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.
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 organisation, but not necessarily explicitly governed by the organisation”. 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.
Figure 1: Functions realise 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
