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 )[1]. 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[2] 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.
The following diagram is an attempt to position the concepts Capability, Business Function, Service and Process in a way that is consistent with the TOGAF 9.1 Content Meta-Model.
Figure 2: A conceptual framework for thinking about capabilities, services, business functions and processes
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’[3] , 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.
In Conclusion
This post has argued for the place of ‘Business Function’ in contemporary Business Architecture practice, and has provided a framework to help sketch out the relationships and distinctions between it and related concepts such as Capability and Service. In the end it is not really a question of preferring one concept over another but rather understanding when and how to use each concept to achieve coherent architecture. Notably, there are currently on-going discussions in the TOGAF community forums to do with the definition of the concept of Capability. Hopefully these discussions will result in a refinement of the meta-model to better define the relationships between Capability, Function and Service as well as a revision to the TOGAF 9.1 ADM that identifies their appropriate use. In a world of ever increasing change it is equally important to understand both what resources and processes are required to realise business goals, as it is to understand the way in which these resources need to be organised and managed.
Footnotes:
- [1] BPMN 2.0 defines Task as: An atomic activity that is included within a Process. A Task is used when the work in the Process is not broken down to a finer level of Process Model detail. Generally, an end-user, an application, or both will perform the Task.
- [2] Notably, neither of these concepts directly describes behaviour, although both reference processes, and by implication, their constituent tasks. Tasks (i.e., a set of instructions executed or performed by an actor) are the only point at which an episode of behavior or ‘work’ can be considered to actually occur. A process is a description of the sequencing or control flow of tasks (i.e., the individual episodes of behaviour).
- [3] See original concept in Improving Performance (1990) by Rummler & Brache
Is business function a primitive (single variable model) or a composite (multi-variable model)? If it is the former than it is a part of the business architecture, if the later then it is not. The business function is: what a business unit (part of organization) should do (tasks/stages in the value stream) in order to realize a capability. So, business function is a composite concept. Its primitives are: capabilities, stages in the value streams, and organizational units. We cannot omit also what information is required for a specific business function to be effective. We just added the fourth primitive: Information.
Same can be said about services.
First, they were called business functions, then someone said that business components would seem more appropriate, then again a new term came to call it business services and now capability map… Some definitions talk about a capability is a function without a verb, others say it means something totally different. Who is right and who is not…I do not think it matters. The only stable thing is the business function. Talk to a business person and they will talk in business functions. We developed an insurance and wealth management enterprise business framework and it went through all the fad terminology that appeared on the market and what we found when talking to business persons is that the only thing that matters is a business functions. So lets not remove the business functions from our vocabulary and keep at the center of our architectures surrounded by everything else.
Hi Pierre – I agree with the sentiment – particularly that often it is the Functional view that resonates with business stakeholders. However I’d also add that the Capability concept has a place (as does Function). As Figure 2.0 in the post suggests – Capability has the ability to represent a cross functional grouping of business resources and processes. A Functional view is important when we need to describe how business resources are managed. A Capability view is important when we want to simply describe groupings of required business resources irrespective of how they might be managed. Sometimes these two views map one to one – on other occasions they don’t. When they don’t there is at least the possibility that Functional management may need optimisation. That said, there are certainly scenarios in which it is legitimate to have instances of the same Capability evident in multiple Functional areas in a company.
Nice article about capability based planning and need of business function in business architecture.
The Business Function concept is useful, indeed. A capability or service is much more than a business function though.
The fundamental issue is to define and relate properly the basic entities of an enterprise in a framework and metamodel i.e. layers, views, value chains and such entities as business functions, processes, workflows, enterprise capabilities, services, information etc.
Otherwise one ends up with separate or even conflicting capability, business process, application, information and services… maps.
Most existing EA approaches have this problem though.
Still, no need to re-invent the wheel. The FFLV-GODS EA frameworks, assembling all these concepts in a framework, was published in 2007 in an Amazon (Kindle) book at http://www.amazon.com/Enterprise-Architecture-Development-Framework-4th-ebook/dp/B004JN0KYA
And here is a post summarising the framework http://it.toolbox.com/blogs/ea-matters/the-fflv-enterprise-architecture-framework-32150
Chris, interesting blog. Your hierarchy from capability to business function to business process is also how I tend to approach the subject. Because capabilities are equally confusing to some, I might also use just high-level business functions in their place (equating a capability map to a business function map), although that loses the ‘business function = unit of governance’ notion in case of cross-functional capabilities.
BTW, we are also working on extending ArchiMate with a capability concept that is quite closely aligned with your thoughts, i.e., a capability is realized by other behavioral elements (business functions, or directly by business processes) and a collection of resources (actors, roles, application components, devices, etc.)
Chris, I was taught that the business architecture was predominantly about people and process. I hail from a BPM back ground so my question is if you are developing a process architecture that is non-functional (not derived from APQC) what use is the capability model as a managed and owned business tool to process owners apart from using it as a capability maturity assessment? Who will own the capability models, who’s the audience and hpow will they be maintained and communicated? How do you explain the difference between a capability and a process without confusing the business AND maintaining a consistent message?
Marco, one important distinction between a process and capability is that a capability is concerned with describing WHAT is required for a business whereas process is a description of HOW things are executed. I find that people readily understand this difference. For more on the virtues of capabilities and capability modelling I’d refer you to my colleague Christine Stephenson’s recent insightful post on the subject (http://enterprisearchitects.com/whatchu-talkin-bout-business-capability-model/).
Chris, I really like this post because it exposes the problem that we are all dealing with. How to articulate the “work packages” that need to get done to deliver the strategy – and in particular, how to articulate these in a way that gives a hierarchy or architecture.
The problem with capability mapping is that is is sometimes helpful and sometimes not. Also, as you point out with your HR example, it can constrain your thinking.
The answer, I think (meaning that I am really not sure), is that the act of design (the job of the architect) is to develop the architecture. 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? This is the creative act of architecting. Different situations will require different solutions. For some a process architecture 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 architecture. In other words, as architects we should not presume that a capability map is the best way of constructing the architecture. This is what I am sharing on my course Designing Operating Models http://www.ashridge.org.uk/dom.
A quick analogy. A building architect might be taught that the way to design a building is to develop a room architecture. But, this will not work if the building is open plan. The architect will need a different framework to help him or her do the design.
By the way, I am going to nick some of your blog and post it on my blog ashridgeonoperatingmodels.com – with references of course.
Andrew, yes I’d agree that different modelling approaches have their different uses. However, in order to be able to demonstrate alignment from strategic goals and strategies, through to processes and individual applications or other implementation components – a business capability model is extremely useful. I always develop one even if I never introduce the client to it – just to aid my own thinking. Of course, I also think that a business function model is important too – as it begins to set out the control structure within an organisation – and so takes the discussion with the client from the conceptual level of capability (i.e., WHAT is required) to logical design (i.e., HOW components will be structured).
I agree with Andrew. The logical next question for many executives after looking through the capability model is: “so how should I be structuring my organisation?”. I haven’t seen many (any?) enterprise architects that have an answer for that – it doesn’t seem to be considered part of the discipline, possibly given the technology design origins of the practice. If we are really serious about “architecting enterprises” then we need to develop skills and clout in organisational design.