Business Model and Business Architecture: Synonymous or Dissimilar?

When I read Tom Graves’ (@tetradian) post Who is the customer? published on July 14th, 2011, it was not the first time that I thought: “Hey, wait a minute. Using business model and business architecture interchangeably is not right.”  But did I expect Tom to do so?  No, not at all.

So when I noticed Chris Potts’ tweet (@chrisdpotts) the next Friday:

@chrisdpotts @tetradian Let’s not confuse business model with business architecture. Our business vs how we are structured to achieve it. #entarch

I could only join him in surprise.

I was even more surprised with what followed. Many reactions on twitter and blogs, most asking for further clarification.  What two characters, a ‘+’ and a ‘1’ can cause on a Friday…

Tom’s response with What do we mean by ‘business-architecture’? was one of disappointment, but also a lot of curiosity about what  –  the hell? :-)  –  we were thinking:

@tetradian @chrisdpotts @krismeukens to me it sounds like you’re mixing BA with EA? – expand/explain, please, perhaps with blog-post?

With that last tweet, Tom has brought a fundamental question to the surface, one that I believe is long overdue and that I am really excited about.  So I was not disappointed at all by his response to our criticism but a bit surprised by his thinking because he has been driving so much debate with regard to other fundamental questions.  For example, I just love the debate that he has set in motion about the distinction between the organization and the enterprise, and admire him for his persistence in defending his stance.  His thinking is far from mainstream yet. But with his passion for enterprise architecture, which is second to none, there is no doubt that his voice has become influential.  But I also believe that the distinction is far from fully clarified yet and that it is root to our ongoing “business model versus business architecture” disagreement.

Maybe I am missing details.  I am not fully aware of all that Tom has ever written. To be honest, I do not read all his posts and rarely completely.  Tom just writes way too much for the time I have available.  Sorry Tom.

Anyhow, whatever my following responses, I do not expect that Tom will have to say: “So that nailed it.  I was totally wrong.”  I am not seeking any truth but have developed a perspective that I think is worthwhile to share.

Of course, Tom is right.  A business model is business structure. Moreover it is significant structure, hence even by my own small attempt to more definition of architecture described in Architecture and the Remainder of Design, business architecture.  But does that make the terms interchangeable?  I believe it does not.  It are key nuances that get lost that way.

I was quick in starting to draft an answer but I quickly found out that a full response would take a very very long post. In fact the more I thought about it, the more I began to see as relevant for clarification of my perspective. The conclusion is that my answer will not arrive quickly. Instead I will explore answers to more fundamental questions first.

At the core of this dispute, I do consider the continuing fuzziness in what not only makes the enterprise and the organization distinct, but the business as well.

The opening sentence of the “business” entry Wikipedia says it all:

“A business (also known as enterprise or firm) is an organization engaged…”

If there is so much confusion between what is the business, the enterprise and the organisation, how then can we meaningfully distinguish between what are their respective architectures?

I cannot count the times that I have people heard trying to clarify the relationship between these concepts, also myself, each time different, not a single time without a lot of fuzziness.

So a first will be my attempt in exploring what I will call the enterprise continuum, in Making Sense of the Enterprise Continuum.  The post will kick off a renewed attempt to write more regularly.

Enterprise Agility, an Attempt to Get to the Bone

A while ago I got involved in following little Twitter conversation:

@pauljansen: RT @umairh the more unpredictable the world gets, the less valuable your cleverest strategy becomes < unless you go for agility

@krismeukens: @pauljansen agility requires predictability, agility comes through choices for longer term, hence one needs to foresee needed flexibilities.

@krismeukens:@pauljansen agility is about getting rid of flexibilities one does not require, which flexibilities?

@pauljansen: @krismeukens agility is ability 2 move quickly when change requires swift fundamental adaptation, it’s a competence, not a specific action.

Not only did this little discussion show me the limits of Twitter conversation in making a point, it also provoked some further reflection and an effort to write a post …

Agility

Ask a bunch of people what ‘agility’ means and how to get increased agility, and you are likely to find as many explanations as people.

The troubling consequence is that the concept of ‘agility’ is often turned down as being valuable or even worth discussing, and classified under “just another hype”. That is unfortunate as agility is really a fundamental ‘enterprise’ concept that deserves serious attention. But before that can be accomplished, its meaning and the path leading towards ‘increased’ agility should be clear.

In getting to the bone, I am in favor of returning to the original meaning. After all, it is an English word that can be looked up in the dictionary; not a brand name, although some, if it would be theirs, would like the idea.

A look-up in Oxford English Dictionary reveals the following:

agile
able to move quickly and easily

A look-up in Merriam-Webster Dictionary brings forth:

agility
the quality or state of being agile

agile
1. marked by ready ability to move with quick easy grace
2. having a quick resourceful and adaptable character

Agility as a ready ability

The words ‘able’ and  ‘ability’ hint, indeed, to competence; the competence to swiftly change even when change is fundamental, with hardly any ripple effects so to speak. Whether that competence is either high or low can eventually mean the difference between succeeding or failing.

The paradox is however that competence naturally is enemy of change. How can that be, you ask?

Ten years ago Seth Godin wrote a classic article “In the Face of Change the Competent are Helpless” about that disturbing fact. I urge anyone to read it.

The reason is that competence is built by factoring out variance, by casting in stone how things should be done over and over, to reach the same quality standards over and over. Once a competence is in place, high impact or abrupt change will destroy it. Naturally, sustained competence can only cope with slow-paced change.

The bitter consequence is that the options for abrupt change in competent enterprises are usually very limited.  Any of possible efforts to realize high impact change without destroying competence will simply take too long, will come too late to yield relief:

Agility as a quality or state

Luckily Merriam Webster mentions other words that provide further clues. Agility is the quality or state to be agile, hence indeed not an action.

But the path towards ‘increased’ agility is inevitably full of it. Increased agility asks for reaching a better ‘fit-for-future-purpose’ state by resolving above paradox, thus action. Without action, no reaching.

Resolving the paradox is about transforming the enterprise, moving it into a state in which minimal enterprise structure change, hence non-disturbing change, can result in abrupt high-impact enterprise operation change. In fact configuration options, realizing the quick resourceful and adaptable character, are to be embedded into competences, competences which inevitably become less specific. Once in place, competences can be reconfigured to realign with an evolving environment with the desired results. Let it be clear that the inclusion of the capability of configuration has a profound effect on Architecture and the Remainder of Design:

The action should also be focussed on working on what seems yet another paradox: Agility increases by reducing change options.

In fact much of found change options in enterprises are non-differentiating. It are options that lead to variance and personal judgement and that do not contribute to a well-shaped ‘lean’ enterprise.

The imperative is to determine what change options do not really matter and are in effect counterproductive, to identify inconsistencies between current and possible future states, and with that knowledge in mind, build core competences with embedded configuration options where necessary. Next one can drive efficiency to the extreme after which natural slow-paced non-disturbing evolution is considered sufficient for any of the desired future states.  That way possible future states are brought closer in line with current state, even when, being observed from the operational side, they appear fundamentally different.

Outcome

Fortunately being the easier part, reducing change options is a good start.

From there, strategic choices regarding alternative future states are to be made and needed configuration options to be derived.  As those choices are about the future, the act of prediction is never far away. So does agility require predictability? My answer is: Preparation for any change is preparation for no change.

However do not forget about velocity as Seth remarks!