Two enterprise-architectures
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
IT-oriented enterprise-architecture tends to emphasise:
- ‘enterprise’ as adjective, as a descriptor for scale – 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
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.
Summary
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!
Thank you Tom for the inspiration. Allowed me to follow my thoughts and connected some of my statements clearer:
I personally believe that it is not important how you enter a company (EITA). In most cases it is more than welcome to provide holistic complete Enterprise Architecture service, but it is very difficult to find an organisation which is ready to hire that way or ready to truly use it that way.
Don’t Think You Are [an Enterprise Architect], Know You Are!
Nice post, Kai – thanks.
The point about “it’s not important how you enter a company” is something that came up in the panel-discussion at the BCS-EA conference earlier this week. Several of us felt that often it’s not that IT is inherently a ‘natural home’ for people who approach things in an holistic way, but more that it’s a place where those of us who do think that way can create a sort-of home for themselves – which they often can’t elsewhere. Hence we end up with both of those mindsets occurring in the same place: those who think ‘inside-in’ (IT-only) or ‘inside-out’ (IT in relation to everything else) and those who also (or prefer to) think ‘outside-in’ (everything in context of everything else). It can make for some interesting clashes at times… but at least it does mean somewhat less risk of lockstep-groupthink, which is sometimes a very real problem in other business-domains.
Hi Tom
thanks for summarising this,its good stuff. I could add a couple of small things from my limited experience.
1) EITA roles: these are sometimes advertised as IT Strategy roles. Because that’s what we’re really talking about, isn’t it? Inside-out directions for IT architecture to work with and in the partner “ecosystem” and possibly some thinking around the business models of the IT department itself. That’s what I’ve ended up doing. If you’re really lucky you get a bit of contact with the people doing the whole-enterprise architecture and they can feed their vision into the EITA as context (I’ve done a bit of this too). If you’re not lucky you have to guess it for yourself (also what I’ve ended up doing to an extent)
2) Whole-architect roles. Are these really CEO positions? Or “special adviser” type roles? Either way, you are right, you won’t see them advertised. The best way to get into one of those positions is to get a role that encompasses the whole-enterprise scope and build your influence from there. A colleague of mine has actually done this. Some example roles vary depending on the organisation but they might include corporate comms, strategy, “policy” or even HR as well as IT. Being parachuted in to a role with this cope and top-level influence and remit probably means having already been CEO somewhere else, built your own company or something of that ilk. Venture Capital perhaps?
Martin
Hi Martin
Good point about ‘IT Strategy’, and leveraging that as a means to move into a more whole-enterprise space. One thing that helps that process is the growing realisation that there’s actually no such thing as ‘IT Strategy’: whatever it looks like, no matter how technical, it must always identifiably be ‘Business Strategy’. That’s a theme that Chris Potts is particularly strong on: follow him on Twitter as @chrisdpotts.
On “Whole-architect roles. Are these really CEO positions?” – Chris Potts often suggests (such as in his book ‘recrEAtion‘) that the CEO is also, by definition, the Chief Enterprise Architect; so in effect the whole-enterprise architect role is a direct ‘delegated’ support for that responsibility. As for how one would get there, yes, I’d agree strongly with all of your suggested paths.
Tom, that’s a terrific post. If nothing else it helps explain what happened at a previous employer. I was hired as a “whole enterprise” architect, but the company reorganized and I was placed into an EITA role. No fit at all.
Hi Chris – and yep, it’s happened to me too… 🙁 (Oh the joys of corporate inanity… 🙁 😐 )
Spot on. All the roles I took as EA placed me into EITA :-). I wondered whether it was an ignorance in the part of organisation which recruits me or organisations are not mature enough accept an Whole Enterprise Architect. After long contemplations and discussions I left it as it is, because most of the times when a person invent some machine it will be used for something else other than what the inventor wanted it to be used for 🙂
Venkat: “All the roles I took as EA placed me in EITA” – yeah, all too true: certainly been my experience, anyway. In six years in Britain I’ve hardly seen a single advertised ‘EA’ role that wasn’t in reality just some flavour of EITA – the ‘term-hijack’ of EITA over whole-EA really is that bad. I take your point about “used for something else other than what the inventor wanted”, but I must admit that I do feel that this mess of misnaming has created one heck of a frustrating waste. There’s a crying need for whole-EA, but still a huge anti-want for it: people want their nice, safe, certain delusion of Taylorist ‘control’, and that’s what the big-consultancies’ version of ‘EA’ (aka TOGAf and its ilk) purports to offer, so we’re all a bit stuck with something that everyone now knows cannot deliver what it promises. Result: everybody loses, except for the scavengers (in the short-term, anyway…). There must be a better way than this, but I must admit that right now I don’t see a way past that barrier of delusion and incompetence. Oh well.
Agree with the first type which is in reality the enterprise IT architecture with the purpose of serving the enterprise IT strategy. BTW the catch word in the term here is “enterprise”. Not so sure about the second type, maybe it is another side effect on the misuse of trendy word like “architecture” 🙂 IMO they are the management strategists or consultants rebranded with the latest catch word.
Thanks, Max. Looks like we’ll just have to agree to disagree for the present about ‘EA=IT-architecture’, though I think you might be surprised at the scale of the shift when TOGAF Next (the upcoming TOGAF version 10) comes out: most of the recent comments I’ve heard from there are recognising that IT-architecture can only ever be a subset of the architecture of the overall enterprise.
There’s certainly an explicit recognition now that there’s no such thing as ‘enterprise IT-strategy’: there are only enterprise-strategies, which have varying degrees of IT-related aspects within them. (See Chris Potts‘ work on this, for example.) The continued attempts to somehow keep IT ‘separate and special’ relative to everything else in the enterprise – in other words, what we would call ‘IT-centrism’ – provide one of the key factors that cause failure of an enterprise-architecture. That’s why we’re very careful these days to keep EITA in its place – and not allow it to be mistaken for the literal ‘architecture of the enterprise’.
Tom – another great post on the real meaning of EA. Although I don’t think the term “Whole-enterprise architecture” will catch on (we really need to think of a better name!), you have captured the differences to IT-oriented EA very clearly. Although, I would think of the “outside-in” or “outside-out” perspective as simply the business perspective, i.e. the perspective of the business (not the same as the business architecture).
Technology is moving well beyond the bounds of IT departments and is becoming more and more an everyday part of nearly every department in the business. So, if we are not the CEO or near to the CEO (which is unrealistic for the majority), the whole-enterprise architect should find a role in the business where they can apply their EA mindset to real business challenges. Technology then becomes one of many different enablers to business challenges and strategies.
Thanks, Steve!
— On “we really need to think of a better name!” – yes, we do. Unfortunately the only correct name, in terms of ‘natural meaning’, is “the architecture of the enterprise”, aka ‘enterprise-architecture’ – which has been hijacked by the IT-folks for their much narrower scope. Sigh…
So in practice we’re forced to find another term with a close-enough natural-meaning, whilst the term that does have the correct natural-meaning continues to be used in a completely misleading way by someone else. Which is a continually irksome irritation and frustration, to say the least. And I admit I don’t have a good answer for that at the moment: right now we’re stuck with nasty kludges such as ‘whole-enterprise architecture’ or ‘real-EA’, to try to keep some semblance of connection to the required natural-meaning.
Terms such as ‘business-transformation’ don’t quite cut it, by the way: the natural-meaning there tends to imply some kind of one-off project, rather than a continual process of integration and strategy-to-execution-and-back-again re-assessment and reintegration, which is what we (would/should) have with ‘enterprise-architecture’.
— On “Technology is moving well beyond the bounds of IT departments and is becoming more and more an everyday part of nearly every department in the business.” – one of the themes I find so annoying in IT-centric ‘EA’ is the failure to grasp that in the enterprise we need to deal with many technologies that are could be described as IT (literally, ‘information technologies’) only in the most peripheral sense. (See my post ‘The egg-sorting machine‘ for one example.) The practical problem that arises from that is that people who are employed by the ‘IT-department’ tend to be very strong on skills and knowledge for working with information-systems, but tend to be a lot less strong on anything to do with physical aspects of technologies – which might anything from materials-science to the 4D-engineering of robotics (movement in 3D and time) to nano-engineering to bio-engineering and much, much, much more. Placing all of that under ‘the IT-department’, because it’s all ‘technology’, is pretty much a guaranteed recipe for disaster on a truly epic scale… We need a true integration across all of that scope – which is where a true whole-enterprise architecture comes into the picture.
— On “Technology then becomes one of many different enablers to business challenges and strategies.” – that’s one of the keys to this, yes. Another equally important theme is the ways in which new (and old) technologies feed into business-challenges, and can inform and create new options for business strategies. Yet another theme is the multi-way interaction between strategy, tactics, execution and organisational-learning. It’s hugely complex; it’s also what makes it hugely interesting. 🙂
Tom – well captured and articulated.
Interestingly, a client recently advertised for an EA, seeking a whole enterprise architect, and all the applicants were IT oriented architects.
The interesting question for employers who want the former is that the type of person they want would not be looking in the EA column of the job ads! What to call the position and how to find suitable candidates are interesting challenges!
@Peter: “Interestingly, a client recently advertised for an EA, seeking a whole enterprise architect, and all the applicants were IT oriented architects.” – :bleak-wry-grin: indeed… (Not surprised, though.)
On “The interesting question” etc – yes, exactly. 🙁 I’ve explored that theme somewhat in my series on ‘No jobs for generalists‘, but collectively we do need to do a lot more on this to make it more workable for everyone.
John Zachman once said that the reason EA came out of IT is because we’re the ones with the drafting skills. Point being, architecture is design. And most “business” people aren’t designers by trade.
I’m not sure if anyone will ever wake up one day and establish true EA where EA should be with the type of people true EA needs doing the work. It’s more likely that the best we can hope for is a continued evolution of EITA -> EA. Which makes some sense, given IT’s increasing pervasiveness in the business to the point where the two are becoming indistinguishable. (And I’m NOT being an apologist for IT-centric convolution of the term enterprise, only taking a practical view on how best to get us where we want to be.)
In my experience, more and more business people are warming up to the idea of explicitly designing the business independent of the design of IT systems – even if our immediate subsequent activities are merely to understand the business design’s impact on IT. It’s a start.
Thanks, Chris.
On “I’m not sure if anyone will ever wake up one day and establish true EA where EA should be with the type of people true EA needs doing the work” – I agree it doesn’t seem to be common as yet in the ‘large countries’, but we were already doing exactly that a good six or seven years ago back in Australia, with at least two clients of mine. There does seem to be a maturity-difference between the ‘large countries’ and the ‘small countries’ (e.g. Australia, Canada, New Zealand, the Netherlands etc) on this – and actually the opposite way round to what one might usually expect. It’s perhaps because there’s such a small technical pool in the ‘small countries’ that people are often forced to be generalists, just to get the work done, and hence the cross-enterprise skills that are needed in whole-enterprise architecture are a bit more readily available than elsewhere.
As you say, though, what’s happening elsewhere is definitely a good start. Let’s hope it continues on?