Enterprise-architect as generalist
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.
“Relationship between CITO and EA” is correct. The rest is still work to be done….
Thanks,
AS
By 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..?
We need to make sure we are separating Architecture from Architect. With a team of architects, some will be more enterprise focused, techology focused, and/or business focused. To be everything, at a low level of detail is a bit unrealistic.
@Tetradian “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.”
Absolutely. architects don’t make the decisions, they provide the information for the board to make decisions.
@tetradian “My own strong preference is that the EA term should be reserved exclusively for āthe architecture of the enterpriseā.”
And I add my preference is business architecture is about the specific business and its relationship internally and externally. More probable today, it involves IT as the implementor of business but IT architecture is separate from BizArch.
Alexander: Thanks, and yes, you’re right, “the rest is still work to be done”. But at least these days it is the direction that ‘the trade’ is going – as evidenced by the strong emphasis on business-oriented architectures in Open Group conferences. It’ll no doubt still be a long slog to get there, but it’s a lot less of an uphill struggle than it was two or three years ago! š
Pat: Many thanks for the comments.
“We need to make sure we are separating Architecture from Architect.” – very good point, and one that I hadn’t elaborated enough in the post above: thanks for the reminder on that. The architecture necessarily covers the whole space, but an individual architect probably can’t or won’t: hence, in many or most cases, the need for collaboration between the architects who manage the ‘architectures’ that make up the overall architecture.
“Architects donāt make the decisions, they provide the information for the board to make decisions”. Not just the board, of course – most of us don’t work at those rarefied levels! š – but for decision-makers at every level. A lot of TOGAF-type work, for example, is decision-support for detail-level project-teams, as described well in Phases E-G of the TOGAF ADM.
“And I add my preference is business architecture is about the specific business and its relationship internally and externally.” – yes, agreed. I’m seeing a tendency amongst some folks to imply that business-architecture is the same as enterprise-architecture, which to me is quite dangerous: business-architecture is necessarily centred on the needs of the ‘the business of the business’, whereas a true ‘architecture of the enterprise’ cannot hold to any single point as ‘the centre’: everything is dependent on everything else, hence everywhere and nowhere is ‘the centre’.
“More probable today, it involves IT as the implementor of business but IT architecture is separate from BizArch.” – agreed, yet there’s also another dangerous trap here. Almost all of the existing ‘enterprise’-architecture frameworks – Gartner, Oracle, SAP, TOGAF, FEAF and the like – describe ‘the architecture’ as a simple stack (‘BDAT’) with IT at the base and ‘business’ at the top. The catch is that this ‘business’-architecture is actually a context-architecture for the primary scope of IT: most of the descriptions in essence treat ‘business’-architecture as a generalised grab-bag for ‘anything not-IT that might impact on IT’. Which actually is fair enough if our only real interest is IT. But if we are concerned with ‘the business of the business’, we actually need to lift the whole pattern two or three steps higher: ‘business’ now becomes our primary scope – assessed in the same depth as we would with IT in the TOGAF-8.1 ADM, for example – and the broader extended-enterprise or ‘business-ecosystem’ takes the same place as ‘business-architecture’ in TOGAF, as a context-architecture for ‘the business of the business’. We need to be wary of the ‘BDAT’ stack: it’s important to see it not as a list of architectures, but a pattern of relationships between a primary focus (IT, in this case) and its working context.
@ Relationship between CITO and EA
ā¢ In my practice I use the acronym CITO in relation to CIO to get the point across that the current CIO is usually an IT-manager, not an information manager. I know the aconym CITO is in fact wrong because IT-management (ought to) reside at and around tactical level in organizations, where investing in and exploitation of technology-based solutions is realized. This is in line with the technology driven definition in the US Clinger/Cohen Act of 1996. Future CIOās must be a manager managing the need for information of an organization as a corporate resource.
ā¢ The relationship between CIO and EA is not a simple one. Recently I saw a conversation in the flow of a Gartner symposium where people were talking about strategic EA versus tactical EA. In line with my CIO/CITO point current EA methods and approaches are in fact about IT. One could compare this to what they call tactical EA. The tactical enterprise architect is someone who has great insight in the way solutions for information problems work, and how these solutions work together to have an information infrastructure for the organization. The tactical EA supports IT-management with knowledge and experience.
The CIO needs a strategic architecture to do his/her work. I hesitate to call this enterprise architecture, because such an explanation would make the term enterprise architecture a homonym. The āstrategicā architecture I mean is needed at strategic level and contains knowledge of the information of the organization. For that reason we have been talking about information architecture, where the subject is not IT but the information itself. The strategic architect, information architect, strategic EA supports the CIO and his/her information managers.
And yes, calling current EA āenterprise architectureā is a problem because this architecture is in fact around the IT of the enterprise/organization. So what method developers and promoters currently call EA is not the architecture of an organization. Something similar is true for the term information architecture. It ought to be the architecture of the information of an organization, while the term is used as the architecture of the information infrastructure supporting the organization. Again, homonyms. This is why I have proposed to The Open Group in their meeting in Miami and San Francisco to talk about IT-Enterprise architecture to solve this homonym problem. It is a pity they decided differently.
The reason for investing in IT (administrative purposes) is the need an organization has of its information. So the need for information is what is demanded, while the availability of information technology to provide solutions to fulfill this need is supplyside. This can be compared to the way a CIO manages/controls what IT-management is doing for the organization.
@StevenvtVeld
What I particularly like about this view is that, while maybe not revolutionary, it just ‘feels right’.
Unfortunately, there’s a lot of headwind to overcome in getting the definitions where they need to be. Most of the folks I talk to in industry are at least 4 or 5 years behind the curve related to understanding of EA.
@ Relationship between EA and specific domains such as technology-architecture
There is a difference between solutions and the technology needed to be able to ārunā these solutions. These solutions combine applications, data and a number of other things needed to support the organization (alignment), while technology exists of hardware, networks, systemsoftware etc. forming the platforms needed to by the solutions to be able āto runā.
In practice we have enterprise or solution architects (many other names) next to IT- or infrastructure architects. Both are needed in line with the description Iāve given earlier.
As a reaction to your TOGAF argument: it is good TOGAF is more about business, but it is still very noticeable where TOGAF came from. This is mainly due to the fact the people developing and using TOGAF are IT-professionals.
I wholeheartedly agree with your conclusion the word enterprise is not the right term to use for what TOGAF is. That is why I did propose, years ago, to alter the term to IT-Business Architecture. This was not accepted by the The Open Group at the time. Pity.
Can you change you truck into a luxury car? Or the other way around? It will be very difficult to change TOGAF. One of the signs of this is in the problems there are around business architecture in the community. Simple reason: you should not assess travelling starting with the design of the engine of a car. Or: why do we try to understand a given problem when we know so much about the solution already? A bit like: if you only have a hammer, everything starts to look like a nail. And I write this to get a professional problem across.
@StevenvtVeld
@ The role EA of as a generalist discipline
A generalist is in reality also a specialist: the generalist specializes in knowing enough about a lot of subjects/disciplines in their interrelation. Compare this to internists and geriatricians in healthcare; they look at āall in generalā, and are not specialized in heart, kidneys etc. or other problems.
It is very hard for a specialist to become a generalist. The reason is simple: their original specialism will always prevail in their way of thinking and working. This is why it is so hard for IT-professionals to become generalists; in practice you always know they base their thoughts on information technology. This is a problem because it is the task of a generalist to weigh all options as equal as (s)he can. The reason being the real problem may be in any of the disciplines.
Todayās EA are IT-professionals. They know IT is the most important development ever, and anything and everything can be better with IT and itās approaches to realize IT. These are the thought of real specialists, and we must be very happy to have them. But they cannot be generalists, because they are not objective when they weigh all disciplines around a problem. So EA cannot be a generalist discipline.
We do need generalists. And we do have people who think and work as generalists. They have a difficult time because the IT-lobby is very strong, and their voice against IT, when and if necessary, is ridiculed because they do not understand IT enough. This in itself is a big fail. For this reason we will have to educate people as generalist from the start. And of course it is not impossible for a specialist to become a generalist; the problem is there are very few people who are able to forget indepth knowledge once they acquired it.
My point of architect versus generalist versus CIO is a point for discussion. In line with my former positioning of architects and IT + information management (incl. CIO) is the basis for this discussion. It is the manager who will have to have the overview, while the architect needs to be specialized in one of a number of areas. I just concluded it will be very difficult to de-specialise once you are specialized. On the other side a manager works with people first, with content second. So can a manager have enough general knowledge to be the generalist, also? In my mind this clearly states the need for a generalist, at least in the larger organizations. If such a generalist is not available one must hope the respective architects can have such a communication with the respective managers that they will capture broad view an organization really needs.
In your answer you refer to Len Fehskens proposed standard classification of roles in terms of depth versus breadth. I do have a problem with this classification, as you can read in this comment. For instance white box knowledge of Zachman row 3 System Model for the generalist says a lot about the kind of “generalism” he describes. Maybe I can best name this as an IT-generalist, while I do think we need generalists who know enough about a full set of other disciplines, hardly related to IT.
@StevenvtVeld