- 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
5 comments:
In my opinion you are misusing Business Functions and Business Processes and going against the examples in the ArchiMate books and specification. Using Business Functions to represent low level detailed behaviour is very uncommon usage in my experience.
In ArchiMate, Business Functions are essentially high level grouping objects that are used to group more detailed Business Processes and Activity objects. See the example diagram at http://tinyurl.com/37dtqyt
A Business Function is closely associated with the organisation unit (i.e. Divisions, Units, Teams and Roles) that carry them out and should represent Behaviour from a generally high level Organisational perspective only.
Typical Business Functions would be for example: Customer Relationship Management, Finance Management, Sales Management, Supply Chain Management etc.
A Business Process and the lower level Activity are used to model the value chains and actual behaviour at a detailed more reusable level.
A Business Process/Activity can be grouped by several Business Functions where it is used in different contexts.
Business Processes and Activities should normally be named with a Verb + Noun Phrase naming convention, where the Noun is typically the name of the Business Object being accessed. Higher level aggregate Business Processes would usually be used to represent Value Chains and be named accordingly (i.e. 'Order to Cash', 'Request to Service' or 'Prospect to Customer').
It is odd to me to see very low level Business Functions being modelled in your example diagram at a lower level than a Business Process and associated with individual Business Objects. It's true that the ArchiMate meta model allows this but it is more normal to use an Activity to represent the lowest level of behaviour and not use very low level Business Functions. A Business Process decomposes to a number of Activities (i.e. Elementary Business Processes).
It is usual to show the Business Process realising the Products and Business Services, and being themselves realised by Application Services. See the example at http://tinyurl.com/3a2jtmn
The link between a Business Function, for example Customer relationship Management and a Business Object, for example Customer Data, is at a more abstract higher level than the Business Objects accessed by Business Processes and Activities.
Incidentally the Activity object can be conceptually associated with a Use Case if you want, although the mapping isn't perfect in theory.
In current state EA models I would model the exsiting Business Functions and related Organisation units (as Business Roles).
In future target state EA models I tend not to model Business Functions at all, preferring to focus only on Business Services, Business Processes and Application Services etc. This more closely maps to BPMS and SOA approaches.
Any close link between data and functionality is modelled in detail between Data Objects and Application Functions and I primarily model Business Objects as input or output from Business Processes.
There is not normally any equivalence at all between Business Function and an Application Function, and the latter doesn't directly realise the former.
The Business Function represents a high level organisational perspective of business behaviour and the Application Function represents a data oriented or object oriented (i.e a Class's operation) perspective on application functionality. The Application Function is closer in concept to the mathematical definition of a 'function' whereas the Business Function is not at all similar to a mathematical 'function'.
If I do use Business Functions at all in a future target state EA model then it is to represent Business Capabilities, which are again a type of grouping object.
I expect to see a Business Capability object to be added to ArchiMate in future versions.
In general, agree with all that you've done here.
The annoying part is that almost all of this is a workaround for one of the few major flaws in Archimate: it echoes the IT-centric mistake of describing everything not-IT as 'the business'.
The reality is that there are many non-IT ('manual' and/or machine-based) functions and services that are the exact equivalents of Archimate's 'Application' and 'Technology' layers - but they all get shoved up into the 'Business' layer because there's nowhere else to put them. Hence your apparent granularity problem - because the finer-grained functions and services actually belong lower down, in parallel with IT-applications and/or IT-infrastructure. The 'Business actor' object, for example, actually belongs in all three layers, depending on whether you're talking an abstract 'customer', an application-layer 'actor', or a real person (the human equivalent of 'infrastructure').
Instead of stereotyping off the business-layer objects in Archimate, you might be better to stereotype off the lower-layer objects such as 'Application function', 'Application service' and 'Infrastructure interface'. If you do it that way, the inter-item linkages should line up correctly, which they probably won't if you stereotype off the business-layer objects.
Hope this makes some kind of sense, anyway?
I concur with Adrian that Business Functions are perfectly usable as high level groupings. The examples look familiar and I've used functions like that on many occasions. In the ArchiMate courses that I teach, I usually recommend to start with business functions and use them to link to other aspects of the enterprise, similar to what is proposed in the NOVIUS method (recommended).
Also, Tom's comment that the whole discussion is rather IT-centric makes sense to some degree. Indeed, considering application functions in a different setting seems useful also. Perhaps a good topic for another blogpost.
However, Adrian also mentioned that Business functions are high level groupings. Here, I can't agree. It's a matter of choice!
The technical specification of the ArchiMate language says: "A business function offers functionality that may be useful for one or more business processes. It groups behavior based on, for example, required skills, capabilities, resources, (application) support, etc. Other methods sometimes call this a business capability".
Following this definition, a lot is to be said for a more finely grained interpretation of the function concept indeed. As always, however, there is no single "right" way to use a concept in practice as it all depends on whatever it is you wish to accomplish.
Please accept that you can look at reality through the 'constitution window' as well as through the 'correspondence window' (read SqEME processmanagement). Don't try to map those two images into one. Only in reality, in executing the business, these two images integrate, appropriate to the circumstances.
This applies to open social systems.
For engineering closed technical systems that (should) behave predicatably your discussion makes sense.
Took me time to read all the comments, but I really enjoyed the article. It proved to be Very helpful to me and I am sure to all the commenters here! It's always nice when you can not only be informed, but also entertained!
- Andre
Post a Comment