Enterprise-architecture – let’s keep it simple

Oh not, not again… looks like the Open Group members are about to muddy the enterprise-architecture pool once more, this time around business-architecture… Please, please, we desperately do not need another taxonomy-disaster like the infamous ‘four architectures’ of the ADM: please can we get it right this time? Please can we keep it simple instead?

Yes, I know I’m probably over-reacting again, but this was the set of tweets from the current Open Group conference in Austin that triggered this off, including a reference to something new from Open Group apparently called the Business Architecture Method Framework:

• LarsHouge: Could it be a good idea to include an information architect in the work related to the Business Architecture Method Framework? #ogaus
• LarsHouge: The BA definition was good, but it seems like the Method Framework is less mature, ex. a clear link to the BMM stuff. #ogaus #entarch
• systemsflow: Interesting #bizarch Q&A comment: Biz arch is as much about connections between orgs as about the orgs themselves. #ogaus #stillparsing
• systemsflow: Another comment in the #bizarch track. Let’s avoid EA landgrabbing and competing with MBA-type biz strategy field. #ogaus
• systemsflow: Interesting #bizarch debate during Q&A.  Does #EA = #bizarch + #techarch?  Or does #bizarch include technology as well? #ogaus
• systemsflow: Q: What do biz leaders expect from #bizarch?   A: Nothing, because they don’t know what it is.  (Because we can’t tell them!) #ogaus
• visualmodeling: IBM’s Kevin Daley: A well-defined biz arch covers strategy, technology, & operations domains + governs their intersection. #ogaus

Kris Meukens and Pat Ferdinandi gave good answers to the ‘MBA’ question:

• krismeukens: RT @systemsflow avoid #entarch landgrabbing & competing w MBA-type #biz strategy #bizarch  #ogaus < circular rather than linear causality
• thoughtrans: UGH! Are you sure those are business architects? Or are they MBAs who … because they have an MBA are considered a business architect? (sorry…that’s my current rant on certifications)

But I’ll admit that some of this worries me a lot. For example, how can it not be obvious to everyone that connections between organisations must be a central theme in business-architecture, just as it is in enterprise-architectures? And whilst I haven’t seen ‘the Definition’, I would definitely agree with @systemsflow here: we should long since have gone past any question about “does #bizarch include technology as well?” The short answer, of course, is ‘No’: but the fact that people above are still talking about ‘technology and operations domains’ as if they’re included parts of business-architecture suggests very strongly that there’s still way too much confusion between the distinct roles of enterprise-architecture, business-architecture and all the other domain-architectures that we work with in business…

I’m sorry to have to reiterate this, but it needs to be understood everyone that whilst the TOGAF ADM does work well for IT-architectures, it has a number of fundamental flaws that mean that it should not be used ‘as-is’ beyond that scope. (I’ve described in several places how we can adapt it for use beyond an IT-specific scope: although quite a few people do use those extensions now, it’s still not yet part of the ‘official’ standard.) The most important flaws are the fixed ‘four-architectures’ of Phases B, C and D in the ADM – business, applications, data, IT-infrastructure – and the way in which it treats ‘business-architecture’ as a scrambled, undifferentiated, unintelligible mess of ‘anything not-IT that might affect IT’,with little if any connection to business as such. And the blunt fact is that Open Group is an IT-standards body: that’s its reason to exist, to “make standards work” in the realm of “boundaryless information-sharing” – but not necessarily anything else. It is very good at what it does, but it is not an architecture-body as such, especially not for outside of the relatively narrow domain of IT: and that fact is becoming all too evident these days. So I’m very, very wary of any ‘definition’ of business-architecture that might come from Open Group.

Instead, could we perhaps keep it much, much simpler? Please?

To do this, let’s go back to first principles,using the words themselves, and nothing more. (I’m using English here, but the same principle works just as well, if not better, in most other languages.)

Architecture: it’s about structure, creating structures that people use. Hence any definition we develop about architectures is going to be something about structure, and about people. (Technology enables architecture, but not is architecture: a rather important distinction…)

Enterprise: it’s not a business, it’s a commitment. It’s about emotion, feeling; about ‘the animal spirits of the entrepreneur’, and so on. In practice, at a collective level, it’s about how people come together to share their aims, and ways to achieve those shared aims. Hence enterprise-architecture is about the structures that people use to achieve their aims. Enterprise provides the ‘Why’ for what we do and how we do it.

Business is part of that: people do business with each other as a way to achieve their respective aims. Hence business-architecture is about the structures that people use to do business with each other, in support of their aims. Markets are obvious examples of structures that provide common space to do business; the law of contract is another kind of structure in that space; likewise exchange-mechanisms such as fiat-currency (money) and credit-cards, and social structures such as the ‘investor/beneficiary’ model that underpins so many commercial organisations. For an organisation, we could also say that its business-architecture is the architecture of ‘the business of the business’. And since it’s about how we achieve aims, clearly it comes under the overall umbrella of enterprise-architecture.

Security is about feeling safe. Hence, in an organisational sense, security architecture is about the structures that people use in order to feel safe whilst achieving their aims. For an organisation, clearly that too is part of its enterprise-architecture, but it’s kind of orthogonal to its business-architecture. In other words, architectures are not necessarily ‘layered’ – as in TOGAF – but intersect as a kind of multi-layered, multi-faceted Venn diagram.

Brands denote stories; likewise for other symbols of that kind. Within an enterprise-architecture and a business-architecture – but not necessarily in a layered way, as such – a brand-architecture is about the structure of how stories link people with their aims. The enterprise is a story: brands and the like form a key part of how we create that story. Brand-architectures are primarily enclosed within our business-architecture, but may well extend beyond: from the perspective of the shared-enterprise, for example, we are custodians of a brand, not the ‘possessors’ of it.

Processes are descriptions of what we do, in what sequence, and so on. They’re the ‘How’ of what we do. So process-architecture is about the structures of how people organise what they do to achieve their aims. Notice that this doesn’t inherently specify the ‘How’ of the ‘how’: it could be people, IT, machines, or any combinations of those. (‘Application-architecture’ is a specific subset of process-architecture where the ‘how’ is hosted on IT.) If we take Chris Potts’ aphorism that “people don’t appear in our processes – we appear in their experiences”, then it should be obvious that ‘process’ is both within and beyond our own organisation: always part of the enterprise-architecture, but not always solely enclosed our own business-architecture. In other words, another intersecting, interdependent set within this overall Venn-diagram of architectures.

We could say much the same for information-architecture: it’s about how people structure the information that they need to achieve their aims. Infrastructure-architecture is more about the ‘What’ of the enterprise: it’s about the structural ‘things’ that people use to achieve their aims. And so on, and so on, for all the myriad of other domain-architectures under the overall enterprise-architecture umbrella that links all of those disparate domains together.

There’s nothing complicated about this. There’s also almost nothing specific to IT about it; or money either, for that matter. It’s always about people, and about structures that help people to achieve aims. That’s it.

So let’s keep it simple? Please?