What is enterprise-architecture? That’s, uh, one of the more awkward questions of the trade…
(Quick summary: if you ask a dozen enterprise-architects, you’ll probably get at least a hundred different definitions… or just ‘It depends…’ 🙂 )
In the continuing spirit of ‘Ending the shoot-out at the EA Corral‘, let’s assume that all of them are correct in their own way: after all, people usually come up with a definition because they believe it has something useful to say. Yet in essence these definitions do tend to fall into one or other of two distinct camps, which we might summarise as IT-oriented EA and whole-enterprise EA.
If you’re looking for work in enterprise-architecture, or want to develop your skills in that kind of direction, or want to engage an enterprise-architect for your organisation, you do need to be clear as to which is which – because in practice they’re significantly different, and not always interchangeable with each other. In short, don’t mix them up!
Not least in importance here is that at present almost all jobs advertised as ‘enterprise-architect’ roles are actually in the IT-oriented category. If you’re expecting to find a whole-enterprise architect role through the regular recruitment channels, you’re likely to get very frustrated dealing with recruiters who seem not to have any clue about what you’re looking for, and who keep trying to foist roles onto you that seem to have no relevance at all to what you want. There are ways round this, but we’ll come back to that in a moment.
There are several key distinctions between the two categories, which revolve around themes such as:
- ‘enterprise’ as adjective versus ‘enterprise’ as noun
- layering of means versus ends
- ‘inside-out’ perspective versus ‘outside-in’
- centred around IT, or broader-scope
(Business-architecture has a similar split between IT-oriented versus broader-scope, but we won’t cover much about that distinction that here.)
The two categories also differ significantly in required skillsets, though skills common to both will typically include:
- ability to ‘connect the dots’
- fast learner and generalist
- presenter and (often) visual-thinker
- ability to build and maintain broad network of more specialist contacts
- ‘soft-skills’ – enterprise-architecture tends to be highly ‘political’, so these are a real must
Those are the essentials, but ask around to find out more about what you’d need.
IT-oriented enterprise-architecture tends to emphasise:
- ‘enterprise’ as adjective, as a descriptor for scope – the architecture of the enterprise-IT
- a focus on means, on how things are done – often in explicit or concrete form, such as reference to an explicit type of software and/or hardware
- an ‘inside-in’ or ‘inside-out’ perspective – focussing on technical integration and standardisation (‘inside-in’) and/or other areas of the business viewed in terms of their impact on self (‘inside-out’)
- anything IT-oriented, or with some aspect of IT as the central theme in the architecture
In essence, ‘enterprise-architecture’ here is a shorthand for ‘enterprise-wide IT-architecture’. The term ‘architecture’ has a long-established usage in IT; the adjective ‘enterprise’ was prepended to indicate IT-architecture with an organisation-wide or enterprise-wide scope. (In US parlance, ‘enterprise’ can mean either a single business-organisation, or a broader consortium of organisations brought together for a common business-purpose that extends beyond the boundary-of-control of a single organisation: both usages are valid here.)
Enterprise-architecture in this form is usually regarded as an ‘IT role’. These enterprise-architects will work within a team that typically reports to the CIO or CTO, or to an IT-oriented unit within the Project Management Office or equivalent.
As with all enterprise-scope architectures, the primary task is to ‘connect the dots’ across multiple projects and, usually, over longer timescales. The key point about ‘enterprise-architecture’ in this sense is that it will almost always centre around some aspect of IT. This is illustrated well in the structure and content of the TOGAF ADM (Architecture Development Method), which identifies ‘four architectures’:
- Business Architecture
- Information-Systems, split into Application Architecture and Data Architecture
- Technology Architecture
In principle these would be generic, covering all aspects of business, all processes and information-uses, and all types of technology. In practice, the specification describes only those aspects of each of those ‘domains’ that relate to IT-systems and IT-architectures: ‘business-architecture’ in essence is ‘anything not-IT that might affect IT’, manual-processes that parallel or link to IT-based applications are classed as ‘business-architecture’, and non-IT technologies are not discussed at all. These are very significant constraints, yet it does make sense, if the respective architecture-practice is centred around IT-domains.
Part of the reason for this IT-orientation can be seen in the version-history for TOGAF:
- up to TOGAF 7: focus is primarily on IT-infrastructures at enterprise-scale (initially in defence and similar contexts, from TOGAF’s predecessor-framework GERAM)
- TOGAF 8: extend to include applications and data on top of the IT-infrastructures
- TOGAF 8.1 (‘Enterprise Edition’): extend to include business-drivers for the IT-applications, data and infrastructures
- TOGAF 9: extend to include clustering into capabilities, security concerns, and impacts of IT-changes (cloud, big-data etc) on business-drivers
In short, TOGAF and its ilk have arisen as an ‘inside-out’ view, looking outward at more and more of the rest of the enterprise, but always from the perspective of IT.
This type of enterprise-architecture provides a direct career-path for IT-professionals, because IT-oriented skillsets will be required and extended at every level and every expansion of scope of the work. In seeking employment in this space, some key distinctions to watch for include:
- explicit mention of a technology in the role-title (e.g. ‘Siebel Enterprise Architect’): specialist skills in the respective technology will be essential, and are likely to be viewed as more important than generalist skills for ‘connecting the dots’ across domains or technologies; also likely to be delivery-focussed (often short-term) rather than architecture-focussed (cross-domain / longer-term)
- ‘Enterprise Architect’ with emphasis on project-management in the role-description: likely to be a solution-architect role (project-specific), or even technical project-manager role, rather than enterprise-architect (cross-project or cross-portfolio)
- ‘Enterprise Architect’ with a grab-bag of technologies listed in the role-description: often turns out to be a junior-position role tasked with project-level ‘tidying up the mess’ between over-siloed specialists, or a ‘random-wishlist’ thrown together as a response to crisis – either way, usually a role that’s wise to avoid
Also watch out for the ubiquitous problem of ‘title-engineering’: a role will often be labelled as ‘Enterprise’ or suchlike to make it sound better or more important than it actually is.
True enterprise-scope IT-architecture roles do exist, but they’re relatively few and far between: always check the role-description in recruitment-ads, or else use alternate channels such as in-person recommendations to find appropriate work in this space.
Whole-enterprise architecture tends to emphasise:
- ‘enterprise’ as noun, as the scope itself – the architecture of the enterprise as ‘enterprise’
- a focus on ends, on why things are done – often with explicit emphasis on abstract rather than concrete form
- an ‘outside-in’ or ‘outside-out’ perspective – often focussing on customer-journey or ‘joined-up view’ (‘outside-in’) and/or the overall enterprise-context in its own terms (‘outside-out’)
- everywhere and nowhere as ‘the centre’, all at the same time – explicit avoidance of emphasis on or bias towards any single domain
In essence, ‘enterprise-architecture’ here is a literal ‘architecture of the enterprise’ that, by definition, needs to cover all aspects of the overall enterprise.
Enterprise-architecture in this form is not an ‘IT role’ – it will and must include IT in its scope, but on an equal footing with everything else. (The implicit IT-centrism of the other category of enterprise-architecture causes serious problems for this type of work: it is essential here to break free of any bias towards IT – or any other domain, for that matter.)
These enterprise-architects will work with or within a team that’s typically attached to a strategic-level business-level unit, and will usually report either indirect or direct to the CEO and executive-board. (Note that because of conflict and confusion with the IT-oriented form of enterprise-architecture, the team will usually not be described as ‘enterprise-architecture’: a conceptually-equivalent alternative term such as ‘business-transformation’ or ‘strategic guidance’ will more likely be used instead.)
Business-architects are sometimes equated with enterprise-architecture of this type. In practice, however, business-architecture tends to be a distinct domain in its own right – ‘the architecture of the business of the business’, focussing on business-models, financial-architectures, organisational-structures and suchlike – which requires its own specialist skillsets. It also tends to hold an ‘inside-out’ view of the enterprise-context, centred around the business’s own perspective, rather than around IT. Whole-enterprise architecture must be able to balance the ‘inside-out’ view with ‘outside-in’, in order to fully model – and advise on – the organisation’s interactions with the broader shared-enterprise.
Although many who work with this type of enterprise-architecture do come from IT-oriented disciplines, the career-path is not necessarily direct from IT: in fact they may come from any professional discipline at all. Specialist skills are relevant, of course, but here there needs to be far more emphasis on generalist skills:
- the ability to connect and work with people at every level and in every domain of the enterprise
- the ability to learn fast the basics of different disciplines, functions and processes
- the ability to summarise and visualise across different spaces
- the ability to balance contradictions and conflicting views and viewpoints
- the ability to balance between strategic, tactical and operational views, across multiple timescales
- the ability to assess a context in terms of patterns, systems and inherent-uncertainties
- the ability to connect-the-dots across all of the spaces, domains and views
In seeking employment in this space, be aware that there are almost no ‘jobs’ for generalists of this type (or any other type of explicit generalist, for that matter). Almost all listed ‘enterprise-architecture’ roles are for IT-oriented architecture only, which can be more of a hindrance than a help in this context. The usual options to find this type of work include:
- from an existing role, build personal connections with others working in more abstract or strategic contexts, such as business-strategy or portfolio-investment
- seek a role with a generalist-oriented consultancy – preferably one not focussed on the IT-space, so as to gain broader-scope experience in non-IT domains
- set up as an independent consultant – usually only viable with existing consultancy-experience and an established reputation
Bear in mind also that at present – unlike for enterprise IT-architecture – there are almost no standard frameworks or methodologies for this type of work, and in some ways certifications from IT-architecture can be almost worse than meaningless here. It can therefore be a real challenge to prove competence and aptitude for this type of role without an existing track-record in this discipline: the classic trap of “can’t get a job without experience, can’t get experience without a job”. Often the only practical way to avoid that trap is to develop a peer-reputation by contributing to and learning from conferences and on-line lists: but whichever way we do it, it does take significant amounts of time – usually measured in years, if not decades.
Both types of roles – IT-oriented, and whole-enterprise – are ‘enterprise-architecture’: but they are not the same, and the skillsets they require are also not the same, so it’s very important not to confuse one type for the other.
In principle, whole-enterprise architecture also encompasses IT-oriented architecture, and in some contexts might be viewed as an extension of IT-oriented architecture. In practice, however, there tend to be significant differences between the two types, in terms of mindset and working-methods; whole-enterprise architecture tends also to be more strategic and abstract in its focus, whereas IT-architecture tends to be more tactical and concrete, focussing more on IT-specific execution of strategy rather than strategy itself.
In short, once again, both types of ‘enterprise-architecture’ are valid, but they’re not the same: don’t mix them up!