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?

Tagged with: , , , , ,
Posted in Business, Enterprise architecture, Uncategorized
5 comments on “Enterprise-architecture – let's keep it simple
  1. Joe G says:

    How would you organize your Business Architects? Would they have specific domains, such as high level processes (order to cash)? Or would they have organizational domains? Or both? Not have domains?

    In my current understanding, and I am in now way as studied as others, is that I would organize my Business Architects into high level business process domains, much like I would organize technology architects into technology domains. There may be ‘cross process’ business architects that are more focused on business models and organization as well.

    Thoughts? If I’m way off please be blunt. If I’m not way off I may be figuring this out. :)

  2. Joe G says:

    ugh, that’s “in no way”.

  3. Business Architecture, Organizational Architecture, Information Architecture shake hands but are distinct children under the Enterprise Architecture. Sometimes they play well together, sometimes they don’t. The Enterprise Architect is the therapist who can show them all how to play nice in the sandbox.

  4. Tom G says:

    @Joe G - You’re not way off. :-) Pat gives a very good summary, in her comment just above, of the kind of structures and relationships between the different domains: there’s a lot more to it, of course (as Pat would tell you), but that’s a good place to start.

    The one thing I suspect you may have missed, though, is the really important distinctions between role-categories for architects: solution-architect, domain-architect, enterprise-scope domain-architect, and enterprise-architect. (The original version of that schema is from Len Fehskens: you’ll find a pointer to his initial article on this, in my post ‘What do we mean by business-architecture?’.) Your comments above suggest that you may be blurring the roles of business-oriented domain-architects – who you might well organise into ‘high level business process domains’ – with the roles of enterprise-scope business-architects – who must be able to cross all sub-domains of ‘the business of the business’. The enterprise-architect role is different again, bridging between ‘the business of the business’, operations, IT, security, quality, facilities, logistics and everything else that happens in the organisation and its relations with the broader shared-enterprise.

    Hope that makes some sense, anyway? – and thanks for joining-in to the discussion.

  5. Joe G says:

    Hi Tom;

    I appreciate your answer greatly because it confirms my thought that business architects can be domain-specific.

    I appreciate Pat’s response as well, and I agree with that 100%. I’m refering to lower level domains/processes as part of business architecture (think of domain as OtC process).

    I think there is room for both cross-domain business architects separately from enterprise architects. This is because enterprise architects, while inherently are cross domain, concern themselves with more than just the scope of the business archiecture. A cross domain business architect would still be in the scope of business architecture.

    So, business architects can be domain-specific or cross-domain, but they still practice business architecture which is distinct from enterprise architecture.

    As far as enterprise-scope business architect, by using the term enterprise in this way I think we risk overloading the term enterprise. It also provides you with two descriptors: enterprise-scope, and domain-specific, which is One or All, with no room for Some. That’s why I prefered the term cross-domain (or cross-process).

    Good conversation. I’d have responded sooner but it appears client caching prevented me from seeing your response. Did I just break the rule about discussing technology in an EA discussion? ;)

    Thanks!

1 Pings/Trackbacks for "Enterprise-architecture – let's keep it simple"
  1. [...] 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. [read more] [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Books by Tom Graves
Ebooks by Tom Graves
Categories
Archives