Linking enterprise-architecture with solution-architecture

What are the respective roles of enterprise-architecture and solution-architecture? How do they relate with respect to each other – and with respect, too?

I’ve been having a great back-and-forth on this on LinkedIn with Donald Lawn, an IT-oriented architect down in Australia. (If you’re in the iCMG Architecture World group on LinkedIn, it’s the discussion hosted by Sabyasachi Nath, on “What is the differences in the role of a “solution architect” and EA? Or “solution architect” is a subset of EA?“)

Some of this conversation has come up already here, in the data-warehouse anti-pattern described in the post ‘Unbreaking‘, but we’d also been talking quite a bit about ‘Architecting the enterprise backbone‘ – about the different types of governance needed to balance the demands for stability versus the demands for agility, or ‘backbone’ versus ‘edge’.

On LinkedIn, Don came back with a detailed explanation of how this could be implemented in terms of XML data-structures and the like, and the limitations of relational databases for this purpose. It was an excellent illustration of both the breadth and the level of detail that’s needed in solution-architecture – in any architecture, actually. We can talk abstracts for quite a long time, but at some point we have to do something – and doing anything does require the detail.

Yet Don’s post was also a really good illustration of the difference between the roles of enterprise-architecture and solution-architecture. As an enterprise-architect, I’d deal mainly with issues that straddle across the whole enterprise-space, with an emphasis on breadth; the solution-architect maintains the breadth pertinent to a specific scope, but also focusses right down on the technical and other detail needed for that specific solution. In a sense, EA is more about context, SA is more about content.

To give a concrete example, imagine we’re working for a large logistics company that (like everyone else) wants to save a whole heap of money, yet that (unlike almost everyone else) wants to make those savings sustainable in the long-term, by building and leveraging mutual trust, in the broadest sense – in other words, with customers, suppliers, employees, investors, the lot.

One practical way they can do this is with self-insurance of their truck fleet, much like I’ve heard Procter & Gamble do. They don’t have an external insurer and the concomitant tedious ‘get three quotes we’ll always go for the cheapest and if you get crap quality that’s your problem’ claims-process – they just deal with the incident straight away, whatever it costs, and without any argument. Which actually ends up much cheaper and much quicker all round, and everyone’s a lot less hassled and a lot more happy about what is otherwise a rather unhappy kind of incident. It also builds trust – lots of it. Yet it also depends on trust – likewise lots of it. Which means that we can’t tackle it as if it’s just a ‘quick money-saver’ – it’s a fundamental shift in the overall architecture of the enterprise.

To make it work, as an architect, I’m going to need an architecture of trust that supports that fundamental shift in attitude across the enterprise, which in turn will depend on a lot of other more tangible changes to underpin that shift. One of those changes is that we’ll need much better handle on some types of information, because claims-incidents, costs-savings, fleet-availability, customer-reputation and supplier-relations all become so intertwined that in effect they can almost become proxies for each other. To make sense of that, and to enable appropriate real-time choices at every level from executive to operations, we’re going to need some kind of ‘trust-dashboard’, where all these information-themes come together. Yet its design and implementation will also need to be able to handle a lot of change, because there’s a lot of wicked-problems and subtle ‘gotchas’ hiding in there; and we’re going to need a fair amount of rethink – probably over several years – before we could settle on something that is self-adapting enough to work well.

Which is where that previous conversation between Don and I comes back into the picture. As an enterprise-architect, I have a fair idea about what’s needed for this ‘trust-dashboard’, but I don’t know how to do it. Not in enough detail to make it work well in the real-world, anyway. (That’s Step 1: admit that I don’t know how to do it…)

But to use the old quote, “I know a man who does”. (That’s Step 2: build and maintain a good professional-network across a range of people that’s much broader than just my immediate peers.) And there are at least two people I need to know in this case: a domain-architect (we’ll call him David), who understands the broader information-technology issues and the way the technology-trends are going; and a solution-architect (we’ll say he’s named Daniel) who knows what works in this organisation’s technology and culture.

To do my part of this job properly, I have to be able to build a straw-man concept of this ‘information-dashboard’ that’s both detailed-enough and credible enough for David and Daniel to say – if perhaps grudgingly! 🙂 – well, yeah, can see what you’re gettin’ at, but, y’know, we’d be better if we did it this way, and anyway that technology’s goin’ outta date and the vendor won’t support it past the next five years, so ya gonna need this new stuff instead. And I’d say, kind of, sort of, yes, but I need it to do that thing, for this reason, and not force people too much along this path, because of that thing, and so on. Back and forth we go, bouncing off each each other’s perspectives as we iterate towards a workable idea. (That’s Step 3: the real core of architecture is the conversations – the detail is the outcome of those conversations.)
This is only going to work if there’s strong mutual respect between us. (That’s Step 4: build and maintain strong work-relations with my professional contacts – the Rolodex-type collection of contacts isn’t enough on its own) I need to listen to David and Daniel: they know their job far better than I do, and far better than I ever will – so I need to respect that fact, and respect their knowledge too. (Which in part depends on Step 1: knowing that I don’t know, and hence being respectful enough to ask for advice…) And it’s also up to me to gain David and Daniel’s trust enough that they don’t dismiss me as some kind of ivory-tower airhead who’s just there to waste their time – that I’m dealing with a broader scope that extends beyond their domain, but I need their help within their domain. (That’s Step 5: know what my domain is and isn’t – what I do know as well as what I don’t, and where and how it overlaps with others’.)

Which is where, eventually, we get down to the detail of ‘backbone versus edge’. The first part is straightforward data-architecture, data-dictionaries, taxonomies and the like. But we do it in stages, starting only with the items that we must have in common: such as a data-structure for item-identifiers, sub-typed out to Truck, Location, Incident, Claim and so on; and a data-structure for Party, sub-typed out to Customer, Supplier, Driver, Claimant and suchlike. (We start with the bare minimum, and build it so that it’s (re)usable anywhere, and extensible for any purpose – both of which imply something like XML, as Don suggests in his LinkedIn post, though the key point is that we need to keep awareness always on the underlying requirement, rather than solely on any specific implementation of that need.)

We extend and amend that core, slowly, under governance. (Which actually implies a set of XML DTDs rather than a single core DTD, with different types of governance for different parts of the set.) What we’re always after, though, is a structure and approach that supports what Don described in his LinkedIn post: “Here are the formats you must communicate in – otherwise do what you like, and we can support new formats if you need changes.” Backbone where it must be backbone, because that’s what everyone needs as backbone; yet beyond that, free to move around as needed.

That’s the kind of conversation I’d need to build and maintain with David and Daniel, in the IT-oriented space. Yet as a broad-scope enterprise-architect, I’d also need to build and maintain similar conversations with their counterparts in the fleet-operations space, the process-design space, the finance space, the Health & Safety guys, the facilities-architects and managers, and many others – and broker good conversations between them and David and Daniel as needed, too. It’s a much broader scope: but because it’s a broader scope, we enterprise-architects simply do not and cannot have the time or the knowledge to do all of the architecture ourselves – which is why we need good relations with the people who do.

IT-architecture focusses on information; enterprise-architecture also needs to include the physical ‘things’, the business-relations, the ‘purpose’-type issues such as brands and reputation, and so on. But whichever way we look at it, and whatever scope we need, all of it is architecture – it’s all the same basic idea, really. 🙂

That’s the way I see it, anyway. Comments, anyone?