What’s in an Operating Model ?

This post is part of the ‘Architecture Models’ series.

This started out as a brief note but I’ve come back to it time and time again because it’s a complicated topic.  Most of the definitions that I saw of an ‘operating model’ were an organogram, an organisation structure showing who works for who.  Many of the people that I interacted with agreed that there didn’t need to be any more content in an operating model and so ‘HR’ should own and create it.  In fact, the IT platform that stores names and managerial relationships could probably display it for me if I wanted to see it.  OK, I exaggerate, but only a little.

It’s a question that is still debated in blogs across the internet.  The WordPress blog at Ashridge On Operating Models suggests that an Operating Model can be described by defining the enterprise’s ‘POLISM’ (processes, organization, location, information, suppliers and management system).

Whilst I agree that those are fundamental parts of an operating model, my view is that there’s more to an Operating Model than just ‘POLISM’.  That seems too constrained and fundamentals of how the business works would need to be documented elsewhere.  If I include those other fundamentals then I think that there are three pillars for an Operating Model:

  • the Financial Model of an organisation
  • the future of the organisation, as defined by its strategies and its saleable products
  • the Operations of the organisation that shows how the enterprise functions

and that these pillars sit on two foundational building blocks:

  • the principles for how the enterprise approaches its vision
  • a glossary


As an aside, Enterprise Architecture would seem to be the next level of detail that shows how each of the pillars interacts; a little like 3D chess but with more dimensions !

Architecture and Business Change

Most (all ?) of the EA frameworks exist to guide and structure change.  The TOGAF framework starts with a Vision for the future so it must be about change !  The implementation of that change, the delivery of that new Architecture causes the business to change.  I have seen many initiatives fail, not because the Architecture was wrong but because the business either didn’t want to change or wasn’t ready to do so.  It wasn’t the architecture that caused the failure but ‘the business’ itself.  I put ‘the business’ in quotes because architects often see it as some amorphous blob that is being changed, rather than real people with real emotions and skills.

Business Change is the discipline that encourages the business to change.  Business Change is about understanding the amorphous blob and encouraging it to change both from the inside and from the outside.  It’s about employee engagement, communcations, measuring customer experience before and after change and an awful lot more.  As architects, we traditionally deal with the ‘hard’ (as opposed to ‘soft’) change: changing processes and tools and organisations.  The mechanics of how they are changed is often not our concern, we just know that ‘the business’ needs to change and we’ve defined what it needs to change into.  Unfortunately, ‘the business’ won’t change unless the Business Change discipline is used.  It’s arguably more important than the architecture.  The reasons that many initiatives fail was a failure of Business Change.

There are plenty of Business Change frameworks out there, in the same way that there are plenty of EA frameworks too.  This is just one of them, taken from Google (http://www.sourcingmag.com/) and I make no assertion that it’s correct, complete or even well drawn but it does provide me with something to discuss:

Each time that I look over these, I think that ‘Business Change’ needs to be another bubble inside TOGAF.  It’s arguably part of Migration but the Business Change activities need to start during Vision so I think that it needs to be at the centre, in the same way that  Requirements is at the centre.  There are a lot of things that need to change in TOGAF so I’ll leave that debate for another day.  (Before you light the flamethrower: there are also a lot of things that are right in TOGAF too.)

I’ll go from left to right across the model, picking out the important boxes, starting with ‘Communication’.  Just saying that ‘Communication’ is important does its importance a disservice.  It’s communication that opens the way for change and it’s communication that faciliates change.  ‘Doing’ communication is hard though.  Finding the right messages and communicating them in the right way at the right time is both a science and an art.

The next box, entitled ‘Business Change’, contains a lot of very very difficult activities.  The words ‘HR Alignment’ are sufficient to chill the heart of anybody that’s been involved in a redundancy consultation process but it’s a necessary part of ‘Change’.  Employee communications, especially once they’ve understood what the ‘Change’ is supposed to be, is also difficult.  If that ‘Change’ message is not communicated successfully then the employees with the skills that need be retained start to disappear, either redeployed or through resignations.  Transition Support is also absolutely vital and often overlooked.  Whilst it can be an enjoyable experience for those supporting the change, it’s a tiring time for those that are ‘being changed’: another new system to learn, a different process to follow and new people to interact with.

Finally ‘Training and User Support’ is never given the importance that it deserves.  Too often it’s overlooked or left as ‘train the trainer’-type support.  After all of the money that’s been spent on the change, sufficient should be kept back to (re-)train the employees that are expected to follow new processes and use new tools.  Maybe we need to remember to do change from the outside in – starting with the employees and what they need.

Organisation Design from the Capability Model

It seems that so many changes, at the level that Enterprise Architecture is involved, trigger changes to the people element of capabilities that all Enterprise Architectures should have a very good understanding of the Organisation Model.  The term ‘Organisation Model’ can be used to cover many different things so, for this post, I’ll restrict the definition to be ‘Organisation Structure’: things like teams, reporting lines, employee measurements.  It’s always easier to change technology and processes than it is to change people.  People change takes so much longer than swapping out a particular technology but is an often forgotten component of ‘Change’.  The Organisation Model is one of the first documents that is drawn up, either conciously or unconciously, when a new Enterprise is being created and, arguably, remains the most important during the life of the Enterprise.

How do you design a whole organisation, a complete Enteprise ?  Which teams do you need and what should their reporting lines be ?  How should they be incentivised and what’s best for the Enterprise as a whole ? This article discusses whether Enterprise Architecture models can help build an Organisational Model. There’s not always an Enterprise Architect at hand to assist at the very beginning of an Enterprise so EAs are usually involved when an Enterprise changes.

There are several different organisational design models; models that are used to create an Organisation Design.  (examples include the McKinsey 7S model, Galbraith’s and Burke-Litwin)  Many of these use the tenets of Business Architecture such as Vision, Goals, process and systems.  I’ve previously written about the capability model, the capability value chain and the relationship to high-level processes.  These are part of the Business Architecture and parts of the Business Architecture seem to assist or maybe replace other organisational design models.

The capability model shows the whole Enterprise laid out in a page as a set of ‘things’ that the Enterprise needs to be able to do.  The capability value chain organises those capabilities into a high-level process and shows which are the main capabilities and which are the support acts.  Putting logical breaks between those main capabilities is the first step to building an Organisation Structure.  With a set of breaks in the value chain, there’s now a rough set of departments that are necessary in the enteprise.  A different department would be responsible for all of the value chain capabilities between the breaks.  Each break though, causes tension in the Enterprise because two departments have to interact.  This tension can be eased by describing clear interfaces and agreements between the two departments.

This way of building an enterprise does create a very mechanistic, rather than organic, organisation but I’ve encountered more mechanistic organisations than I have organic.  It also leads to a functional (e.g. marketing, sales, delivery, finance) organisation, rather than, for example, a product or customer focussed one.  Those different types need to be borne in mind when putting breaks between the capabilities and deciding whether there should one or multiple instances of the capabilities.  Once the splits have been put in place, the supporting capabilities, need to be grouped into departments too.  However, one supporting capability can support multiple main capabilities and so these could be modelled as shared services.

Once the departments have been created, the measures and incentives need to be added too.  To reach these measures and incentives, each capability can be analysed to determine a set of sensible KPIs.  Whilst I say ‘sensible’, experience is necessary in drawing-up KPIs that are transparent and measure the enterprise correctly without creating perverse incentives.  However, once the KPIs have been reviewed, the can be turned into measures for the department and incentives for individuals.

From a capability value chain, I think that technique gets us to a rough sketch of an organisation, doesn’t it ?

Impact Analysis using the capability value chain

The post before last discussed building a model of the enterprise that included dependencies between capabilities:  ‘Make the tea’ depended upon ‘Maintain the kettle’ and so on.  The model can be used to create complex impact assessments, and, if the model has the data in it, a very good architecture for the solution design.  The impact assessment, of course, has to be at the stage where a review at the level of capabilities is appropriate.  This is usually at the early stages of a new idea, maybe to scope how wide and deep the impacts of that idea might be and to set out the high-level architecture.

Once the value-chain model is in place, a quick impact assessment of an idea can be performed very quickly.  The first step is to document the capabilities that are needed by the idea.  Once that’s been done, a quick check against the value chain model shows up the other capabilities that might also need to be changed.  The ones that need to be changed are those that connect with any capability that was documented as being necessary to deliver the idea.  For example, the preceeding capability might need to be changed (to, for example, provide the data correctly) and so might the following capability (to, for example, accept the data correctly) and so might the supporting capabilities (to, for example, accept an updated interface)

The scope of the change necessary for the idea then, are the directly impacted capabilities, the preceeding, following and supporting capabilities.  That’s a high-level impact assessment done almost instantly.  Admittedly, there’s some skill in picking the capabilities necessary to deliver an idea but that’s where the skill of an experienced Enterprise Architect is needed.  It also provides a fact-based definition of the scope of a project and that definition allows people to challenge whether the scope has too many risks associated with it, can be delivered in the available timescales or with the available monies.

If the model had been expanded to include the mapping between capabilities and IT systems, processes and teams then quite a definitive scope can be extrapolated very quickly from the documentation of the capabilities and those that surround it in a value chain.  I’d always advocate that the mappings between capabilities and people, processes and tools are maintained for just this reason: it makes impact assessments so much easier.  Of course, the capability model can be used when the project moves into the more detailed phases too.  The detailed business requirements, for example, can be captured against capabilities.



Capability Value Chains and Process

The postbag is bulging with arguments that the capability value chain is actually just a process model.  In the wider Enterprise Architecture discussion, there seem to be a lot of people still debating whether capabilities are just the same as processes so this is my $2c into the debate.

The standard definition of a process is that it is an ordered set of activities that translate an input into an output.  When developing process models, we typically start with a very high-level model of what the Enterprise does to translate the inputs into the outputs, or use Porters Value Chain.  Obviously, those inputs and outputs vary between Enterprises so it’s not possible to be more specific than that.  That high level model usually only covers the ‘happy day’ scenario, not all of the different paths that can be taken in the detailed process, let alone showing the proceses that cope with error scenarios.  Those ‘unhappy day’ scenarios are only documented once the high-level process is broken down into more detailed processes.  At a more detailed level, the activities necessary to handle the different paths and scenarios are depicted on the process diagram and at that detail level, the diagram starts to need swimlanes.  Swimlines split activities by the teams that provide that acitivity.  Those teams are usually clustered around a particular skillset (e.g. sales, debt collection, kettle maintenance) and those skillsets are supported by a set of tools.

Once a process starts to move between swimlanes, it’s clear that different teams and skillsets are necessary before the process can work.  The teams offer different capabilities and all the process is showing is that different capabilities are linked together in a specific order.  In fact, if we build a capability model then processes could be depicted, not as straight lines along a swimlane, but as diagonal lines between capabilities, without swimlanes.

So are processes different to capabilities? No, I don’t think so when we’re still looking at things from a high-level.  Once lots of detail is necessary to document a process with lots of swimlanes then it’s very definitely a process because the intention of a capability model is not to break the capabilites down to a level of detail that could be used as activities in a detailed process.  The intent of a capability model is to be able to see the Enterprise on a page, not to provide layers and layers of detail for each capability.  However, it’s true that detailed activities in a process should be able to be classified as part of a capability.

It’s the layout of the tasks that separates proceses and capabilities: capabilities show all of the different things that a business can do; processes show the order in which those capabilities are triggered to translate a particular input to a particular output.

Capabilities and Value Chains

Building a capability map seems to be ‘the in thing’ at the moment.  Capabilities have centre stage at Enterprise Architecture conferences and feature in Enterprise Architecture.  Like many others, I’ve built a capability architecture and had it widely agreed.  What has been built is a simple map of a complex business.  That’s a laudable achievement but is it useful ?

The map isn’t useful as a model of the business, it’s really just a picture.  A cartographer includes features of the landscape into their maps so that their map is a model of the terrain. What features should be included on a capability map to make it into a useful model of the enterprise ?

This article proposes the evolution of the capability map into a Capability Value Chain by including dependencies between capabilities.  This creates a small, neat and useful model of the Enterprise.  Not a picture, but a model.

Many people will know Value Chains from ‘Porters Value Chain’, a very useful tool that helps to define what the key activities of the enterprise are.  But hang on, isn’t that what we’re doing with capabilities – defining the activities of the Enterprise ?

Capabilities, the “what the Enterprise does”, describe all of the activities of the company.  There are, of course, some capabilities that have to exist to enable others.  e.g “Maintain kettle” has to exist before “Make the tea”.  If these capability dependencies are (simply) documented then the capability map starts to turn into a model.

Once the dependencies have been documented, it’s possible that many capabilities depend on just a few.  If many capabilities depend on a few key ones then are the key capabilities the most important to the Enterprise ?  On the contrary, in my industry, the important capabilities are those that are valued most highly by the customer.  There aren’t that many businesses that can exist without customers so it seems sensible to denote the customer facing capabilities as the most important.  Those capabilities that are valued more highly form the value chain and those that are dependencies form the mesh of capabilities that support that value chain.  The order of the chain, for my industry, is decided by the customer’s journey through the enterprise.

When the dependencies have been documented, they can be analysed to gain some useful intelligence.  it’s now simple to show the nuance that’s well known: any effort to improve a capability must include analysis of the capabilities upon which it depends before.  Reusing the analogy: making a hotter cup of tea depends on having a well maintained kettle.

A cup of tea sounds good right now …