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.
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 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
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
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.
10 July 2010
I have recently finished reading the book ‘Lost on Translation’ by Nigel Green and Carl Bate and found it a very useful and insightful. I recommend it for the shelf of any Enterprise Architect. See http://www.lithandbook.com/
The book describes the VPEC-T ‘thinking framework’ and a focus on understanding the Values, Policies, Events, Content and Trust perspectives and provides a useful language to use when speaking with the business about any strategic change.
Being keen advocate of using Archimate (http://tinyurl.com/cf3z25) for developing Enterprise Architecture models, it struck me the next step after a VPEC-T based conversation would be to write up the outcomes in an Archimate model.
So what is there in Archimate that would be useful?
The first thing I noticed is that more or less all of the Business Layer meta model concepts in ArchiMate are in scope for VPEC-T and the Application Layer and Technology Layer are not.
That’s not to say that VPEC-T wouldn’t be useful for the application and technology layers, but it seems to be naturally focused on the Business Architecture side of things to me at the moment.
So how does VPEC-T map to ArchiMate concepts?
V = Values
The obvious first Archimate concept to use here is ‘Value‘.
ArchiMate users don’t use Value as much as they should in their models in my opinion. Using VPEC-T will correct that.
ArchiMate defines Value as that which makes some party (represented by Business Actor, Business Role) appreciate a Business Product and/or associated Business Services that they are buying, using or acquiring.
Value in this sense is also associated with a value chain (which is modelled in terms of a sequence of Business Processes and Business Activities that provide a Value).
I would also use the ArchiMate concept of Meaning.
Archimate defines Meaning as knowledge or expertise present in the representation of a Business Object, given a particular context. I would use Meaning to represent the inherent shared knowledge or value system that users have as their mental model.
P = Policies
There is no ArchiMate concept for Policy as such in the 1.0 specification but a number of EA tools that support ArchiMate do support it.
I would generally use the ArchiMate concepts of Business Function, Business Process to represent aspects of Policy. These should be used with care though, such as more in the sense of Business Rules, Guidelines, Policies, than with the normal meanings of Business Function and Business Process.
I would also use the ArchiMate concept Business Object, to represent Strategies, Goals, Objectives, Business Decisions,
In the conversation about Policies would be a focus on the Target Business [Operating] Model, in terms of what Business Product and Business Services would be sold or provided to what customer segments, i.e. Business Roles. This overlaps a bit with how one would represent a Business Model in ArchiMate which will be the subject of a future blog entry.
E = Events
The obvious Archimate concept to use here is a Business Event.
This is a key concept, and it seems especially obvious to use it in a message and service driven architectures, but it’s curious how infrequently it is actually used in most of the BPMN style models I have seen people develop.
I first started modelling with Events using IDS Scheer’s ARIS tool in 1998 and the power of an event driven approach has stayed with me ever since.
Business Events are used to trigger a value chain that results in an outcome that has Value.
Value chains are modelled using s sequence of Business Process and Business Activity and outcome of a value chain is represented with a Business Object, Business Product, Business Service associated with a Value.
Since Business Events occur via various channels, it might also be useful use the ArchiMate concept of Business Interface (representing a Channel) in your VPEC-T model, but that is a bit like solution design so is optional.
C = Content
Archimate can be used to model Content at several different levels of knowledge, information and data.
The Meaning object is used to represent knowledge, the Business Object for business information, the Data Object for data, the Representation object for the physical representation of information and the Artifact object for the physical storage of data.
In a VPEC-T model created with ArchiMate, I would mainly use the Meaning, Representation and Business Object concepts.
To me Trust is all about relationships, interactions and collaborations between people.
I would use the ArchiMate concept of Business Actor, representing an organisation, organisation unit or a person, and the concept of Business Role, representing the roles played by those organisations, organisation units or persons in relation to others.
For the trust relationships I would use the ArchiMate concept of Business Collaboration and Business Interaction. These don’t get used in many Archimate models but I think they are useful for representing aspects of Trust relationships.
A Business Collaboration is defined in ArchiMate as a (temporary) configuration of two or more business roles resulting in specific collective behaviour in a particular context.
A Business Interaction is defined as a unit of behaviour performed as a collaboration of two or more business roles.
I would also use the Archimate concept Contract to represent a Trust agreement (such as a Service Level Agreement) between parties.
Overall for doing Enterprise Architecture, I recommend using a ‘thinking framework’ such as VPEC-T first and then an Enterprise Architecture framework and modelling language such as ArchiMate second.
Recently I was asked about the concepts of a Business Function and a Capability, and how it is unfortunate that these concepts tend to be blended together.
a) How do you differentiate between these concepts?
b) Is there a value to modeling both, or do you find that organizations that use one tend not to use the other?
My answer is copied below.
I have also often found that people confuse Function and Capability. They are certainly different in my opinion.
Many enterprise architecture efforts don’t really focus much on either of these concepts and instead just focus on modelling business processes, applications and infrastructure.
This is because the Organisation Architecture and Strategic Planning domains are not included with the scope of Enterprise Architecture within their organisations.
However since ArchiMate includes the concept of a Business Function and now TOGAF9 (Capability-Based Planning - http://www.opengroup.org/architecture/togaf9-doc/arch/chap32.html) includes the concept of a Capability so I’d expect more Enterprise Architects to start using both these concepts more than they have previously.
A Business Function is a concept used in the Organisation Architecture domain and represents what work is done by that organisation, organisation unit or business role. An organisation can be designed as a set of Business Functions and usually the structure of the organisation units within an organisation is closely based on the business functions.
Those Business Functions are more stable than the organisation structure itself and often an Organisation Unit or Business Role may be responsible for multiple business functions. A Business Function is only ever carried out by a single Business Role/Organisation Unit within an organisation.
Examples of Business Functions include: Sales, Mаrketing, Supply Chаin Management, Finаnciаl Mаnаgement, Operations, Customer Relationship Management, Product Management, Supplier/Pаrtner Relаtionship Mаnаgement.
A Capability is a description of an ability to do something in terms of expertise and capacity.
It is associated with strategic planning and not the Organisation Architecture or Business Architecture domains. A Capability is delivered through the establishment of a number of different changes usually at together as a group of changes delivered in an iteration.
These changes are likely to include new or changed organisation units, business functions, business processes, business services, application services, application components, infrastructure services, infrastructure components (Nodes etc), business objects, data objects etc.
A Capability is used as the unit of change in strategic portfolios and Capability Increments (TOGAF9) are used in programme and project portfolios.
Examples of Capabilities include: Capability to sell a new Product, Capability for eCommerce, Capability for rapid merger and acquisition activities, Capability to survive the credit crunch, Capability to conduct research, Capability to achieve delivery objectives and be ready for future unknown challenges.
ArchiMate (http://www.archimate.org/ART/) defines a Business Function as:
A business function is a unit of internal behaviour that groups behaviour according to for instance required skills, knowledge, resources, etc., and is performed by a single role within the organisation.
A business function describes internal behaviour performed by a business role that is required to produce a set of products and services. For a consumer the products and services are relevant and the required behaviour is merely a black box, hence the designation: internal.
There is a potential many-to-many relation between business processes and business functions.
Informally speaking, processes describe some kind of ”flow” of activities whereas functions group activities according to required skills, knowledge, resources etc.
Complex processes in general involve activities that offer various functions. In this sense a business process forms a string of business functions.
In general, a business function delivers added value from a business point of view. Organisational units or applications may coincide with business functions due to their specific grouping of business activities.
TOGAF9 defines a Function as:
Function describes units of business capability at all levels of granularity.
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.
Any bounded unit of business function should be described as a function.
[a Function] Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as “business function”.
TOGAF9 defines a 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.
(Unfortunately in the TOGAF9 meta model at http://tinyurl.com/czrmpj, Capability is shown on its own as an unrelated concept, so I think that there is more work to be done on the TOGAF9 meta model.)
Civil Service Capability Reviews at http://tinyurl.com/cuyta9 has an interesting model of Capability.
CBDI_SAE defines a Business Capability as: The power or ability to perform something of value to your business.
MODAF defines a Capability at: http://tinyurl.com/c5lhaq
MODAF defines a Function at: http://tinyurl.com/cvkkua
Business Motivation Model: In the Business Motivation Model the concept of a Desired_Result is closest to that of a Capability and illustrates that we should measure Capabilities in terms of Goals and Objectives and their measures.
2 March 2009
Today I came across the Essential project - http://protege.cim3.net/cgi-bin/wiki.pl?EssentialProject
This is a very interesting open source Enterprise Architecture project that builds on the excellent Protege Ontology Editor.
If you haven’t looked at Protege yet then go to http://protege.stanford.edu/ to find out more about this free open source ontology and knowledge tool and download a copy to try out. It has lots of uses
I also recommend going to the Essential project web site http://www.enterprise-architecture.org/ and downloading a copy of Essential to try.
The Essential Modeller uses Protege as it’s editor to enter the Enterprise Architecture model content, based on a Meta model pre-built in Protege.
and the Essential Viewer uses a Java web application running in Apache to view the resulting Model.
The Essential Meta model is a fairly minimal EA Meta model, hence the name ‘Essential’ but it is certainly sufficient for most EA work. Using Protege it would be possible to modify the Meta Model to extend it to support other EA Meta models such as TOGAF 9 or Archimate.
On the Protege web site you’ll also find a number of interesting existing projects, including a model of the Federal Enterprise Architecture (FEA) in OWL.
I also remember reading about a Zachman Framework being modelled in Protege a few years ago that I think used a similar approach to the Essential project to publish its contents. http://apps.adcom.uci.edu/EnterpriseArch/Protege/index.html
6 August 2008
I have been evangelising about Archimate for a few years now in the UK and elsewhere.
Following a recent discussion, I wondered whether anyone else in the UK has also been using Archimate within their organisations and would like to get together to share their experiences, models, use of EA tools (such as BiZZdesign Architect or Avolution Abacus)?
1 August 2008
I have recently come across the Avolution Abacus EA tool at the recent IRM UK EA Conference.
Avolution Abacus is a highly flexible tool for enterprise architecture modelling and for analysing the resulting models using pre-defined metrics.
The main features of Abacus that gives it a competitive advantage includes:
A meta-meta-model that is customisable at any time, including adding or changing component types, attributes and relationship types.
I like this feature since I invariably want to add concepts and new relationships. Some older EA tools have fixed meta models that prevent this or make it very awkward to change.
Powerful import and export to Microsoft Excel, Visio, PowerPoint and Word
I find this is also an excellent feature, especially since most organisations that I have supported in their Enterprise Architecture efforts nealy always start out doing their modelling using office applications.
Customisable charts and graphs
I think that the charting and visualisation features are also very useful for presenting important information to senior executives, who just want to see the numbers and not the models..
There are five pre-built evaluation tools that are excellent for analysing the enterprise architecture models in terms of Performance, Total cost of ownership, Modularity, Openness and Reliability.
* The Performance simulator uses discrete event simulation to calculate the theoretical load and response of your architecture. There are a series of outputs from this simulator, the most obvious of which are the Bandwidth and Response Time properties.
* The Modularity evaluator calculates the number of incoming and outgoing connections for each component.
* The Total cost of ownership evaluator calculates the Total Cost of Ownership (TCO) for the architecture.
* The Reliability evaluator calculates the mean time between failure of the system and availability of the system given the structure of the components and connections and their properties.
* The Openness evaluator determines the degree to which an architecture and its elements are ‘open’, that is, the ability of the system to handle replacement of components with minimal impact.
Implementation Libraries with pre-defined metrics
This is an excellent feature that I have not found in other EA tools. The Implementations contain pre-defined data about existing COTS applications, infrastructure and connections that are used by the evaluation tools. This is invaluable for costing a particular future state architecture option. Collecting this kind of data is frequently never done by organisations, and estimating costs can be largely guesswork.
Abacus supports numerous Enterprise Architecture meta models and notations as libraries.
I’d like to see the Business Motivation Model (BMM) also supported, and I’ll probably have a go creating it myself when I have a spare moment.
A demo can be downloaded at the Avolution Abacus Web Site
30 January 2008
For a long time now I have been recommending that organisations use the TOGAF ADM as the basis for their Enterprise Architecture Development Process and best practices, and to also use Archimate as the basis for their Enterprise Architecture Framework and the metamodel of architecture elements that need to be developed.
Archimate presents a unified way of modelling enterprise architectures, integrating the architecture domains for Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture in a way that makes the models easy for decision makers to understand and read. Archimate also includes a big focus on Services within the various architecture domains, which supports the adoption of Service Oriented Architecture approach. See http://www.archimate.org/content/afbeeldingen/concepts.gif and http://www.archimate.org/content/afbeeldingen/archimate_example.gif.
I recommend the Archimate book. See http://tinyurl.com/69gx72
Anyway, the reason that I’m prompted to mention Archimate again is that good news today is that the Open Group has announced their intention to adopt ArchiMate as an independent standard for enterprise architecture modelling and analysis.
The combined use of TOGAF and Archimate is one step towards increasing the maturity of the EA discipline.
I predict that the next step in this EA maturity story will be the alignment of COBIT with Archimate and TOGAF.
There is a paper available to COBIT members that looks at the mapping from COBIT to TOGAF.
You know it makes sense!