In a recent LinkedIn discussion within the LinkedIn group “Operating Models” there has been a good thread about ways of drawing operating models, methods used to draw operating models and the definition of what is an operating model. I recommend the thread.
In this blog I want to share one response to a proposal I made that we interpret the term Business Architecture as meaning the same as the term Business Model. In my understanding, both terms include as one of their elements, the operating model. This response from Steve Kerzman provides a lucid alternative view. Thank you Steve: as always apologies for the edits.
“I don’t agree with you Andrew. I would argue that Business Model and Business Architecture are two different things, although I have seen some people include the former under the latter.
My experience of the term Business Model is that it is most often used to describe the strategy for how a business will make its money; e.g. we’ll sell razor blade handles cheaply at little profit and then make our money on the supply of the blades to our ‘captive’ market of customers owning our handles that are incompatible with other blade suppliers. As such I see it including a strategic definition of things like markets, customers, channels, products/services, pricing, etc.
In my version of model hierarchies a business architecture takes these and other statements of strategic intent as inputs and interprets them in terms of what operational business capabilities and value chain(s) will therefore be required to successfully achieve the vision/strategy. Business architecture deals with a number of dimensions such as processes, metrics, organisation structure, technology, etc. As such I tend to see business architecture and target operating model as largely synonymous concepts….although I’m sure others may see it somewhat differently. [So Steve is suggesting that the term business architecture is similar to the term target operating model and that its starting point is a business model/strategy. Whereas I see business architecture covering business model as well … if fact I consider an operating model to be one of the parts of a business model]
“Continuing down the hierarchy, I see detailed business processes, ways of working and the like, which may have been defined using value stream mapping, BPR and other analytical assessment and redesign techniques, underpinned by what-ever management philosophy and tool-set is most appropriate or preferred (e.g. Lean Six Sigma and DMAIC). These most often are accomplished in a programme of related projects, each of which will implement their portion of the relevant procedures, systems and other artefacts, all of which are made coherent by the overarching business architecture or target operating model. [I think we agree here – the broad business processes are defined using tools like value stream mapping and then the detail is worked out in projects that should be part of a bigger programme. The bigger programme is kept aligned by the overall model]
The business architecture in turn also provides the upwards assurance that the delivery of project outputs will collectively correspond and add up to the outcomes defined by the original statement(s) of strategic intent. These are often expressed as elements in a business case elements. These elements are part of the terms of reference of each project as administered by the programme.
I also agree that the term ‘architecture’ is generally poorly received and understood by most management team members who tend instinctively to place anyone using it in a sort of ‘techie nerd’ pigeon hole. Their next reaction then often being to shunt said person off to talk to the IT guys…..and that ‘labelling’ unfortunately frequently also has the related effect of reducing that persons ‘business’ credibility with the board and other senior management. [We agree here, although things may be improving]”
What I like about this contribution is that it illustrates well the language and definition confusion that we are in. I think everyone is talking about the same stuff:
– you have a strategy that focuses you on certain products and markets and channels and pricing and value proposition;
– to deliver this strategy you need capabilities;
– the capabilities involve processes, people, technology, locations, buildings, machinery, working capital, brands, suppliers, etc;
– finally the people require organising into structures.
All of this thinking needs to be done at a high level and at increasing levels of detail until you get down to the lowest level of detail such as sentences in job descriptions or code in software applications or terms in contracts with suppliers.
What we all find difficult is to develop a set of words for describing this stuff that is not obscured by jargon that it is hard to absorb or so constraining that it gets in the way of innovation and uniqueness.