How much should an enterprise-architect know and do?

A great question this morning from Australian enterprise-architect Mike Aikins (@AussiMike):

Noted some of your comments recently on how you feel more of a facilitator than the creator of an EA when working with a client. Question is how relevant/important is it for the consultant EA to have deep industry/sector knowledge in order to fulfil that role?

There are actually two questions there:

• To what extent should EAs themselves aim to design an architecture for the enterprise?
• Either way, how much industry/enterprise knowledge does the EA need?

The two questions are closely related, but it’s useful to answer them separately and then link them together afterwards.

How much should an EA aim to ‘architect the enterprise’?

Architecture is both descriptive and prescriptive. Although architecture itself must always face toward the ‘big picture’ view, there’s also always a large component of real, practical, concrete design – because architecture only becomes useful when it does touch the real world. (We’ve all seen plenty of ‘concept architectures’ that would be no use at all to any real person – and that applies to building-architecture as much as it does to EA!) So an architect is also always a designer – a creator of what people then experience as ‘architecture’ in the real world.

But there’s an interesting trade-off here. The clients must always be not merely involved, but deeply engaged in the design. If that doesn’t happen, they won’t feel that they own it (‘own’ as personal responsibility, that is, rather than mere possession). And if they don’t feel that commitment towards it – that it is their choice, their creation, rather than something imposed on them – the structure will fail, if only because they’ll find themselves fighting against it in all manner of small subtle ways, consciously or not. Or, to put it the positive way round, the architecture will work best when the client feels that it expresses who they are, how they relate, what they know, what they do, in their own concrete, practical terms. To make that happen, the architect needs to elicit all of those things from the clients – and hence does need to be a firm yet genuinely humble facilitator.

At the same time, each architect does need to express their own choices in the architecture: every building by Gehry or Gaudi, Frank Lloyd Wright or Charles Rennie Mackintosh, is instantly recognisable as such. So the opinions and politics and worldview of each architect do also matter: which means that, especially as an external consultant, we do need to ensure that our views do align reasonably well with those of the respective clients, to ensure that the inevitable gaps can be bridged enough to make the architecture work. (This is one of the key reasons why IT-centric ‘enterprise-architecture’ so often fails: business-folks rarely appreciate IT-types trying to redesign the business world to fit into their own rather restricted image. 🙂 ) This is more about empathy than sympathy: we need to be able to listen, to respect the clients’ knowledge and desires, to yield when appropriate; yet also able to respect our own knowledge, and to know when to stand our own ground. What we know and how we express our vision does matter – and that’s precisely why the client employs us, after all.

Which brings us to the second question: how much do we need to know about the business itself?

How much industry/enterprise knowledge does the EA need?

Obviously, there’s another interesting trade-off here, because what we call ‘architecture’ is actually a complex mix of big-picture aspiration and real-world design. To put it at its simplest:

• design depends on domain-specific specialist knowledge – lots of it
• architecture depends on link-between-domains generalist knowledge – lots of it

So we need both types of knowledge – and lots of both, which is why it takes a long time to become competent as an architect. But domain-specific knowledge is relatively easy to acquire: almost all education and almost all organisational structures push towards specialisation of some form. So to balance that, the architect must be a consummate generalist. You need to be able to learn the rudiments of a domain or a business very fast indeed – sometimes mere minutes may be all that you’ll have, in which to get something both valid and usable enough to work with. Even more, you need to be able not only to grasp the ‘world’ of each specialist, and thence to converse intelligently and usefully in their own specific terms, but also to link all of the ‘worlds’ together in new, more effective ways. We need very strong people-skills, to be able to engage the attention and commitment of people in domain and at every level, from the cleaners and call-centre workers right the way up to the boardroom (who sometimes seem to have little awareness of what their cleaners and call-centre workers actually do…). The specialists often won’t know how their worlds connect with others, if at all, so they won’t be able to help you much in that: it’s up to you to understand the whole as a whole, and make it work well for everyone.

So to reply to Mike’s original question, the short (and unhelpful!) answer is “it all depends”, because there’s yet another huge trade-off here. The reality is that there’s a limit to how much any one person can know, which leads to two very different types of EA roles:

• the internal consultant, with in-depth knowledge of the organisation
• the external consultant, with in-depth knowledge of the world beyond the organisation, including the EA discipline itself

The internal consultants’ value lies in what they know (sometimes even more in who they know) of their own specific business context; paradoxically, the external consultants’ value often lies in what they don’t know, and in the sometimes ‘stupid’-seeming questions they ask so as to discover what they need to know. External consultants can challenge an organisation’s assumptions and ‘givens’ with far more licence and freedom than most ‘insiders’ would have; ‘insiders’ know the organisation’s deep culture in ways that would never be available to any ‘outsider’. Somehow we need to balance the two – the worst balance being where a closed group of outside specialists create ‘the architecture’, and then walk away, leaving the organisation with no architecture capability of their own and no way to use the work that’s been done. (That seems to be a common tactic amongst the ‘big-name’ consultancies: it delivers minimal real usable value to the client but creates long-term ‘consultant dependency’ – which may be a nice way to milk the client for fat consultancy-fees, of course, but seems little better than fraud, in my opinion… 🙁 ).

Most of my own work is in the ‘external consultant’ role, creating context and capability. I’ve done a certain amount of ‘inside consultant’ work in my time, but mainly enough to gain deep respect for the fact that it takes years – decades, even – to build up the knowledge and connections enough to do real whole-of-organisation architecture from the inside. So for most of my clients, my real value is not that I know their business in detail, but that I can learn enough detail fast, and connect that to the whole of the extended-enterprise within which their own enterprise (organisation, business-unit, domain, whatever) will operate and exist. (See my presentation ‘What is an enterprise?‘ for more on this.) Here I perhaps need to emphasise two key points:

• the relevant enterprise is always larger than the nominal organisation in scope
• an organisation is bounded by rules, whereas an enterprise is bounded by shared commitment

Which means that whatever type of ‘enterprise architecture’ we do, we need to know a lot more than just our own scope. IT-infrastructure architects need to understand the applications and data that will run in their infrastructure; data-architects need to understand the business-use of that data as information and knowledge for decision-support; business-architects need to understand the broader enterprise, both horizontally (partners, supply-chain etc) and vertically (market, clients, prospects, non-clients, anti-clients, social context etc). The in-depth knowledge of our own domain is (relatively) easy to obtain; it’s going outside our own scope that’s a lot harder, simply because so much of it is literally ‘alien’.

As a consultant EA,  I need to be able to translate the strangenesses of those ‘alien worlds’ into something that makes practical sense for my clients. I have to make those ‘alien worlds’ seem safe for them, too. And I need to know all of it well enough not to make any serious mistakes! An internal-EA’s knowledge is usually design-focussed, literally into the depth of the detail; an external-EA’s knowledge is necessarily far more generalist – the opposite of ‘depth’, in a sense – looking outward, making connections, drawing analogies and innovations from every other available discipline and domain.

So how much knowledge – and what knowledge – do we really need?

A good specialist can describe and deliver ‘best-practice’ for the industry. As an architect and a generalist, I need to understand what ‘best-practice’ looks like at the present – hence, yes, I do need in-depth knowledge of the industry, or at least know how and where and from whom I can acquire it fast. But I also need to be able to describe and deliver far more than existing ‘best-practice’ – in fact something that will not only deliver ‘even-better-practice’ now, but will continue to elicit new improvements to overall effectiveness onward into the future. To do that, I sometimes need to deliberately ‘forget’ all of what I know about current ‘best-practice’ in the organisation and industry – because the broader enterprise often has different ideas, and better ideas at that!

To constrain the amount of needed ‘depth-knowledge’ to a level that’s achievable, we can usually set the scope-boundaries to those of the broader enterprise – again, always at least a couple of steps larger than whatever our own ‘enterprise’ may be. If we’re doing business-architecture for a brewery, for example, we obviously need to understand our own business-drivers and internal business-context. We need to understand the drivers and context of our immediate market: clients such as shops and bars; other brewers and other direct competitors; ‘up-side’ supply chain such as grains, containers, energy, water; ‘down-side’ supply-chain such truckers, warehouses, distributors – in other words, all the usual interweavings of the transaction-economy. But we also need to understand what’s happening beyond our immediate market, especially where it interweaves with the attention-economy and trust/reputation-economy: hence the importance of non-clients, anti-clients, other intersecting service-providers such as police, schools, medical services, and the community in general. What are some of the entirely different forms of social-entertainment that could sideline beer entirely? Or non-social entertainment, or even non-entertainment, such as the potential impact of fundamentalist religion? If we remain solely introspective, looking only at our own immediate world (‘the competition’ and so on), we can’t complain if our ‘enterprise’ is suddenly overwhelmed by a tsunami of change that could have been entirely expected – and architected for – if only we’d had the sense to look out to sea…

So to come back to the original question again, the short answer is yes, we do need “deep industry/sector knowledge”, to fulfil the design side of the architect’s role. But in practice, we probably need less of that in-depth knowledge than you might expect, because there are plenty of specialists who can give us everything we’re likely to need. Instead, what we probably need much more of is ‘in-breadth‘ knowledge – because that’s what the architecture side of our work needs most.

Hope this make sense, anyway – and thanks again for the question!