- Business functions map to "activities" in the sense of "primary and secundary activities" in Value Chain Analysis. In this case, many processes belong to a specific business function.
- Business functions are more finely grained and map on a competence that is recognized in an organization. As such, they are more closely linked to administrative organiztion type of research. In this case, several functions may be necessary in order to fulfill a particular process
Where the former view has the advantage of ensuring closer links between the field of enterprise architecture and strategic management, the latter appears to have the advantage of providing a mechanism for modeling the reusable building blocks of organizations. I came to appreciate this later view more after some good discussions with several clients and colleagues in the Netherlands as well as in Belgium. In this blogpost I will sketch some of my ideas and invite readers to comment and sheir their experiences in using the Business Function concept, especially when creating ArchiMate models.
The first principle that I'm proposing is to make a very tight link between business functions and business objects. That is: they have a granularity such that they mainly manipulate a single data object. Typical examples, then, are functions such as preparing an invoice, performing tax calculations, preparing a product for shipment, digitizing a document, et cetera. Note that these functions have a granularity such that they are reusable across business processes.
The logical next step is to link these functions to processes. Due to the relatively low granularity of business functions, business processes may be more coarse grained at the architecture level, which is a good thing. As is customary in ArchiMate, these businesses processes realize business services which represent the behavior of an enterprise to its environment; nothing new there.
In this scheme, business functions can be seen as "the things we need in order to be able to fulfill a business process". However, so far we've only proposed to tie them to business objects (by means of the access relationship in ArchiMate). We also need to tie other means to these functions. The main construct to be used here is that of an application service, which represents the functionality of applications that are available in the enterprise. The following example illustrates the concept so far:
By adding a layer of business functions between business processes and the means that are used to fulfill these processes, it may seem that models become needlessly complex. This is, however, not the case, as there is a big diffrence between the model (i.e., all the knowledge of all the concepts on the model) and its current representation. For many stakeholders one will generate views on the model which show only the relevant parts of it. For example, one my generate a view with processes and include the derived relationships between a process and the data objects that are manipulated in the process.Derivation rules are relatively straight forward and the more sofisticated toolsets support these derived relations. For example:
The main advantage of such an approach, in my opinion, is that the business functions are easy to recognize and use in practice. They form a good starting point for modeling, and as well as provide a good starting point to gain insight in the architecture of enterprises.process having acces to a business object is a process using a business function having access to that data object
