Modelling Behaviour
19 October 2010
I frequently find that there is much confusion about the modelling of Behaviour in an Enterprise Architecture model, specifically between the concepts of Business Capability, Business Function and Business Process. The various enterprise architecture glossaries all differ in their definition of these.
For example the TOGAF ADM or ISEB definitions don’t help as much as they could.
TOGAF quite reasonably defines Capability as ‘A business-focused outcome that is delivered by the completion of one or more work packages. Using a capability-based planning approach, change activities can be sequenced and grouped in order to provide continuous and incremental business value’.
However elsewhere TOGAF says that ‘The term “function” is used to describe a unit of Business Capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc.’. This confuses Business Capability with a Business Function.
ISEB says that a Business Function is ‘An idealised or logical subdivision an enterprise’s capability.’ and also that a Business Capability is ‘A business function whose performance is the subject of management attention … It is usually a high level and cross-organisational business function.’ Other methods I have encountered confuse Business Functions with Activities and have Business Processes decomposing into Business Functions.
ArchiMate has the most clarity about Business Functions and Business Processes but doesn’t as yet define a Business Capability.
One of the first artifacts to be produced as part of a Business Architecture model is a Target Operating Model. This is where definition issues are often first seen.
A Target Operating Model is usually a view of the organisation structure showing the Business Functions that each organisation unit is responsible for, but often these are also rather casually referred to as Capabilities.
Even more casually, it’s not uncommon to find the Target Operating Model actually contains a mixture of Business Processes, Business Functions and Business Capabilities with some Business Services thrown in for good measure.
It’s time for a bit more preciseness, less fuzziness and better standard definitions. ArchiMate has helped enormously by providing a standard enterprise architecture language but it still allows some fuzziness. See http://www.opengroup.org/archimate/doc/ts_archimate/
Below I’ve described the definitions I encourage the use of.
Behaviour concepts
Business Capability
A Business Capability is defined as the ability to execute a specified course of action, to achieve specific strategic goals and objectives. A Capability is defined in terms of the outcome of the course of action, one that has a business value. The concept of Capability is used in the military context and the MODAF framework where it is described in the abstract. See http://en.wikipedia.org/wiki/Capability_management and http://tinyurl.com/2vge39e
A Business Capability is not a Business Function, but is a concept that encapsulates other objects, in particular Actors (organisation units), Roles, Policies, Standards, Skills, Business Functions, Business Processes, Products, Business Services, Application Services, Application Components and Infrastructure. A Business Capability is therefore used for managing units of strategic business change.
A military example of a capability might be ‘2000 air freight sorties’, ‘1 Tonne heavy lifting’ or ‘Personnel Recovery under fire’ (but not ‘Helicopter’ or ‘Flight Management’). A business example might be ‘eBusiness’ (or the ability to sell new or existing products and business services to customers via the internet).
Business Capabilities can be decomposed into component business capabilities creating a capability hierarchy. A Business Capability is named after the desired outcome.
Business Function
Business Function is an organisational perspective on behaviour. It is not the same as a Business Capability. A Business Function defines the ‘what’ behaviour that is associated with an organisational unit and modelled in a target operating model. In many ways the Business Function is equivalent to all the behaviour that is modelled in an organisational specific swim lane in a Business Process Flow view (i.e. a BPMN diagram). A Business Function is typically named with a suffix of ‘management’ (i.e. ‘Customer Relationship Management’), but could also be a single noun (i.e. ‘Billing’). Business Functions can be decomposed into component business functions, resulting in a business function hierarchy. A Business Function does not decompose into a Business Process or an Activity.
A useful example of a Business Function model is IBM’s Component Business Model, where the ‘components’ are (usually) Business Functions. See http://www-935.ibm.com/services/us/imc/pdf/g510-6163-component-business-models.pdf
Business Process
A Business Process is another perspective on behaviour and defines the behaviour from the ‘How’ (how work is done) perspective. It represents both a complete Business Process Flow and the elements in a Business Process Flow. A Business Process Flow view (i.e. a BPMN diagram) is a view that shows a sequence of sub-Business Processes or Activities that are triggered by a Business Event. See http://en.wikipedia.org/wiki/BPMN
The sequence of Business Processes can represent a Value Chain at a macro level or the detail elements in a Value Stream that is triggered by a Business Event and results in an outcome of value to the source of the Business Event, usually a customer. See http://en.wikipedia.org/wiki/Value_chain and http://en.wikipedia.org/wiki/Value_stream_mapping
A Value Stream is a more detailed version of a Business Scenario (TOGAF). Business Processes are named with a Verb + Noun phrase.
A Business Processes representing a Value Stream is named after the Trigger + Outcome i.e. ‘Order to Cash’ or ‘Prospect to Customer’
The Enterprise Business Architecture book is highly recommended as a source of examples of a Business Process Model with Business Processes representing Value Streams. See http://www.enterprisebusinessarchitecture.com/
High level Business processes are typically aggregations of more specific Business Processes (sub-processes) or Activities.
Business Processes can be decomposed into component business processes, i.e. into a business process hierarchy. At the lowest level of sensible decomposition (i.e. at one place, at one time, by one person or system) the elementary business process is usually called an Activity. Activities are what are modelled in a BPMN diagram and are realised by a person (providing an organisation service) or by an application service or application. An Activity doesn’t decompose into a Business Process or into a Business Function.
A macro level Business Process (i.e. representing a Value Chain, or a column in a Component Business Model) may be used to group a number of Business Functions. Note that there is a many to many relationship between Business Functions and Business Processes. One Business Function may group many Business Processes and one Business Process may be used by many Business Functions.
An example of this can be seen in the eTOM (Enhanced Telecom Operations Map) where Business Functions and Business Processes are orthogonal to each other. See http://en.wikipedia.org/wiki/ETOM
Business Service
A Business Service represents an external view of the services an organisation provides or sells to its customers alongside the sale of a Product. A Business Service may be realised by a Business Function or directly by an Application Service, but is more usually modelled as being realised by a Business Process.
Business Services can be decomposed into component business services i.e. into a business service hierarchy. I’ve also found it useful occasionally to create a Business Service Flow view, which is similar to a Business Process Flow view but seen from an external customer’s perspective instead of the internal ‘How’ perspective of a Business Process Flow view.
Clarification of all these Behaviour concepts is an important step towards improving and evolving a common understanding of the business architecture layer within all enterprise architecture models.
on Enterprise Architecture 
20 October 2010 at 8:27
Interesting and useful post. It leaves me slightly daunted and with questions on why so many stereotypes are needed to represent activity-like things, particularly Business Service which is only different because it represents an external view (of something that is defined elsewhere). It either is (something) or it isn’t – it should be based on perception! ;-) The distinction between Business Process and Activity by virtue of what is performing it seems ripe for simplification as it seems an artificial one if I’ve understood the definition.
From experience the fewer stereotypes (within reason), the better. The corollary is that if there is potential overlap and you force an architect to choose you can bet they’ll make different choices and you end with overlap. Having said this if you don’t intend to share the architecture description it doesn’t matter so much as you can enforce consistency within the one user community.
TRAK is similar to MODAF in the way it represents behaviour. A non-maintained snapshot of the metamodel diagram is at http://en.wikipedia.org/wiki/TRAK/ . The definitive metamodel is at http://trakmetamodel.sourceforge.net
In the Enterprise Perspective we have an enduring Capability which gives us:
* Enterprise requires Capability
* Enterprise aspires to Enterprise Goal
* Enterprise Goal requires Capability
where the Enterprise has start and finish times which therefore leads to the idea that the capability needed by the enterprise is required over particular times. Comparison of this with the time at which capabilities are realised by the delivering of systems allows capability gaps e.g. aircraft carrier with no aircraft! to be identified.
In the Concept Perspective we define, wait for it, the concept in terms that don’t imply a particular technology or solution. This is where the user requirement is described. We have ‘Concept Activity’ giving:
* Node conducts Concept Activity
* Concept Activity supports Capability [provides the traceability / justification to the enterprise and its needs)
Finally we get to the Solution Perspective where we describe how we implement or realise the concept and what things realise the capabilities needed (and the Procurement Perspective defines how and when projects deliver these). The Solution Perspective covers current and proposed solutions.
He we have:
* Resource (System, Physical, Software, Organisation, Role, Job) performs Function
* Function realises Concept Activity
All these activity-like stereotypes can be decomposed (has part) and all can be quantified e.g.
* Capability is quantified by Metric
From what I can see the differences wrt ArchiMate are that there is no mention of ‘business’ – in the solution can describe a business and the way it is structured and the exchanges that occur. Equally though the same set of stereotypes can be used to describe an aircraft carrier or a train as the central concept is that of a system. This also means you have to be clear to keep the model of the business distinct from the model of the product produced by that business.
Am I right in thinking that relationships in ArchiMate aren’t named? I can see relationship types e.g. composition, aggregation etc. We’ve found that names do help – it means non-architects can read diagrams as a set of sentences [like in this comment] and it also helps test the metamodel – if you can’t agree on a simple sentence-like structure it probably isn’t correct. It also helps specification of consistency rules (ISO 42010). The downside is that you have then to be consistent in naming and use.
In TRAK, unlike MODAF et al, we don’t have a set of stereotypes for services. Partly this is because it is an easily confused term (business services vs the software services in a service-oriented approach) and also because they seem to be an abstraction and we have mechanisms that cope well with this already. Also watching what happens with DODAF 2 where the Systems Views are now deprecated in favour of the equivalently named Services Views as I don’t think you can equate a service (an activity-like thing) with a system and losing the ability to describe the real world concrete solution seems a backward step.
Always interesting to be able to compare and contrast frameworks (and to learn something!).
Thanks
20 October 2010 at 9:32
Your reply is the second time I’ve seen TRAK mentioned recently. Do you think it can be used as a generic EA meta model for wider use, or is it best used for physica environments such as military or railways etc?
I think the representation of Capability in MODAF and in TRAK is better than Capability in TOGAF, where it is not a clear concept.
I agree that Capability should be related to Enterprise Goals etc.
Aircraft carriers without Harriers is a decision that will come back to bite us I’m sure…!
‘Concept Activity’ sounds a bit of a long name for a object type – what is the definition exactly? I assume the definition is in the meta model.
Re ‘you have to be clear to keep the model of the business distinct from the model of the product produced by that business.’
Do I understand correctly that TRAK is used to model Products and not to model the Enterprise (the business) that produces the Product?
Relationships in ArchiMate have a type but are not named as such. This is the same as BPMN and UML.
You can of course name a relationship and it’s role ends and give it other attributes when you use it in a model with all tools that support ArchiMate.
If you fancy learning ArchiMate, then you can download a free EA Tool called Archi – http://archi.cetis.ac.uk/
and read the specification at http://www.opengroup.org/archimate/doc/ts_archimate/
MODAF includes Services in a new Service Oriented Viewpoint SOV.
Click to access 20100426MODAFSOVViewpointV1_2_004U.pdf
If you look at this then it shows Service aims to achieve Capability.
If TRAK doesn’t have this then you might want to add it as it seems useful to me.
20 October 2010 at 11:41
In the Solution Perspective TRAK can be used to describe systems, organisations etc and therefore isn’t restricted to hardware. You can describe the structure of an organisation, the role, jobs and competencies (of role) and the role(s) of the organisation. You describe membership and governance of an organisation – e.g. trade bodies, associations and the interchanges between them (or between jobs or roles within the organisation). The boundary of ‘system’ and what’s inside is completely up to you. TRAK also allows you to describe a responsibility boundary using the construct Organisation / Role plays Role extends to Resource [System, Organisation etc] – useful if you want to describe what an ‘Authority’ might have responsibility or control authority for, or indeed a System Design Authority. As with all these things the flexibility comes from the combinations of stereotype and relationship (and the combinations or path).
Having explicit named relationships – and TRAK requires that the plain english is always shown – means that we can also use non-graphical ways by making sets of statements. As far as possible we’ve deliberately chosen names such that it makes sense as a sentence – always important to consider the user interface of a framework.
Since a service is often a euphamism for an abstraction or summary of an activity-like thing I remain to be convinced that we need this extra complexity and potential for incorrect choice/inconsistency. If we did have service it would indeed have to be mapped back to show how it contributes to capability.
The smaller the metamodel and the smaller the view set the better (within reason) – we want simplicity, clarity and not drive up the cost of modelling. It is an aid or a tool after all, not an end in itself.
20 October 2010 at 13:01
[…] This post was mentioned on Twitter by Tom Graves, Bart Leeten. Bart Leeten said: Modelling Behaviour http://j.mp/c752Km […]
30 October 2010 at 13:53
[…] Modelling Behaviour https://ingenia.wordpress.com/2010/10/19/modelling-behaviour/ #EntArch #BizArch […]
11 December 2011 at 12:14
MetaObject is sharp drop into the implementation detail.
Please replace with MetaInterface.
1 May 2012 at 2:36
Good discussion on Archimate and how to model the “business capacity” concept. It is definitely something that we want to have as part of our organisation’s EA meta-model, and tricky as Archimate does not explicitly support it. It could be modeled as a collaboration but would span the layers. So perhaps the answer is that each capability is modeled as a Total View? And the Enterprise Capability Model simply is a collection of these individual capability views?
1 May 2012 at 2:40
Apologies, first line should read “business capability”
1 May 2012 at 7:20
There are few “legal” ways to animate the macrodynamics of the system. Archimate is a tool, not a panacea. I can think of very few instances when I could not solve the behaviour display issue with UML object sequence diagram.
16 May 2012 at 9:26
Interesting post and I have to study it more in detail. After an initial scan I have two questions, though:
1. If you want capability to ‘encapsulate’ (dangerous word) other objects, and somewhat all other layers can be aggregated(?) in the capability, should there not be an aggregation from capability to the organization unit in your picture?
2. Your military examples like ‘2000 air freight sorties’ and ‘1 ton heavy lifting’ sound like ‘products’ to me. Where lies the difference exactly? Is a capability then an aggregation of a product with the means to produce the product? Or should capability be the object that realizes the product (or that has product as a composite part)?
Again: this is interesting and thought provoking.
16 May 2012 at 22:17
The first thing you need to resolve is Business vs Organisation vs Enterprise. Are they synonyms? Probably not but does one realise another….
Capability . From the dictionary ‘the extent of someone’s or something’s ability’ or ‘ forces or resources giving a country or state the ability to undertake a particular kind of military action’
A capability is therefore never an aggregation of a product. I might have a warfighting capability which is realised by the Eurofighter 2000 et al.
A capability is itself different to an active ‘doing’ such as a function (‘ an activity or purpose natural to or intended for a person or thing’).
A process (‘ a series of actions or steps taken in order to achieve a particular end’)
Personally I’d start with dictionaries rather than frameworks – as ontologies they’ve been around a lot longer and therefore had longer to be refined.
17 May 2012 at 7:35
Agree. A capability to do something is not the same as actually doing that something. The same capability can be used for other results, for instance.
Following that, capability comes close to function. You might look at it as potential versus actual function. A capability is the what I *can* do, a function is what I do.
Another way is looking at capability as aggregation of behavioral, active and passive components. Together they make up a ‘capability’.
Following Uncle Ludwig: how would you *use* ‘capability’ in modeling, e.g. in an ArchiMate model? The answer to that question might give you how to add capability to a language like ArchiMate. As modeled above, it is close to product (just another indirection) and it does not contain the active components that are an important part of it. So far, I have not a compelling argument to add it, as it does not bring much more than function and product which are already there. But I am not certain, because the fact is that capability in itself as a term has a meaning and modeling it in something like ArchiMate as function does not cover that entire meaning.
5 September 2019 at 13:27
Thank for this interesting post.
I’m currentlty working on a IS cartography project for a software editor and service provider customer linked to the telecomunication sector.
To achieve this, I would like to use
1) Archimate to modelize links between Business, Application (and eventualy Technology) components
2) eTOM to build a Business Map
As you probably know, eTOM is “business process” oriented and doesn’t really propose any “business function” notion, only process regroupments (level 0, 1, 2).
But in your post you wrote “An example of this can be seen in the eTOM (Enhanced Telecom Operations Map) where Business Functions and Business Processes are orthogonal to each other. See http://en.wikipedia.org/wiki/ETOM“.
Can you please explain me what are the business functions you identified in eTOM?
Did you consider horizontal domain (e.g. product, customer) and vertical process groupings (e.g. Fullfilment, Assurance)?
Personally, I’m not very confortable with this breakdown.
What methodology do you suggest to build a clear and reliable “Business Functions” referential
Hope you could highlight me…
Regards,
Cédric
5 September 2019 at 13:36
Do you think eTOM Level 2 processes can be considered as Business Functions?
To be noticed, in that case relation beween BF and BP would be 1-to-many and not many-to-many…
Below an extract of Level 2 processes to illustrate :
Selling
Contact/Lead/Prospect Management
Market Performance Management
Sales Performance Management
Marketing Communications and Advertising
Marketing Campaign Management
Brand Management
Market Research
Loyalty Program Management
Product & Offer Portfolio Planning
Product & Offer Capability Delivery
Product Support & Readiness
Product Configuration Management
Product Performance Management
Product Specification & Offering Development & Retirement
Product Capacity Management
Product Offering Purchasing
Product Lifecycle Management
Customer Support & Readiness
Customer Experience Management
Order Handling
Customer Management
Customer Interaction Management
Customer Information Management
Problem Handling
Customer QoS/SLA Management
Bill Invoice Management
Regards,
Cédric