Comparing Business Model and Business Architecture

Posted on June 29, 2014 by Andrew Campbell

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.

Posted in Business model, Enterprise architects and operating models | Tagged , , , , , | 5 Comments

Operating model diagrams

Posted on June 20, 2014 by Andrew Campbell

Not many people write simply about a subject like operating models.   So I am reproducing here a blog by Jonathan Hammond of Knadel.  Jonathan does a great job of demistifying the task of generating a good diagram of your operating model or TOM.  Thank you Jonathan, apologies for a few small edits. Unfortunately he does not provide any examples – maybe in his next blog.

“The objective of documenting the operating model is to communicate how the business works, or will work, both operationally and technically.  A good operating model diagram will also serve to identify operational bottlenecks; uncover responsibility gaps or risks; or highlight fragmentation of data management, systems or functions.

Many of Knadel’s projects involve documenting a business’s operating model; typically the target operating model (TOM), normally the current model and frequently both with a number of stages in between.  Invariably we tend to use our own standards for documenting models and over the years our presentation has evolved and matured.

However, we do this with one eye on potential modelling standards and I’ve often trawled the internet to find a definition of an operating model diagram, and have regularly been disappointed (Me too Jonathan).   I find myself inspecting example diagrams that fall into one of two camps;

  1. extremely high-level diagrams where the information contained within the diagram (usually a functional decomposition) could equally apply to any business in that market segment, or
  2. highly-specialised enterprise architecture diagramming techniques such as TOGAF, ARIS or Zachman; or BPMN for business process modelling.

Whilst these standards work well for their intended frame of reference e.g. a technical architecture or a business process hierarchy, I believe there still remains a gap in articulating the interrelationship between business functions, organisational design, technical architecture and data management. It is this interrelationship that standard diagrams seem to miss. In a company functional decompositions, organisational charts and systems architectures often abound but rarely share the same underlying model or terminology or support for each other.

Unfortunately no single diagram can communicate the full complexity of an operating model. Our approach is to provide a suite of related diagrams usually augmenting pre-existing organisational charts and systems architecture diagrams. These diagrams answer a number of questions using the same language and underlying model.

  • Who is responsible for what [function]? This is typically a Functional Responsibility diagram. A Functional Responsibility diagram apportions a business’s functions and activities either to internal parties (e.g. departments) or to external providers. It’s important to realise that in such a diagram functions may be split/duplicated and thus scope of responsibility must also be represented. Outlining functional responsibility is particularly useful when measured against a Capability Map i.e. who is capable of undertaking functions and what’s their capacity to do so. In sophisticated cases functional responsibility diagrams have a temporal aspect i.e. who is responsible for what and when.
  • What functions are supported by which systems (and by inference which functions are not supported)? In the absence of a better term this is an Operating diagram. An Operating diagram is usually focused on a distinct business cycle over an extended period (e.g. a trading cycle, a reporting cycle etc) and covers all the functions involved, the systems that support each function, and the data used. This is clearly a complicated diagram and must be targeted to maintain legibility.
  • Where is data mastered, managed and distributed? Mention data diagrams and this usually conjures up images of technical database diagrams. These modelling languages show how data is structured within a system and are too low level for operating models. We endeavour to show how data is sourced, managed and distributed across systems. We typically refer to this as the Data Management diagram. Stylistically it is closely related to a systems architecture diagram but extends to functions not supported by automation. We also show data flows on Operating diagrams.

These are but a few of the diagrams that we use and I fear I may be leaving you with a whetted appetite, unsatisfied that I have alluded to diagramming methods without sharing them (Yes Jonathan – give us more!).  For the time being the message is ‘if you’re interested then get in touch’. Otherwise it’s watch this space for more information as we’ll share more in the future (Yes please!)”

While I don’t think that Jonathan’s three types of diagrams cover the full waterfront – what about geographic maps, what about stakeholder maps, what about process hierarchies, etc – I like the humble yet practical tone.

Posted in Design tools | Tagged , , , , , , , , , , , | 1 Comment

Do small companies have operating models?

Posted on June 15, 2014 by Andrew Campbell

The following is stolen from a post by Peter Murchland in a discussion group in LinkeIn’s The Enterprise Architecture Network. Thank you Peter and apologies for the changes I have made to your insightful comments.

In a new organisation, the first sign of an operating model is usually the Chart of Accounts – a common structure understood across the enterprise for managing and organising the enterprise from a financial perspective. This is needed by the sole trader for tax purposes, and grows from there, to ensure consistent application of the categorisation of income and expenses. This is typically a top down effort.

The next sign of an operating model is usually the job specifications, which establish clarity of roles and responsibilities.   This normally starts as a bottom up process.  New hires want to know what their job boundaries are.  It may take some time before a  top down perspective in the form of an organisation chart is developed.  This is because the top team have probably been working well without a formal organisation chart and hence do not easily see the need for it.

The next sign of an operating model is likely to be some definition and documentation of critical or common processes, ensuring that people performing these processes attend to critical steps and that hand-offs are clear between steps in the process and between processes. This tends to be more bottom up than top down.  It becomes top down when the processes are identified as part of a process architecture or a capability map.  Many organisations never develop this top down perspective.

As the organisation gets more complex, a particular challenge arises with multiple IT systems.  Each IT system will have documentation in a bottom up sense, but a top down perspective becomes essential to record the portfolio of systems and the connections between them.

So the top down perspective of an operating model often starts in the finance function with the accounting structures and rules, and the definition of legal entities and profit centers.  It may be supported by an organisation chart and related job descriptions. It will probably be further enhanced by a document defining decision authorities of different people or different levels in the organisation chart.  But the main impetus for documenting the operating model is likely to come from the IT function as a result of the need to lay out the different IT systems and how they connect together.  It can also be driven by a business processes or operational effectiveness function as a result of the desire to lay out the process hierarchy.  But, since much process work is about improving individual processes rather than developing an overall model, process architectures are less common that one might expect.

This is why an operating model can be viewed through a number of lenses – the accounting and legal entity lens, the organisation chart lens, the process lens and the IT systems lens.  There are additional lenses also: the buildings and locations lens, the supplier and business partner lens (really an extension of the process lens) and the career paths and people development lens.  The danger with the Enterprise Architecture community is that most of them come at the problem primarily from the IT systems lens.  As a result, their work can be a bit lopsided.

John Tieso helped illustrate this more informal evolution of an operating model in the same discussion group.  Thank you John and again apologies for the edits.  “I did some work with a very small firm recently. The two principals believed in documenting their major processes, procedures, and practices so that, as they grew and their processes needed to evolve, they had the documentation ready to discuss change. In fact, every Friday over lunch and into the early afternoon, they dedicated time to reviewing how these process, procedures, and practices were working, and what they needed to change or re-document.

One of the principals had done some modeling as an analyst with another firm, so he was used to creating simple models to accompany the written documentation–nothing fancy, just workflows and data flows.

They asked me whether they needed an Enterprise Architecture (or in my (Andrew’s) language an operating model). Basically, I told them they had one.  They had a simple set of models–their major processes, their organization, their network, and their links to their clients. Each procedure and practice was documented and linked to the high-level models. At their level, they really didn’t need anything else. Their business plan gave them at least three years before they would begin to hire niche personnel, such as a CIO, HR lead or a business processes expert.  In the meanwhile, they could use their Friday quality time to maintain their operating model.  They  needed nothing more complex than this for success.”

Posted in Design steps | Tagged , , , , , , , , , , , | Leave a comment

Designing beyond the boundaries of the firm

Posted on June 13, 2014 by Andrew Campbell

Operating model design, like organisation design, is primarily about designing those activities that are under the control of the organisation: the inside.  But organisations are increasingly reliant on a range of external relationships to succeed.   The implication is that operating model design should include the design of these external inputs.

Both the operating model canvas (still under development) and the PILOS model include “suppliers” as one of the main elements in the design challenge.  PILOS stands for Processes, Information, Location/Buildings, Organisation/People and Suppliers.   Interestingly, there does not appear to be much literature or guidance on how to design the external inputs.

At Ashridge Business School we recently discussed this issue in the context of organisation design.   It was raised by Richard Rawling of the Nous Group (an Australian consultancy) on the four day Advanced Organisation Design course.  We discussed ways of testing whether the external relationships are well designed, and we discussed the levers of design that are available.  Our main conclusion was that more work needs to be done in this area.

Tests include questions like

– are we doing only those things that we are good at?

– are our business partners competent to do what we want them to do?

– do our business partners have conflicts of interest, and if so, how are these kept under control?

– do rewards and penalties encourage our business partners do their best to help us succeed?

– do we “own” those things that will give us sufficient bargaining power in the relationship?

Levers include things like

– the choice of who to work with (like people selection in org design)

– the specification of what we want them to do and what we will do

– the specification of what we will “own” and what they will “own”

– the division of powers and decision making rights between us and our business partners

– the rewards and penalties for good or bad work

– the information systems and processes between us

– the mission and values and cultural norms that are established for this relationship

Since good operating model design is about identifying the significant pieces of the organisation, what their contribution is and how they should work together, then these same questions are just as relevant for the larger network or ecosystem.

My colleague Felix Barber has been working on these questions through the lens of how organisations can collaborate effectively with third parties.  His book will be out this Fall.

Posted in stakeholders | Tagged , , , | Leave a comment

Choosing good process owners

Posted on June 7, 2014 by Andrew Campbell

This post is a repeat of one from June 4 – because it has a readability glitch. 

One test of a good operating model is the process owner test: “do you have a list of your most important processes and does each have an appropriate process owner?”

One of the issues concerns the definition of “appropriate process owner”. This blog focuses on this issue drawing on an article by GENPACT a consultancy that works on finance processes. GENPACT open their article with

“World-class finance and accounting services are built on a delivery model aligned to organizational goals and business needs. For some, standardization means a single roof with centralized services. For others, it could be a mix of global, near-shore, regional, and in-country resources organized to deliver the most effective services at the best cost.

There is one common characteristic of world-class organizations, however. These companies give responsibility for end-to-end process capabilities to a single person who is directly accountable to the CEO, the COO, or the leader of Global Business Services (GBS).

The importance of the GPO role should not be overlooked. World-class global processes, whether finance and accounting, procurement, or any other end-to-end value chain, incorporate multiple foundational elements: standardization, globally enforced policies, metrics benchmarking performance to industry standards, technology that enables improved processes, and an operating model that matches skill sets to requirements and that accommodates fluctuations in demand. All of this is driven by a GPO focused on end-to-end performance, working with multiple stakeholders in harmonious collaboration to achieve a common goal.”

The article then talks about the skills and authorities that a GPO needs to be effective.

First, the GPO must be able to dive deeply into any process that has a material impact on business outcomes, analyze where bottlenecks and leakages occur, and determine which metrics are suitable to measure the desired outcomes. This requires capability and authority. Often the GPO’s role is constrained or the GPO’s skills are too narrow. Authority is needed not just to get access, but also to challenge policies. GENPACT give an example, “Existing policies can hinder efficient process execution, as in the case of an Australian company whose shipping policies contributed to orders sliding into the next month for payment. This led to Sales offering unauthorized discounts to entice customers to order early. A diagnostic of the end-to-end Order to Cash (OTC) process provided a clear view into the problem and enabled a more efficient process design.”

Capability is needed to do the analysis and to judge whether local variations are necessary to support local operating models or not.   A services team is usually needed to support the GPO, providing analytical skills, redesign skills and governance expertise.

Second, the GPO should have a global remit. The GPO should have the authority to define global standards and approve or not local variations. This should also involve the power to conduct training and development activities across regions.

To execute this remit, the GPO needs an open mind and a deep knowledge of business models and operating models. It is easy for the GPO to steam roller a standard approach. It is much harder to find the right balance between standardisation and local variation. The GPO also needs a team who can lead the training and development, and who are also sensitive to local differences.

Third the GPO should be responsible for performance outcomes even when he or she does not “own” the teams executing at the transactional level. This requires sufficient authority to influence the people who do own the resources, and to hold them accountable for their pieces of the process. It also requires good information flows and the skills to spot areas of poor performance and counsel those concerned.   The GPO needs an “operations controller” to help with this work.

Process standardization requires “big picture” thinkers. GENPACT worked with the CEO of a global pharmaceutical company who understood the challenge. He appointed one of the company’s most influential business unit CFOs to spearhead the process standardization project. He was given a central authority with clear responsibility for achieving the company’s Finance transformation goals. Because he was able to take both a global perspective and the perspective of a business unit, it was easier for stakeholders to agree on objectives and cooperate to get fast resolution of issues.

Choosing the right person, giving that person sufficient authority and supporting the person with sufficient capability is necessary.   Once a transformation is completed, the on-going process owners can have other jobs as well. But during times of change, the GPO is a big and challenging role that is often mishandled.

Posted in Design tools | Leave a comment

Enterprise architecture, frameworks and operating models?

Posted on June 3, 2014 by Andrew Campbell

There has been a long discussion on LinkedIn about Enterprise Architecture and TOGAF – more than 400 comments!    What follows is stolen mainly from a comment by John Tieso – thank you John.  For those who do not normally use the word architecture, just use the term operating model (or possibly business model) instead of EA or Enterprise Architecture.   For those who do not know what TOGAF stands for, it is The Open Group’s Architecture Framework.   This is one of many frameworks that are used mainly by IT people to document the operations of the enterprise.

John commented (I have done a little editing – hopefully without changing the meaning):

Watching this thread (and the ones preceding) for over four years now, I do wonder if we will ever agree on some basic premises. I suggest these are:

1- Development of an enterprise architecture is development of an overall perspective and holistic view of an ENTERPRISE — the organization as a whole.  The methods used to develop this view involve a number of models and descriptions of requirements, business rules, data structures, applications (systems), networks, etc, which help document the enterprise-level functions.

2- The vast majority of architectures developed each year are NOT enterprise architectures, but subsets of the enterprise, and may be current state descriptions of that subset/function, or future state maps (e.g. target operating model).

3- In many organizations, the actual EA does not exist — but is simply inferred through brief descriptions.   As a result, people create subset architectures, such as business, data, network, communications, or systems views without an agreed and documented enterprise architecture (before everybody jumps in, I am painfully aware there are other views as well – such as organisation, people, buildings/locations, suppliers, etc).

4- There is no single architecture framework which is adequate for the development of ALL EA and subset architectures. More generally, when the decision is made on what type of architecture is needed, the framework will either (1) be chosen from something that has already been developed for that architecture effort, (2) be customized to ‘fit’ the requirements of the project, or (3) combined with other frameworks and techniques to achieve the desired purpose. So, if the architecture work is about systems engineering requirements, one might start with John Zachman’s matrix; if the work is about business or IT views, one might use TOGAF, or another framework. If you are doing architectures for the various governments, you might start with DoDAF, MODAF, NAF, or another framework designed for those military or governmental contexts. Again, you might combine one or more to get the best descriptive results for the requirements identified.

5- An architecture documents the existing state, and/or perhaps some desired future state of the enterprise, or a subset of the enterprise, for some specific purpose. Doing an architecture provides logic, rationality, and a level of understanding shareable by managers, strategists, technical personnel, developers, and others. The purpose may be to provide an agreed view against which “lower level” architecture work can be done.
It may provide a basis from which innovation can be more easily discussed and understood.  It may provide a way for those who understand operations to communicate with those developing strategy, both to test the practicality of the strategy and to feed operational insights into the thinking.  Teaching architectural terms and methods provides the means to explain otherwise mundane concepts to those that need to understand what the effort is all about.

6- The CEO owns the EA, although, in practice, that is almost never the case. Whoever ‘owns’ it has to be able to manage, maintain, describe, and periodically review it with the full approval of senior management.  By default, the CIO often owns the EA because he or she is the function head who most needs the level of detail contained in an EA.

7- The efficacy of an architectural framework is not determined by what software supports it, or the bells and whistles the vendors insist in packing into every new version to justify higher prices. The real efficacy of a framework lies in its ability to help form a plan for development, maintenance, and management of corporate processes and practices, together with their supporting resources and suppliers, over time.

Posted in Design tools, Enterprise architects and operating models | Tagged , , | 7 Comments

Thoughts about the Open Group’s new Business Reference Model

Posted on May 13, 2014 by Andrew Campbell
Posted in Business model, Enterprise architects and operating models | Tagged , , , , | Leave a comment

Design Thinking is not Design

Posted on May 7, 2014 by Andrew Campbell

Most of the ideas in this post have been stolen from Marcio Dupont’s blog on May 1, 2014.

Design Thinking has become a bit of a craze in both Business Schools and companies. But design work is more than design thinking. Design work involves two activities, the creative ideas and insights activity and the practical, turn-it-into-reality activity.

Design thinking

Design Thinking is really helpful in the creative activity – but it does not do much to help you turn it into reality.  The chart above has “choose” and “implement”, but design thinking does not focus on these steps.  For good design, according to Marcio, you need Design Thinking and a Designer: by this he means someone who takes the hard and practical decisions, mobilizes others, leads the project and brings out a workable result.  Another way of expressing this is that for good design we need a Design Thinker and a Design Producer (or Design Director).

The reason why I am dancing on the head of this pin is that I think Marcio has a point. It is easy to get carried away with creativity, and forget that we all need to keep our feet on the ground. For every out of the box thinker we also need an in the box thinker. This is Marcio:

“Many businesses and schools have a belief that good design thinking will solve all the problems of a global company in several areas from design, engineering to management.

Nowadays, companies want innovative solutions quickly and at low cost, and it seems that somehow, design thinking is seen as the solution. The expensive, complex and time consuming processes demanded by “traditional” design work, have been transformed into a cheap, fast and without major complexities process within design thinking.

This perception of design thinking displays the Design Profession as something that can be practiced by anyone, without the guidance of a Designer.”

I have edited a little because the original is in Portuguese – no I don’t read Portuguese, but was working from a translation. Marcio goes over the top here. Design Thinking is much more than a cheap, fast process.   But he also has a point. It is easy to put the design thinking bit of the design process on a pedestal, and believe that, if you do this well, you will come out with a good design.

So what is Design Thinking? It includes “going to Gemba”, going to the places where the value is being created – the production line, the sales interaction, the customer usage moment – and observing what is happening. It includes laying out customer journeys or supplier journeys or employee journeys to understand how people arrive and leave these “moments of truth” (P&G phrase). It includes deep interviews to understand motivations, values and philosophies.   It includes mock-ups and trials and role plays and three-D printing of models.

And what is Design Direction or Design Production?   Design Direction includes project management. It includes agreeing plans and budgets with the sponsor client. It includes working up good “design principles”. It includes evaluating ideas against design principles and against other tests of practicality. It includes destruction testing. It includes a deep knowledge of the technologies needed to make the design work. It includes making tough decisions and compromises. It includes organising people and sub-contractors to meet deadlines.

You need both for a good design outcome.

Posted in Design steps | Tagged , , | 2 Comments

An enterprise architect’s view of capability maps

Posted on May 1, 2014 by Andrew Campbell

A good chunk of this post has been nicked from a blog by Chris Aitken from Enterprise Architects. Chris I hope you don’t mind. Copying is flattery!

Chris’s blog is titled “Business Function: Does it have a place in Enterprise Architecture”. But the blog is interesting because it is about how to articulate the “work packages” that need to get done to deliver the strategy – and in particular, how to articulate these work packages in a way that gives a hierarchy or architecture or in my language an operating model.

I reproduce some of his blog because Chris is an Enterprise Architect trained in TOGAF and such, and I am not. So I like to understand how people like Chris think, and, of course, you, the reader, should too!  I comment on Chris’s words at the end – so you can always skip to the end to get the main point.  I have left out some diagrams Chris provided because I did not know how to lift them and it is the words he uses that most interest me.

“Capability modelling has become something of a de facto standard within contemporary Enterprise Architecture practice. Capability-based planning is also a proven tool when it comes to change, portfolio management and the development of strategic roadmaps. However, I wonder if we architects aren’t guilty at times of being overzealous in our readiness to label anything that a business does or needs as a ‘business capability’, resulting in capability models that are in reality a mixture of capabilities, services, business functions and processes? Although the concept ‘business function’ might be considered ‘old school’ and only ‘reinforcing siloed architectures’, it becomes crucially important when we want to describe how an enterprise needs to organise itself in order to operate a given business model. Moreover, the term ‘function’ is highly overloaded, meaning different things to different people in different contexts adding to confusion with similar ideas and a lack of precision in its use.

Defining Business Function

When it comes to the concept of ‘business function’ it is tempting to simply transplant the concept of ‘application function’ to the business domain, and use it to represent a type of ‘organisational functionality’ (i.e., a set of instructions carried out by personnel to change the state of an object). However, not only does this view betray a certain ‘software engineering’ centricity, it is also difficult to distinguish this view of business function from that of process related definitions (c.f., BPMN 2.0 definition of Task ). Most importantly however, this is generally not the sense in which the term ‘business function’ is used by business stakeholders.

The term ‘business function’ is more commonly used to represent the logical level structure an organisation uses to control and manage its resources and processes (e.g., human resource management function, investment portfolio management function). TOGAF 9.1 somewhat obscurely defines ‘business function’ as “Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization”. Assuming a business function is concerned with ‘governing’ resources, an organisational chart might be considered the physical implementation of a business function model because it shows how, via the lines of reporting, the control and management of resources is structured and exercised within a given organisation. Indeed, the TOGAF 9.1 definition seems to call out this distinction between actual organisation structure and the more abstract concept ‘business function’.

Defining Capability

By contrast TOGAF 9.1 has this to say when defining the concept ‘capability’: “An ability that an organisation, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organisation, people, processes, and technology to achieve”. The TOGAF 9.1 Content MetaModel further defines ‘capability’ as “a business-focused outcome that is delivered by the completion of one or more work packages”.

I would personally prefer to define a capability as a grouping of organisational resources or assets (i.e., people, information, tools) and processes, necessary to deliver one or more strategic objectives.

Where Business Function Fits

Both concepts; capability, and business function, represent ways to view the structure and organisation of business processes and resources (i.e., people, information resources, systems and technologies).  Clearly both concepts provide useful insight into the degree of organisational coherency. Furthermore, both appear in the TOGAF 9.1 Content meta-model. Unfortunately, the relationships between these concepts are not explicitly defined.  However, the meta-model does describe business functions as delivering capabilities. This suggests that business functions might be thought of as sub-classes of capability.

Adopting this approach, a capability model (i.e. conceptual model) might be used to scope and constrain lower level (i.e. logical) business function and service models. The business function and service models might then describe how specific capabilities are realised within the operational enterprise, both in the current and future state.

Why Business Function Matters

Although capability-based planning and capability modelling are key elements of the Enterprise Architect’s toolkit, the more detailed business function and service perspectives also have a role to play. Capability modelling should be used to describe ‘what’ is required to meet enterprise objectives. Business function and service modelling should be used when describing the structuring and management of resources and processes to deliver outcomes.

The concept of business function in particular is most relevant when we are interested in representing the control of resources, and management of process execution within an organisation. This view may be quite distinct from that of capability. For example, a capability view of Human Resource Management may include Payroll as a sub-capability. However, the functional view of the organisation may in fact have the Payroll function sitting within the Financial Management function. That is to say that it may make more sense from a resource management perspective to regulate the Payroll processes and resources together with financial management processes and resources, even though it is understood that they contribute to the organisation’s overall HR capability.

Furthermore, it is the management aspect of business functions that makes them ideal candidates for representation as process model ‘swimlanes’ , as the business function can be said to ‘own’ or manage the processes within a particular swimlane. One practical benefit of this approach is that process models developed in this way are likely to have greater longevity during periods of organisational transformation, as business functions unlike other swim lane alternatives (e.g., org units), are relatively stable over time and across organisations.”

Chris is making some pretty profound observations, especially if you are an enterprise architect.  But, to a layman he seems to be involved in some tortuous thinking. Why? Because he is trying to use words in a precise way, particularly words that are used rather loosely by business people.

One of the contributions that EA training attempts to make (I have not been trained so I may get this wrong) is to provide precise definitions for different terms. The idea is that these precise definitions, often developed by the Open Group, help architects communicate with each other and do their work. But, of course, they also constrain.

Let me give an analogy. If building architects were trained with a precise definition of what a room is or what a wall is or what a floor is, would this help them be good architects? My guess is no it would not. Part of the creativity of being a good building architect is to re-imagine what a room is or could be or to do away with the concept of room altogether.   A building architect should be driven by an understanding of what the client wants, some knowledge of what is technically possible and a creative blending of these two inputs. I don’t think this is how Enterprise Architects are trained.   My concern is that the taxonomy-based training encourages a paint-by-numbers approach rather than a creative approach.   Maybe this is like Georgian architects who worked from a framework that defined ideal room dimensions, window sizes and so forth. Of course, Georgian architects built some wonderful buildings, but they were somewhat limited by their training.

So my thought is that the act of design (the job of the architect) is to develop the architecture or model. By this I mean that we can all define the 20,000 work packages that need to be done, but how do we arrange these work packages into an architecture or operating model? This is the creative act of architecting or design. Different situations will require different solutions. For some a map of processes may be all that is needed. For others a capability reference model may be the best tool. For others an organisation model with business functions maybe the best approach. As Chris points out, where you put Payroll is a creative decision that should not be constrained by assuming that Payroll is part of an HR capability. In fact, maybe Payroll should completely re-conceived as an audit function. Employees could download what they are due and be audited to make sure they are not defrauding the company: a bit like how Americans pay Federal taxes.

Posted in Capabilities, Enterprise architects and operating models | Tagged , , , , , , , | Leave a comment

Levels and actors in the design process

Posted on April 30, 2014 by Andrew Campbell

I was stimulated by two recent inputs.  One was my two day course Designing Operating Models which ran at the end of April.   Great inputs from participants.  The second is a discussion on LinkedIn about the difference between architects and engineers in a group discussing Enterprise Architecture.

So the issue is about levels of design and actors in the design and implementation process.  Why is this interesting?  Because there are different actors and the handovers are tricky and deciding where one starts and the other stops is tricky.

So my first analogy is a play.    A play will have a producer who is really the owner of the production (the business person).   The play will be written by a playwright (the designer or architect or …).   The play will be directed by a director (not sure what the equivalent here is – but maybe the project manager).   Then there are actors who perform the parts of the play (employees!).   As the play is being rehearsed, the actors may well have suggestions about how the play can be improved.  The director will clearly have a big influence at this stage as well.   So the play is designed or influenced by a number of people at different levels.

When the play is being performed, then the actors are doing what the director wants and what they have agreed to do.  Design has stopped.  Except that, based on audience reaction, there are often minor changes made.

Second analogy is a house.   A house will have a client the owner (normally the people who will live in the house).   A house will have an architect.   A house project will have a number of building trades involved each of which will do some lower level design work with regards to the electrical wiring or the plumbing or …  There will be on site employees who will come up against snags and problems which they need to resolve or refer to higher levels.  Finally once the house is finished the people start living in it and they may make further adjustments to the design as they live in it.  Again, the design of the house is influenced by people at different levels.

So can we create an idea of levels of design linked to types of people?   Just like when a worker hits a snag, he or she may be able to solve it at that level or may need to refer up to his or her immediate boss or the problem may have to be referred up to the building trade designer or it may have to go back to the architect or the architect may even have to take the issue back to the client.

Level one could be the client level – the level of strategy and design principles

Level two could be the architect or designer level – the rough sketch, the concept, the high level blue print

Level three could be the detailed designer level – the detailed blue print, the drawings to scale, but of the whole rather than of sub-parts.  At this level you will produce a process architecture, an organisation structure, a capability map, etc.

Level four is the  “trades design” level – the job descriptions by HR, the building layouts by Property, the draft contracts by Legal, the recruitment plans by Recruitment, the detailed process maps with swim lanes by Business Processes, etc.

Level five is the “execution level”.  The thing is being built.

Level six is the “user level”.  The thing is being used.

Three observations of this.  First, levels one and two are often given too little attention.  Hence my blogs on design principles for example.

Second, there is not much clarity about when level three stops and level four starts.  Maybe this is OK.  But often level three stops too soon and the “trades” level has to make guesses to fill the gap.

Third, it can be really helpful to get down to level six on some aspects in an experimental way, even before level two has been finalised.   Hence, the use in Design Thinking of mock ups that you can give to real customers, of role plays, of war games, etc.   These are techniques for getting down to level five or six before the whole thing has been designed.   In fact none of the levels should be finalised, until level six is complete: changes should be expected (within reason of course).  So the design process must make it possible to loop back based on new information provided by a lower level.

As you can imagine, this makes the running of a design project quite a challenge.

Posted in Design steps, Levels of design | Tagged , , , , | Leave a comment