Over the last couple of years, I’ve read a number of posts by Nick Malik around his Enterprise Business Motivation Model. I’ve also had a look at the Osterwalder and Pigneur Business Model Generation effort. Nick tried to reconcile Osterwalder’s Business Model Canvas with the EBMM with this post, and raised some interesting architectural points.

This, and a twitter conversation with Brenda Michelson and others gave me the impetus to form an overall view of how I see enterprise architecture and what I’ve written up previously as business DNA. Part of this is to again explain what I see enterprise architecture is (specifically where it sits vis-a-vis the business), part to form the basis of an approach to businesses that demonstrates how enterprise architecture can be of value to them (i.e. my pitch).

Yes, there’s a diagram. It’s based on Malik’s EBMM, and his reconciliation of Osterwalder’s BMG Canvas. It’s obviously “bigger” than the business model canvas, and unlike Malik I’m not trying to describe the architectural information model.

I do however attempt to describe the major elements of a business architecture and where they fit with each other. I have to say up front that this diagram has neither the rigour nor the depth of the EBMM – partly because I’m just at the beginning of the process, partly because I’m not re-inventing anything; where other models have what I think is a good fit at lower levels I’ll use them in more detailed explanations.

Note too that “enterprise” doesn’t imply a minimum size (whether measured as revenue, employees, geographic spread etc.) – I like Nick’s idea that an enterprise is a collection of one or more business models, and our analysis of the enterprise is independent of the legal entity or entities established around it.

An example from my own experience: a diversified manufacturer that had grown via acquisition from a strong core business. By the time we were called in, the “enterprise” consisted of 17 legal entities: a holding company and fully- or partly-owned subsidiaries. Our engagement identified one business capability model and four business models (some of which covered multiple legal entities). Each business model had its own operating model; in practice all four business models had picked the same operating quadrant; in different circumstances there may have been differences there as well. Why a single capability model? So the enterprise knew what capabilities it could call on in total; we overlaid the different business models over the capability model to show which capabilities were used by which business. Having a single capability model also allowed this enterprise to recognise that their organisation structure was no longer best suited for the business models and capabilities that they had developed or acquired over time. It also highlighted overlaps and gaps across the business models for some capabilities, and made discussions about which capabilities were differentiators or not much easier.

Why only four business models, and not seventeen? To a large extent, the legal entities involved are not germane to the description of the architecture. Several of the legal entities shared a business model, which (in practice) would be applied/exercised in the same way in those entities – so these entities could share a technology roadmap (even if individual implementations followed a different timeline), or unearth merger opportunities. In the event of further acquisitions, it could identify the most appropriate vehicle – integrating a new investment is easier if there are similar business and operating models.

I’ve also delineated the parts of the model that I see as describing business intent and business design – terms taken from the architecture framework I’ve been using.


  • The diagram is not complete (I just needed to get that out for all those of you who also recognise its incompleteness) – it’s a work-in-progress.
  • In case it wasn’t obvious, I like the EBMM – I think (especially for practitioners) it’s a good theoretical base to work from. I believe it suffers from its technical bent; it’s not an easy thing to put in front of business executives and expect understanding and acceptance (and in fairness, I suspect that isn’t Nick’s intent with this form of the model). I also think that the business model canvas works for generating new business models; but from an enterprise architecture perpective, Nick’s translation of it picks up the missing pieces.

Comments are welcomed; be gentle 🙂