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!

Tagged with: , , , ,

8 Comments on “How much should an enterprise-architect know and do?

  1. Thanks for this post Tom, and especially about the difference between external and internal EA efforts.
    I feel a bit of both: although my team is an internal one, the diversity in our business (we run 800 discrete services) means that you are also external to the individual services you are trying to architect.

    I agree that who you know is probably more important than what you know in this situation. Actual detailed domain knowledge can be a hindrance as it lenses your conversations towards it unconsciously.

    Many technical people are also afraid of seeming ignorant as they are hired on the basis of their knowledge and expertise, and this is also a mindset that particularly needs to be discarded if an IT architect is going to transition to becoming an EA.

    • Many thanks for this, Martin.

      A quote from the ‘Tao Te Ching’ seems apposite here:

      “In the pursuit of learning, every day something is acquired
      In the pursuit of Tao, every day something is dropped
      Less and less is done
      Until non-action is achieved
      When no-thing is done, nothing is left undone”

      Seems to me that that’s the key to an architect’s work: keep paring away, simplifying, creating clarity. When there is nothing more to trim away, the work is done. Very different from the myriad ‘ten thousand things’ of real-world implementation!

  2. Is the knowledge-type dependant on what the company needs?
    – Silo thinking is usually preferred by companies concentrating on cost-cutting.
    – Broadly exposed thinking is essential if you want to expand revenue. Broadly to expand beyond even the industry.

    Either can be internal or external architects.

  3. Silo-thinking is often the most serious source of problems, whether cost-cutting or seeking to expand revenue (or equivalents in government/not-for-profit).

    For example, scanning across silos will often highlight unnecessary duplication, which almost certainly means avoidable costs. Silo-based schemas and term-definitions frequently cause chaos when trying to translate data between different departments, such as in whole-of-enterprise process-flows. In general, whilst external architects may have more freedom to find and ‘surface’ such problems, it will usually be up to internal architects to resolve them, because of the amount of depth-knowledge and delicate relationship-management that will be needed.

    By the way, whilst we will often need to build bridges between silos, it’s usually very unwise to try to break them down. However ineffective silos may be, many business-folks (especially in middle-management) *like* their nice neatly-defined fiefdoms, and will defend them far beyond reason – you have been warned! 🙂

  4. @Tom G
    Silo’s can also refer to Silo-industries. If you don’t look outside your own industry, you might miss opportunties that can enhance your enterprise. IE: how I think it was fedex that looks at stock car racing pits for efficiency.

    • Good point, and again reaffirms the importance of the generalist view. The danger there is ‘scatter-gun’ – since everything is possible, there is no focus (which is one of the reasons why silos develop in the first place – to help enforce focus). This is why I push for the importance of visioning as the anchor for a whole-of-enterprise architecture, because it provides a stable reference-point around which ‘anything goes’.

  5. I have had some time to consider your thoughts on this Tom…a few “comments from the trenches” if I may.

    On the first issue of should the EA “Architect the Enterprise”, perhaps the clients I see are unique but I am frequently given the following business proposal – “We need to develop an Enterprise Architecture by date x, we want to hire you to do this for us, you can consult/interview with our management and IT Team but the job is to “do the architecture” using your industry experience and generalist knowledge. You will have 20 weeks to complete this and then you will present this to the board as “our” IT Master plan.” This places the EA consultant in the position of having to put far more of his own biases and perspectives into the plan than is ideal as the level of consultation/engagement is limited by the client. Believe me I have (only a few times) tried to explain how this is not optimal and that they will not have ownership in the plan. In these cases I usually do not get the engagement. Alternatively, I have had great success in taking the engagement on with a view that in an imperfect world, my involvement and engagement with the client will, over time, allow them to understand why this needs to be more than a one-shot exercise and that perhaps in version 1.1 or V2 we may get to a relationship that is more about a partnership or mentor/student. In effect V1 tills the ground to enable the seed of a good EA practice to grow over time. The role of the EA here is initially to demonstrate to the enterprise how an EA practice “could” work within their enterprise….engage them in the dialogue and the (often new) interaction between business strategy, service design , service delivery and the technology foundations underpinning these endeavours. More later…..

    • Thanks, Mike – the blunt realities of real-world EA practice! Agree entirely – I’ve had exactly the same, as I hope was clear from the article. Is certainly true that most of my EA work, especially in recent years, has been “to demonstrate to the enterprise how an EA practice ‘could’ work” in their own context.

      Dialogue is key here. Often my aim in the version 1 (or 0.1, more likely) is to provide something that the executive can argue over – which in effect is a ‘stealth’ method for getting them to take ownership, because once they’re arguing about it, by definition they’re taking some form of responsibility for it. (More to the point, if they don’t argue about it, I’ll have failed, because it will fall back to unused shelfware within weeks.)

      This also points to another difficult trade-off between the external and internal EA roles. The external EA is often arbitrarily assigned the authority to design “our IT Master Plan” or suchlike, but shouldn’t, because they don’t have either the time or the insider-knowledge. The internal EA does have the required knowledge, but doesn’t have the authority, because they’re ‘only’ an employee, usually from “somewhere way down in the crazier side of IT”. The organisation will only start to get serious value from EA when it’s placed as part of strategy and decision-support at the whole-of-organisation level, but neither of the external-EA or internal-EA positionings make that easy to happen. Tricky…

      But thanks again, anyway – yours and others’ “comments from the trenches” always much appreciated!

Leave a Reply

Your email address will not be published. Required fields are marked *

*