October 5, 2009

On business functions

While reading the book Business Process Management – Concepts, Languages, Architectures (Mathias Weske, 2007. ISBN: 9783540735212) I was once again confused by the term business function which is used differently by different authors in different contexts. In this blogpost I’ll describe my attempts to come to grips with this term. Before diving in, though, I must say that the above book is interesting and very well written. I like the structure and style of writing. I particularly like the fact that quite a few pages are spent giving an overview of (selected parts of) the field from a historical perspective. Given the strong focus on IT, I wouldn’t recommend this book as a first introduction into the field of BPM, though. However, the books seems very useful for IT-professionals who wish to gain a deeper understanding of conceptual analysis of business processes (e.g. IT managers, process architects, developers, JBoss specialists, etcetera).

To divein: to understand the concept of ‘business function’ we must come to grips with the words ‘business’ and ‘function’ first. To me, the word ‘function’ has a mathematical connotation. In mathematics, a function is a special type of relation which couples an element from one domain to exactly one element from another domain. For example:

f:x\rightarrow x^2 + 1

is a function that maps real numbers to real numbers. I.e., f is a function that transforms a real number into exactly one other real number. It seems hard to apply this notion of functions to business functions, regardless of the definition of the concept 'business' (which is an interesting discussion in itself; it probably does not mean a product-market combination as is common in the field of strategic management). It is likely that 'function' in 'business function' should be interpreted along the lines of "something that achieves a specific goal".

Weske starts his exploration of the concept of business function with Porter's Value Chain Model (see e.g. Wikipedia). In this model, activities are characterized as being either primary or secundary/supporting.



Weske claims that these activities are typically dubbed business functions in BPM literature; a value system consists of a value chain which contains business functions. Business functions can be detailed further using the concept of business processes. This seems similar to the way the business function concept is used in e.g. the NOVIUS method for architecture as well as the ArchiMate language.


In ArchiMate a business function is defined as "a unit of internal behavior that groups behavior
according to, for example, required skills, knowledge, resources, etc., and is
performed by a single role within the organization
". This definition implies a second meaning for the business function concept, as illustrated by the following ArchiMate fragment:



this snipplet shows that a business function (A) can consist of one (or more) business processes, and also illustrates that business processes can use business functions (B). An example of the former would be the observation that the business function "financial settlement" has a "collect premium" process. An example of the latter would be the observation that the "collect premium" process uses a "billing" business function.


As always, using terminology can be tricky. I guess that both interpretations work in practice and have no strong preference for either. Has anyone encountered other uses of the word 'business function'?

2 comments:

Tom G said...

The greatest problem with 'business function' is that, like 'capability', the term is used at multiple levels with little or no awareness of the distinctions between the levels. IT-folks also tend to (mis)use 'business function' to mean any function other than within an IT-based system - 'business function' = 'not-IT-based function', regardless of the level at which it occurs within the function/service/process hierarchy. The result is that 'business function' can become chaotically ambiguous in descriptions of an enterprise-architecture, business-architecture or even a low-level IT-architecture.

Seems to me that, as you suggest, the only way out is to use the term in the same sense as in mathematics: a 'function' is a point in a system where identifiable outputs are related in some way to identifiable inputs and controls. Defining 'function' in this way allows us to construct layering of functions/processes etc in a consistent way. A simplified summary of how this modelling would work is as follows:

- the inputs, outputs and controls for functions are all assets
- assets may be physical, virtual (e.g. data), relational (e.g. link to real person), aspirational (abstract relation, e.g. brand, morale etc) or any combination
- internally, functions are guided by business rules, which in Cynefin terms may be any combination of simple (rule-based), complicated (analytic), complex (heuristic) and/or chaotic (principle-based)
- in themselves, functions are abstract: to be enacted, they need to be linked to capabilities, which can work on defined combinations of assets (as above) with specific skill-levels (as per business-rules above) [note: within software, capability is constructed and often merged with function, sometimes giving the illusion that they are one and the same; however, in manual processes, function and capability are necessarily separate, and different combinations are necessary in order to support load-balancing, disaster-recovery etc]
- a combination of function and capability is 'exposed' as a service
- a process is a choreographed sequence of transactions with services

All of these may be nested at any level of abstraction. For example, the output of a process may be viewed as the higher-level 'asset' that feeds into a higher-level function, and so on.

For sanity's sake, it is generally better to reserve the terms 'business function' and 'business capability' for higher-level abstractions, and simple 'function' and 'capability' for lower-level ones.

All of this does map well with Archimate notation, if not necessarily the way in which Archimate is currently used (the latter mainly because at present it is still used mostly for IT-centric 'enterprise'-architecture).

Hope this makes some degree of sense, anyway. :-)

Pat Ferdinandi said...

A commonly accepted glossary would be helpful. Unfortunately I do not believe I'll see it in my lifetime.

Providing a definition of a term when writing is always beneficial. Too many people assume everyone has the same defintion. This isn't just an IT problem. I see this in every business line (sales, marketing, finance, accounting, hr, etc) as well.

What is a business function? Is it Accounting or paying a vendor? I agree with both of you that the term "business function" is used to categorize different things. Would it be modeled as an entity with different subtypes?

Business Function is a noun. A thing that requires action to add clarity. Business Function requires a verb to help define it. Without a verb on how it is used will continue to add to the complexity of miscommunication and use.

Are we talking about "performing" a set of business activities within its business unit to achieve a specific outcome? Is that a business function? The danger in calling this a business function is the narrow view of it ... placing organizational boundaries that limit growth potential.