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.