Making sense of architecture roles

Have been having a bit of a struggle with two particularly intransigent types over on LinkedIn, in the long-running thread on “EA is the glue between strategy and execution”. They’ve been insisting that their own particular views on enterprise-architecture are ‘the truth’, and that everyone else is wrong. One of them, as we might expect, is hung up on the usual IT-centrism; the other, interestingly, has been adamant in using the term ‘enterprise business-architecture’ to describe what is a much greater scope than merely ‘the business of business’ – in other words, falling for the second TOGAF trap rather than the first, a ‘business-centric’ rather than IT-centric view of architecture.

I won’t bother going into the ‘dirty-tricks’ game-plays in which these two have indulged, both online and offline: let’s just say that they might even give Himself a run for his money, in terms of dysfunctionality and professional dishonesty. Hey ho. But in near-desperation I sat down to try to tackle the whole question – making sense of architecture roles – in a systematic, structured way. The following was the result, as posted to LinkedIn:


To quote Jurgen Dahlberg on Twitter, one of our core problems is that “Enterprise Architects fail because of their reliance on logic as their single means of persuasion.” True or not, it may be useful to tackle the specified theme of this thread in a structured, logical manner.

The stated theme is that “EA is the glue between strategy and execution”.

A strategy is a statement of intent that something should happen.

Execution is what is actually done to make that intent actually happen.

The blunt reality is that there may be many disconnects between strategy and execution. These potential disconnects typically increase with scope, scale and complexity.

In practice, and especially in large complex organisations, it may be very difficult to realise (execute) a chosen strategy.

One reason is that an organisation brings together many different disciplines, each of which have their own terminology, their own context-specific experience. ‘Translation’-difficulties are very common between disciplines and even between work-teams.

Another reason is that organisations tend to be structured in silos, again reinforcing barriers of ‘language’, but also providing all manner of other boundaries of politics, control, authority, hierarchy and the like. Larger corporations may also have to deal with multiple jurisdictions, multiple natural-languages, multiple human-cultures and so on – all of which add their own difficulties for translation and execution – especially where the strategy requires context-specific forms of execution.

Another reason is that different domains may well be going through different changes, and/or different rates of change. Maintaining alignment over time across all of the disparate domains will rarely be simple.

Yet another reason is the translation from abstract to concrete, from strategic vision to real-world practice. The use a well-worn phrase, the devil is in the details – details which may not have been allowed for in the initial strategy.

As a result of these and other related forces and constraints, the organisation has a natural tendency to fragmentation. There is therefore a need for a distinct discipline responsible for bridging all of the gaps, aiding communication, providing advice on design within and between domains, and generally assisting in both the execution of strategy and in formulating strategy.

By convention, a role that is responsible for linking between domains in this way and for this purpose is referred to as an ‘architect’.

In a small organisation, it is usually possible for one person to cover all of the ‘architect’ role. In principle, this is the responsibility of the CEO or equivalent, but in practice the role will often be delegated to others.

As the scope, scale and complexity grow, this ‘architecture’ responsibility will usually be partitioned amongst more and more people, each covering a different aspects of the overall scope, and with different balance between depth (specialism) and breadth (generalism).

Depth is needed in order to grasp the detailed needed to achieve execution.

Breadth is needed to ensure that each domain and subdomain and project links cleanly and appropriately with others.

We could summarise depth as follows:

  • none: the other domain is considered out-of-scope, not relevant or non-existent
  • black-box: the other domain is known only in terms of its exposed interfaces, without requiring any knowledge of the domain’s internal operation
  • white-box: some knowledge of the other domain’s internals, sufficient for concerns such as cross-domain trade-offs, probability and direction of change, failure scenarios and risks, disaster-recovery scenarios and options, etc
  • full-depth: full knowledge and experience of the other domain, to an identifiable level of skill (e.g. Trainee, Apprentice, Journeyman, Master)

We could summarise levels of abstraction with the Zachman layers, from row-1 (business context, within which the strategy will operate) to row-5 (action-plan immediately prior to execution).

We could summarise scope (and hence breadth) in terms of the various domains, subdomains and silos of the organisation and its business context. The precise list will depend on industry, organisation-structure and many other factors, but common examples are indicated by responsibilities of the respective senior executive: CFO (finance and ‘business of business’), CIO (information), COO (operations), CTO (technology), CKO (knowledge/learning) etc. As above, the CEO has responsibility for the architectural integration of the organisation as a whole.

Each architect-role will have its own distinct combination of scope, scale, complexity, abstraction, depth and breadth.

Note that even in the same nominal scope, architects may have different requirements for depth or breadth. For example, a process-automation architect may regard power-supply and skill-sets as out-of-scope (‘none’-depth), whereas an architect working on disaster-recovery planning would need ‘white-box’ depth in each of those ‘out-of-scope’ areas.

To identify the required responsibility, authority, reporting-relationships and the like, it will be useful to categorise these roles according to Len Fehskens’ schema:

  • xA (e.g. data-architect, Siebel architect, brand-architect): architect within domain or narrower scope (sub-domain, portfolio, project); usually row-3 to row-5 abstraction; limited breadth; usually ‘black-box’ or ‘none’ depth in domains outside of own immediate scope
  • ExA (e.g. enterprise IT-architect, enterprise business-architect, enterprise security-architect): architect across a complete domain; usually row-2 to row-4 abstraction, but may need to do deep-dive in own domain; usually ‘white-box’ or ‘black-box’ depth in domains outside of own scope
  • EA (enterprise-architect): architect across all domains; usually row-1 to row-3 abstraction, but may need to do deep-dive in any domain; must have some level of ‘white-box’ depth across all domains

Categorisations of these types will aid in training and selection. The categorisations of scope and responsibility will indicate the trade-off between specialism and generalism, and the domain(s) of primary interest. The ‘depth’ categorisation indicates the required level of skill for each domain and subdomain in scope: ‘black-box’ depth would require only the ability to understand interface specifications, whereas ‘white-box’ would require familiarity with domain terminology, and ‘full-depth’ would typically require specialist training and certification. For example, TOGAF Foundation is a ‘white-box’ certification, whereas TOGAF Certificate should imply ‘full-depth’ knowledge.

In theory, any architect-role may be assigned any name whatsoever (including nonsense-titles such as ‘Bob’ or ‘Fred’).

In practice, however, each architect role should be assigned a meaningful name or title that, at a minimum, indicates its scope,  primary domain (if any) and abstraction-level. This will aid in communication with other stakeholders, and hence in itself becomes part of the architecture.

Assigning misleading names – such ‘enterprise architect’ for an IT-specialist, or ‘enterprise business architect’ for a role that extends beyond ‘the business of the business’ – will hinder communication, and thus should itself be considered an architecture risk.

Comments/opinions, anyone? Hope this is useful to someone, anyway.

6 Comments on “Making sense of architecture roles

  1. Hi Tom,

    Interesting breakdown of the roles. I wonder if one of the reasons we see such disagreements is a core confusion… between roles and titles! (e.g. if you have a title, we should place the expectations of the role on you, for better or for worse).

    I like the way you break it down, with the CEO playing the architect role, and with the needs for the role increasing as orgs increase in complexity. This is a useful post and I will be sharing it with others. Thank you.

  2. Many thanks, Nick – given your background and work, would be valuable to have your input on this as well.

    Although, as I mention above, I came to that xA/ExA/EA schema by working from first-principles, I need to reiterate that Len Fehskens has done a lot of work on this over the past years – see, for example, his session at Open Group, Boston July 2010. Would have been helpful if I hadn’t forgotten that… but credit where credit’s due. 🙂

    Also Kevin Smith came up with a nice way to describe this, using a 3D bar-chart in Excel. One axis (x-horizontal) is the role; the second axis (y-horizontal) is the domain or subdomain; and the third (z-vertical) is the required or actual skill-level/knowledge-level in that domain, from ‘none’ through black-box, white-box, Trainee, Apprentice, Journeyman, Master. (An alternate and perhaps better choice for the third axis would be Zachman layer, from row-1 [or row-0 if you use my extended version] down to row-5.) A typical xA role will appear as a single vertical bar (full-depth) with occasional dots elsewhere, probably none of them above Zachman row-4. A typical ExA role will have full-depth in one or two domains with some depth (usually Zachman rows 2-3) across a much broader yet incomplete set of other domains. An EA role may have full-depth in one or more domains, but must have some depth (i.e. more than ‘none’, and at least Zachman rows 1-3) in every domain.

  3. Hi Tom,

    My first time on your blog site, good content!

    Practically, titles that actually have meaning still require context (or a framework) to be known and undertood by all stakeholders within an organization. To apply such tiles in an organization may lead some individuals to resist if their perceived competence or importance is diminished in any way. An interesting idea nonetheless. As for breadth and depth, I can see how they can be used by architects in assessing the weight or strength of stakeholder input when populating EA artifacts within the rows/cols of the Zachman framework.

    I am currently working as an Enterprise Architect (EA category) consultant with over 20 year experience in consulting.

  4. What is important is the ExA definition. Whatever architect we feel we are (for example, I see myself has a BizArch therefore a enterprise business-architect or EbA). The only question is my continual involvement in clarifying values, vision and strategy. Therefore, would I begin with Row 1 and not Row 2.

    Secondly, could you add the link to Kevin’s 3D bar chart?

  5. Pierre – many thanks.

    Yes, there are real problems with ‘upsell’, or resistance to requests for realism in alignment between role and title – “some individuals … resist if their perceived competence or importance is diminished”. Nick Malik also commented on much the same problem above.

    One way out of this is to emphasise that this isn’t about titles but about the work to be done. Much of the tension around purported competence at present is around specialisation, or depth of skill in a primary domain such as IT, or business-models, or a particular technology, or whatever. Really all that we’re asking about, in this xA/ExA/EA categorisation, is about generalism, about the level of knowledge and skills required in areas that are not the primary domain.

    An xA category expects very high skills in at least one domain, with black-box (interface- or protocol-level) knowledge of an appropriate range of other domains that connect with that primary domain (for example, BPMN models that link manual-process or business-events to IT-based workflows).

    An ExA category may actually have less skill in their primary domain than an xA (or, more usually, somewhat less experience in current detail-level than an active xA). Instead, they trade off depth for scale. That’s what the ‘E’ prefix: they cover an enterprise-wide scope for that domain – which means they won’t have time to go to detail-depth, which in turn is why they need to work with xAs to ensure that the strategy or whatever does come right down to real-world level. It’s true that ExA roles tend to be done by more senior people, but that’s mainly because (as you know firsthand) it takes many years to gather together enough experience to do the work. But in reality in not about seniority or ‘importance’: it is a different role.

    The EA role (and its equivalent in other professions, such as building-architect or marine-architect) is again a different. Unlike the xA/ExA relationship, the skillset itself is different: the specialism of the EA is not a specific domain, but generalism itself.

    An xA tends to prefer depth, primarily in one domain; an ExA also focusses on one domain, but at a larger scale; an EA tends to prefer scope, across many (preferably all) domains. It’s not that one is ‘more important’ than another: they’re different roles. That fact should, I hope, dissuade people from trying to ‘claim’ a type of role which they don’t want to do anyway. And if titles could also reflect that point, it would definitely help! 🙂

  6. Pat – yes, you’re right, starting at row-1 versus row-2 (or even row-3) is probably one of the most visible differences between an ExA versus xA role. (For those who aren’t familiar with the Zachman categories, row-1 essentially describes things in terms of lists; row-2 adds relationships between items; and row-3 also identifies and adds attributes to those descriptions of things.)

    I can’t provide you with a link to Kevin’s 3D-barchart, because it doesn’t exist! 🙂 It’s an idea that came up in a discussion between us, and I think it’s documented in an email from Kevin, but that’s about it. In essence it’s what you have above: define a 3-axis grid in Excel or whatever, with ‘name of domain’ as one axis (e.g. IT development, IT service-management, business-strategy, process-development, production-management, HR, finance, security, marketing, etc); role-name as another axis; and Zachman row-depth (or knowledge-level: none, black-box, white-box [‘logical’], mid-depth [‘physical’], full-depth [‘deployment’]) as the vertical axis. Use one of the Excel 3D chart-types to display the result: you’ll end up with a structure in which the xA roles are deep within one domain; the EA is spread rather thinly across the whole map; and the ExA roles kind of half-way between, emphasising one domain but dotted all over the map, with each only ever covering part of the map.

Leave a Reply

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