Business-architect or enterprise-architect?

A great Twitter-conversation yesterday with Chris Potts and others on one of these near-interminable boundary disputes in enterprise-architecture. 🙂 It started with a Tweet from Chris, and kinda snowballed outward from there:

• chrisdpotts: Note to job-description writers: “Enterprise Business Architect” is tautologous.  A business is a type of enterprise. #entarch
• tetradian: “‘Enterprise Business Architect’ is tautologous” – disagree slightly: to me BA is arch of business-models etc, not whole enterprise <I regard business-architecture as about the ‘business of business’ only – i.e. a domain-architecture, not whole-of-enterprise architecture
• flowchainsensei: Is anyone in the real world likely to understand the job title(s) – let alone the fine(?) distinction? I say not.
• chrisdpotts: What do you include in the actual architecture (not models) of an enterprise that’s a business, that the word ‘business’ omits?
• tetradian: I distinguish b/w enterprise and org http://bit.ly/8wWNSq whole-enterprise is context of business (like bizarch is for IT-arch) // bizarch=that which we ‘control’, whole-enterprise includes ‘beyond-our-control’ e.g. supply-chain, community, anti-clients etc
• chrisdpotts: I think you are saying that business=organization. Is that correct?
• tetradian: bizarch vs whole-ent arch probably needs lengthier explanation – do you need me to do blog-post on this, and if so, how urgent?
• tetradian: business=organisation – largely, yes – point is that it’s an entity with legally-bounded responsibilities, but enterprise isn’t //  a business is a type of enterprise, but an enterprise isn’t necessarily a business // general rule-of-thumb I use is that the enterprise in scope for a business is 3 steps larger than the business itself // ‘3 steps larger’: 1.supply-chain 2.customers/prospects 3.non-clients/anti-clients/government/community (4.broader ecosystem)
• chrisdpotts: No need for the blog post, thanks. A business cannot exist without its relationships with other parties (legal and informal).
• chrisdpotts: As far as the outside world is concerned, those relationships and how they are conducted, are the business’s architecture. // (Outside-In versus Inside-Out views of architecture)
• tetradian: I separate bizarch vs whole-ent-arch b/c need different skillsets: biz-models/finance (compete) vs broad-scope generalist // to use your terms, bizarch (in practice) tends to be Inside-Out, whole-ent must be Outside-In
• chrisdpotts: Got you.  Thanks. // Then there’s Gartner’s ‘middle-out’ architecture – which depends on what or whom you regard as the ‘middle’ of your enterprise.
• nickmalik: @chrisdpotts Re: “Enterprise Business Architect is tautologous.” No… it is a matter of scope.  Most BAs focus less than Enterprise.
• chrisdpotts: @nickmalik From that, it sounds like Business Architects need to widen their scope!
• Cybersal: @chrisdpotts @nickmalik I used to work in a team of 3/4 business-system architects who covered the enterprise between us

Okay, so Chris said “no need for the blog-post, thanks” above, but I think it’s worth doing a slight expansion on this anyway. 🙂

I honestly don’t have any problem with the term ‘Enterprise Business Architect’ – I think it’s an entirely valid description of an architectural role. Let me explain.

There’s a role called ‘architect’. This is someone whose job it is to link various things together in a consistent, integrated, maintainable and sustainable way – you know, an architect. Could be any area at all, any focus or interest: as long as it’s linking more than a couple of different types of items together, you could just about get away with calling the role an ‘architect’.

Often we’ll find there’s a prefix, specifying a technology, or a domain of interest, or something like that. Hence at the lower (i.e. more detail-level) end, we’ll see titles like  ‘Siebel architect’, or ‘.Net architect’, or ‘web architect’. Going up a notch or two, we’ll see more emphasis on the domain: process-architect, security-architect, data-architect, applications-architect, business-architect.

Each of these roles has a strong specialist element, emphasising the particular domain of interest, and usually a lot of in-depth knowledge and skills in that specialism. But they’re more than just specialists. They’re what we might call ‘T-shaped’: a lot of depth in one domain, but also a bit of depth in a range of other domains too – which is what gives them the ability to make links between domains, and hence is what makes them ‘architects’.

And each of these domain-architectures requires its own distinct skillsets, each with their own distinct terminologies and concerns – and the depth required is such that they’re often somewhat incompatible with each other, too. But an ‘architect’ is someone who can link across those incompatibilities – sort-of, anyway.

Then we’ll sometimes find that there’s a need for a scope-prefix on the name – of which the most common is the term ‘enterprise’, meaning that the work has an enterprise-wide scope. This scope-prefix, if present, should always come before the domain-prefix: hence ‘enterprise Siebel-architect’ is okay, but ‘Siebel enterprise architect’ is definitely not okay, for reasons that will become clear in a moment.

The point is that there’s a special-case, where it’s not that the domain has a specific scope, but that the scope itself is the domain. To use a term coined by David Armano, we could describe these architects as ‘sun-shaped‘ – they’re true generalists, linking across every sub-domain within that scope. And that’s a distinct skill-set in itself, radically different from the domain-specific skills of the ‘T-shaped’ domain-architects. The only person who should be called an ‘enterprise architect’ is one whose domain is the entire scope of the enterprise.

Which brings us back to Chris’ doubts about ‘Enterprise Business Architect’, and why I do think it’s an acceptable term.

To me a business-architect is a domain-specialist: someone who specialises in the architecture of ‘the business of the business’. These are typically people who’ve expanded outward from business-analysis (by which I mean ‘the analysis of business’ – in-depth financials and so on, not the IT-oriented notion of “someone who gets IT requirements from ‘the business'”). They’ve learnt enough of other domains to act as architects, but their real focus will be in ‘business’-type themes such as business-models, investment-planning, financial modelling and the like.

These business-architects are specialists, with distinct business-oriented specialist skills. A business-architect will typically work within one business-unit, or perhaps a whole company within a conglomerate; an enterprise business-architect is one who would cover the whole portfolio of the business-as-enterprise. But it’s still business-architecture, ‘the architecture of business’ – it doesn’t move much outside of that domain. For example, it wouldn’t usually cover IT-implementation, or detail-level process-design, or security or quality or any of the operations-level ‘-ilities’ – it’s about ‘the business of business’, and not much more.

But an enterprise-architect covers the entire scope: every domain, at every level. The role also covers a scope that can extend much further out than that of the business-architect. For example, a business-architect could get away with assuming that ‘the organisation’ and ‘the enterprise’ are one and the same, in classic Taylorist style; but an enterprise-architect must be able to separate them where required, extending the enterprise-in-scope beyond the legal-responsibility boundaries that define the organisation, to encompass the supply-chain, the market, the direct business-ecosystem (including non-clients and anti-clients), the community, government and sometimes even further than that. The time-scales may also be much longer than those of the business-architect: the latter may well be concerned with a five-year strategy at most, whereas environmental and other concerns mean that the enterprise-architect may at times need to consider an indefinite or even infinite timescale.

An enterprise-architect must also be comfortable working at any level, from the board-room to the factory-floor, from operations to tactics to strategy and beyond; and with concerns that may be deep within and/or far beyond the organisation itself. This demands a skillset that’s broad rather than deep, focussed on interconnections more than on item-detail, ‘holographic’ rather than ‘photographic’, an unusual ability to learn the basics of any skill or domain very fast indeed. This is a very different skillset from that of the ‘business-oriented’ business-architect. I don’t think I’ve ever met anyone who truly managed to combine both sets of skills in their personal portfolio, and I don’t think it’s fair to expect anyone to do so – especially across all of the complexities of a typical large organisation.

What worries me somewhat is that the role of business-architect is likely to become confused with that of the true enterprise-architect. We used to see – still see – a lot of IT-architects who called themselves ‘enterprise-architects’, yet who really didn’t have much of a clue about anything that happened outside of IT – and hence were walking disaster-areas as soon as they tried to tackle a true enterprise-architecture scope. Now that TOGAF and the like have finally woken up to the fact that business-architecture is not merely ‘anything not-IT that might impact IT’, but is a distinct domain and skillset in its own right, we’re at last seeing proper business-architecture starting to happen (or happen again, rather, now that IT-architecture is less in-the-way than it was…). But the trap is that we’re seeing exactly the same mistake being repeated at the business-architecture level: ‘business-centrism’ rather than the old ‘IT-centrism’. And unfortunately the old-style management models, stuck in their delusion that the organisation is the enterprise, feed right into that mistake…

One of the key facts about a true enterprise-architecture is this: the architecture has no centre. It’s not centred on the IT; it’s not centred on the business; it’s not centred on the shareholders, the customers, the executive, the employees, or anywhere or anyone. Everywhere and nowhere is ‘the centre’, always, all of the time. A domain-architecture is indeed centred on that domain (and arguably should be, too); but an enterprise-architecture has to cover everything, as exact equals, everywhere. That’s what makes it different. That’s also what makes it hard to do.

So yes, there’s a real role called the Enterprise Business Architect. It can be done by the same person who does the role of Enterprise Architect; but in practice it’s usually not a good idea to try to do that, because the skillsets that the roles require are so different from each other.

That’s about it, really. 🙂