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.