One of those great back-and-forth Tweet-conversations: this time about the relationship between technology-architecture and enterprise-architecture, triggered by a post by Forrester consultant Gene Leganza on ‘15 Tech Trends EA Should Watch‘ (ZDNet summary here). The conversation meandered to a set of questions by Brian Hopkins and Steven van ‘t Veld which seem worth expanding here:
- practicingEA: @tetradian @dougnewdick Should EA divest itself of Tech selection then. Seems part of E is T so the TA part of EA should still b involved..?
- tetradian: @practicingEA: “Seems part of E is T so the TA part of EA should still b involved..?” #entarch – yes, of course: tech is part of enterprise
- practicingEA: @tetradian begs further ?… Is TA part or separate from EA. My vote….no. EA team should have reps from all domains BA DA AA TA
- tetradian: @practicingEA: “EA team should have reps from all domains BA DA AA TA” – yes: and many other domains too (BA is not ‘everything not-IT’!)
- StevenvtVeld: @practicingEA @tetradian So if there are reps from all domains, who is the enterprise architect? Is EA the one with all of specialisms?
- StevenvtVeld: @practicingEA @tetradian So, is there a difference between the notion of “Enterprise Architect” and the CITO?
- tetradian: @StevenvtVeld “if there are reps from all domains, is EA the one with all of specialisms?” – EA is the *generalist* that links all together
- tetradian: @StevenvtVeld: “is there a difference between the EA & the CITO?” – lots! 🙂 CITO decision-maker in IT, EA is decision-support across org
- StevenvtVeld: @tetradian How do you create such a generalist? Current #entarch are IT-specialist. What is his/her task? So: what is differnce btwn EA&CITO
- StevenvtVeld: @tetradian Agree: IT-manager versus supporting professionals. Still cannot find the “generalist”. #entarch
To me the key questions embedded in there are about:
- the relationship between CIO (CITO) and EA;
- the relationship between EA and specific domains such as technology-architecture;
- the role of EA as a generalist discipline.
Before we go further, it might be useful to point back to some previous posts, as further reference if it’s needed:
- Two roles for enterprise architects (internal team versus external consultant)
- Making sense of architecture roles (skillsets, skill-levels, generalist versus specialist, and the xA/ExA/EA categorisation)
- Enterprise-architecture: Bring on the clowns? (role and relationships of generalists in the organisational structure)
- Business-architect or enterprise-architect? (breaking free from the IT-centric description of business-architecture as ‘anything not-IT’)
- Skill-sets for enterprise-architects (pointer to a very useful article by Sally Bean)
- The rise of the business-anarchist [on Sidewise blog] (skillsets to work with inherent-uncertainty – a key part of EA responsibilities)
- 10, 100, 1000, 10000 [on Sidewise blog] (typical timescale needed to reach specific skill-levels)
Relationship between CITO and EA
I’m not quite sure what’s meant by the term ‘CITO’: I’ve not seen it before. It implies a kind of merging of the CIO role (Chief Information Officer, which technically needs to cover all information-management, including IT-based and non-IT-based forms) and the CTO (Chief Technical Officer, which technically needs to cover all technologies, both IT-based and non-based). Yet it also implies the subset of both of those roles that only deals with IT. For now I’ll assume that the latter is meant: a CxO-level role which, however, only focusses on IT.
There are many arguments at present about about the scope of EA, but for this specific question we’ll set them all aside and assume that it has the exact same scope as the CITO – whatever that may be.
If we assume the same kind of authority for the CITO as for a typical CIO or CTO, the role would be responsible for budget, for planning, for strategy, for people-management, for business-continuity, security, disaster-recovery and much, much more. As far as the specified scope is concerned, the buck stops with the CITO: they’re responsible directly to the executive and the board for all matters in scope. In anything other than a quite small organisation, it will be too much work for one person: hence much of the leg-work and detail-work and the like will be delegated to others by the CITO. Security is one obvious example where the work is likely to be delegated; service-management is another; change-management is another. And, in turn, architecture.
To me the simplest summary of architecture in general, and EA in particular, is that it’s responsible for the practical expression of a single core-principle: Things work better when they work together, with elegance, with clarity, on purpose. Another keyword is effectiveness: not just efficient, but efficient on purpose, ‘doing the right things right’.
So the EA has two key roles: a communicator, linking people together; and design-support across all of the domains in scope. Some EAs do detailed design; others are more likely to help coordinate design by others, or to bring in design-ideas from other areas, to help reduce the natural tendency to groupthink or ‘solution-first’ thinking. The key point, though, is that it’s primarily a decision-support role, helping others to understand the nature and options in the selected scope, and the probable consequences of each decision in that scope. An EA’s reporting-relationships tend to me complex, with matrix-relationships across much or all of the scope, at almost every level; and the role’s authority tends to be informal rather than formal, an authority derived from trust and respect rather than explicitly assigned in a formal management-hierarchy.
By contrast, the CITO is primarily a decision-making role, with ultimate formal authority and responsibility for the scope.
Relationship between EA and specific domains such as technology-architecture
Many people will still assert that EA is primarily a technical discipline. And it is true that much of the background of what is currently called ‘enterprise architecture’ arose from a perceived need, starting perhaps a couple of decades ago, to manage the cost and complexity of IT-infrastructures and of the applications and data that run upon them. The history of TOGAF illustrates this well: TOGAF 7 was almost exclusively about the architecture of IT-infrastructure; TOGAF 8 recognised that the architectures of applications and data will impact on IT-infrastructure; TOGAF 8.1 acknowledged that high-level business-drivers and detail-level user-interface/user-experience (unfortunately all bundled together as ‘business-architecture’) impact on applications and data; and TOGAF 9 started to incorporate broader-scope views of ‘the business’. The current focus of Open Group for TOGAF is ‘Transforming EA into a Business Discipline‘, expanding outward from the previous technology-centric view of architecture.
‘Enterprise architecture’ literally means ‘the architecture of the enterprise’ – the whole of the enterprise, not solely its IT. There have been disciplines with this scope and responsibility – though perhaps not with that name – for at least half a century or more, long pre-dating the IT-industry usage of the term ‘enterprise architecture’.
The use of the EA term for technology-architecture is an unfortunate misnomer, probably arising from a habit of technical specialists to describe broad-scale (rather than broad-scope) implementations as ‘enterprise’ – hence EAI, ‘enterprise application integration’, or ESB, ‘enterprise service-bus’. This is unfortunate because it causes a ‘term-hijack’, in which the narrow-scope usage of the term (IT-infrastructure, in this case) blocks out the view of the broader scope (the enterprise as a whole, including people, purpose, strategy, market, business, and non-IT technologies).
If we take a narrow view, then EA ‘is’ technology-architecture, and, probably, where that architecture intersects with other architectures such as service-architecture, brand-architecture, security-architecture and so on.
If – as Open Group and others are now more openly proposing – we use the EA term in its literal sense as ‘the architecture of the enterprise as enterprise’, then technology-architecture is a both a subset of that broader-scope architecture (relative to the organisation) and an intersecting-set (relative to the organisation’s industry and the IT-industry in general).
My own strong preference is that the EA term should be reserved exclusively for ‘the architecture of the enterprise’. All other enterprise-scale architectures with narrower scope than the whole ‘enterprise-as-enterprise’ should be referred to as ‘enterprise xxx architecture’ – for example, ‘enterprise technology architecture’, ‘enterprise security architecture’ and so on.
The role EA of as a generalist discipline
Design and implementation of almost anything in a large, complex organisation will require specialist skills and experience. However, to manage the many different forms of complexity and interaction, successful implementation will also require breadth, the ability to connect across disparate domains.
As part of the role of ‘connector between things’, every architect will cover some part of the overall scope in depth, and some or all of the overall scope in breadth. Yet in anything other than a relatively small organisation, no-one is likely to be able to cover everything in full depth and full breadth. In practice, the work usually needs to be partitioned between different people – some emphasising depth, others emphasising breadth.
As summarised here, Len Fehskens has proposed a standard classification of roles in terms of depth versus breadth:
- xA (eg. business architect, data architect, process architect): deep-specialist knowledge in one or more primary domains, with an emphasis on implementation (Zachman row-4/5); either ‘black-box’ (interface/protocol-only) or no knowledge of other domains
- ExA (e.g. enterprise IT-architect, enterprise security architect): specialist knowledge in one or more primary domains, with an emphasis on connections between domains (Zachman row 3/4); usually ‘white-box’ (full Zachman row-3) knowledge of any directly intersecting domains
- EA (enterprise-architect, in the literal sense of the term): generalist knowledge across all domains of the enterprise, to at least ‘white-box’ level (Zachman row-3)
An xA role will typically emphasise best-practice, depth-analysis and formal analytic rigour. An ExA role and, especially, an EA role, will also follow formal rigour, but must balance this with a much stronger emphasis on so-called ‘non-rational’ disciplines such as design-thinking and social psychology, and support for communication, creativity, innovation and leadership.
Many people in the technical domains may find an ExA or EA role uncomfortable at first, as Open Group explain:
EA is fast becoming a business activity and is leaving behind the safe haven of IT. Language and communication now stand front and center as the current and most critical element of EA but how do we go about overcoming what, for many enterprise architects, is arguably our greatest challenge?
However, the required skills for these broader-scope roles are known and well-described – as above – and can be learned over time, if one chooses to do so. However, there is no requirement to do so, though it seems clear that the existing (mis)use of the EA term will fade away over the next few years, with technical-architectures each reverting to a more accurate descriptive name.
Hope this helps, anyway.