Business architect and enterprise architect
This one started from a Tweet from Vince Outlaw, one of the attendees at the recent Gartner EA conference in San Diego:
- SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R Very timely as Enterprise Business Architecture is a HUGE subject at #GartnerEA
If you know me, you won’t be surprised that to me that was like a red rag to a bull. Yup, I admit it, I fulminated:
- tetradian: RT @SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R >Business Architect is _NOT_ an IT job!!! #entarch #fercryingoutloud..
- kvistgaard: @tetradian Well, let’s face it: it is! “Business” is misused in #BPM and Business Architecture, same as “E..” in #entarch. So really, Business Architect, nowadays, sadly, is an IT job.
Whilst Nick Malik dived in from another direction:
- nickmalik: RT @SMOutlaw: Hot IT job No. 1: Business architect http://ow.ly/5p44R >Business Architect is _NOT_ above EA either!!! #entarch
…and, later, expanded on this with a post of his own:
- nickmalik: [post] Different Specialties of Architect http://bit.ly/iRmtCE –> To reduce the arguments about #entarch
Which might well look like Yet Another Pointless Argument About Job-Titles… “Oh no, not again”, I hear you cry?
Actually, this is a serious problem, and all of those are valid responses, in their own ways. Enterprise business-architecture is a very important aspect of enterprise-architectures; done properly, it is definitely not an IT-role, but at present it is still all too often portrayed as such; and the relationships between the various roles have become very blurred, very messy, and very confusing, to the point where that confusion is causing a lot of damage to organisations and their business-related architectures – and to the profession as a whole. Oops…
The core of the problem is not merely one but two related term-hijacks:
- portraying enterprise-architecture as minor subset of IT-governance;
- portraying business-architecture as a kind of random grab-bag of ‘anything not-IT’ that might affect IT’.
The worst perpetrator of this, I’m sorry to say, has undoubtedly been the Open Group, aided and abetted by ‘the usual suspects’ – the big IT-consultancies and analyst-firms. All of whom have only just realised how much they’ve succeeded in getting themselves ‘hoist by their own petard‘, but have unfortunately caused (and are still causing) a lot of damage with their previous overly-myopic IT-centrism.
I hasten to add that some of the Open Group crew are well aware of the problem, and the damage that it causes. For example, the indefatigable Len Fehskens has been fighting this particular battle for even longer than I have: his blog-post ‘Enterprise Architecture’s Quest For Its Identity‘ is an absolute must-read for anyone involved in anything to do with enterprise-architectures. His nomenclature of roles is really useful here: xA, ExA, EA (about which more in a moment). In essence, the architect’s role consists of bringing things together into some kind of unified whole, for a chosen purpose. I’ve expanded on this a bit more in my earlier post ‘Making sense of architecture roles‘, but the key point is that to understand and describe the role, we need to understand both its scope (or ‘breadth’) and its direct skill-level (or ‘depth’). A domain is a region of scope and expertise: for example, IT-infrastructure, security, brand, organisation, process, logistics and so on. In Len’s nomenclature, ‘x is any specific domain:
- xA (e.g. applications-architect, brand-architect): a domain architect, with emphasis on a single domain or closely-related cluster of domains, almost always with high skill-level (strong depth) in that domain – i.e. deep, but probably not broad
(a solution-architect is usually a domain-architect assigned to a specific project or change-programme)
- ExA (e.g. EBA, ‘enterprise business-architect’; EITA, ‘enterprise IT-architect’): an enterprise-scope domain-architect, with emphasis on how a single domain links with other domains; the skill-level is sometimes referred as ‘T-shaped’, deep-skill in one domain, but sufficient of knowledge of other domains to able to support good ability to converse with other domain-architects and other specialists from those other domains
- EA: a specific domain-architect whose domain is the enterprise as a whole, and for whom the core skill-set includes cross-context specialisms such as systems-theory, human-factors, futures, strategy and other ‘big-picture’ themes; the skill-level across domains tends to be broad rather than deep (i.e. ‘comb-shaped’ rather than ‘T-shaped’), but must include all domains that are in scope for the enterprise
(Note that in most countries, by law, the only people who can describe themselves as ‘architects’ – without any other qualifier – are building-architects. Everyone else in all other cross-context-linking or cross-domain-linking professions must use some kind of qualifier – hence naval-architects, civil-architects, security-architects and, of course, enterprise-architects.)
What the Open Group have done in TOGAF is to completely scramble that nomenclature: routinely, an IT domain-architect or, at best, an EITA is labelled as an ‘EA’, with business-architecture – which should be a domain that is business-focussed and functionally distinct from IT – parked somewhere entirely arbitrary ‘under’ the IT-centric ‘EA’ banner. Hence that ‘business-architecture’ is simultaneously both ‘below’ and ‘above’ that ‘enterprise-architecture’, in several different utterly confused and utterly confusing senses. It is, bluntly, a mess – an unusable mess. And whoever it was that insisted on incorporating that mess into TOGAF 8.1 and TOGAF 9 should be quietly taken out and have their noses rubbed in that mess every single day until they themselves have sorted out the mess, because the end-result is that it’s made it almost impossible even for IT-architects to do their jobs, let alone anyone else.
So yes, Ivo and Patrick are right: it may well be true that ‘business’ architect is currently described as an IT role. But the blunt fact is that it really doesn’t help to do so: it just perpetuates the mess. Every one of us needs to be emphatic about this, because it is probably the primary cause of damage to the profession at present.
And yes, Nick is right, too: business-architecture is a distinct domain – the architecture of ‘the business of the business’ – that must not be seen as ‘above’ the scope of the broader shared-enterprise in which the business operates. By definition, it’s sort-of ‘under’ EA, because EA provides (or describes, or maintains, or whatever) the overall umbrella (or coverage, or network, or mesh, or whatever) under which (or through which, or within which, or whatever) everything connects with everything else. But when only IT-architectures are described as ‘EA’, then there are some circumstances in which BA or EBA is ‘above’ that kind of ‘EA’. Yet also circumstances when they’re not – given the way that TOGAF describes BA and EA. Which again adds to the mess…
Which is where we come to the second term-hijack in TOGAF and similar IT-centric ‘EA’: defining ‘business-architecture’ as ‘anything not-IT that might affect IT’. Reading the TOGAF spec – particularly the TOGAF ADM’s Phase B, ‘Business Architecture‘ – there is almost no distinction made between high-level strategy (whose main impact is at Zachman layers 3 and above), process-design (typically Zachman layers 3-4) and protocols and the like process-execution (typically Zachman layers 4-5): it’s all ‘not-IT’, hence all jumbled together into a kind of blobby blancmange with no functional meaning at all. Take a look, too, at the TOGAF description of ‘business scenarios‘ – somewhere around the Zachman layer-4 – and compare that to the business-usage of the term – which is more like Zachman layer-2. Hence, overall, no wonder that business-folk get seriously annoyed at IT-centric ‘EA’ and its daft description of ‘business’-architecture that makes no business sense.
So we have TOGAF – and just about everyone else in the so-called ‘enterprise-architecture’ space – describing an ‘enterprise-architecture’ that isn’t about the enterprise as enterprise, and a ‘business-architecture’ that has very little connection with the business of the business. Oops… not helpful…
So in that sense, no, I disagree with Ivo and Patrick: it may be ‘realism’ to say that “really, Business Architect, nowadays, sadly, is an IT job”, but it is definitely not wise to allow that misnaming to go unchallenged, because the consequences are very serious indeed. (The building-industry has long since discovered this blunt fact the hard way – hence the legal controls around the ‘architect’ term.)
And I also sort-of disagree with Nick – not from what he’s said as such, but more from where I know he’s coming from: when the business of the business is IT – as in his own business-context at Microsoft – it’s again all too easy to fall back into IT-centrism, and I do detect more than a hint of that in his follow-on post about ‘Different Species of Architect’.
Overall, though, I’d have to insist on this as a summary:
- business-architecture touches IT, but is not an ‘IT role’
- business-architecture is a domain-architecture – ‘the business of the business’ – and hence necessarily comes ‘under’ the broader whole-enterprise scope of enterprise-architecture
Any other way to describe the relations between business-architecture, IT-architectures and enterprise-architecture will merely compound the mess that TOGAF et al have already made of this profession. Sigh…
That’s my opinion, anyway. For what it’s worth. Over to you?