How do you differentiate between a Business Function and a Capability?

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.

 

References:

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.

Essential – an Open Source EA tool based on Protege

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.

Architecture of Essential

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.

Essential Architecture Manager

 and the Essential Viewer uses a Java web application running in Apache to view the resulting Model.

Essential Viewer

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

Also http://apps.adcom.uci.edu/EnterpriseArch/Protege/TRCEAPractice/Website/main.htm

Enjoy.

Business Architecture is part of Enterprise Architecture

Enterprise Architecture does by definition include Business Architecture. Any other view is now rather out of date. 

Enterprise Architecture should include several domains: 

•  Strategy 
• Business Architecture 
• Information/Data Architecture 
• Application Architecture 
• Infrastructure Architecture

In addition there are other sub-domains for Process Improvement, Governance, Audit, Security etc. 

All EA frameworks including Zachman, Archimate, IAF and TOGAF 9 recognise these distinct domains in some form. 

TOGAF 9 is increasing mature and the image at http://tinyurl.com/btxqga 
is a good baseline for understanding the various domains. 

Of course over the history of the maturing of the Enterprise Architecture discipline, it was nearly always the case that Architects came out of the IT function.

IT trained staff are more likely to be good modellers and think in rational formal ways necessary to produce good Architecture models.

Business staff on the other hand like to own their business models and have been less precise and formal about how they modelled what they do.

This is improving of late with BPMN and BMM models becoming more acceptable for business focused staff to use.

The Enterprise Architect is also increasingly becoming a Strategy & Architecture discipline and an Enterprise Architecture (as opposed to a Solution Architect) likely not to have an IT background. Many are from a Business Analysis, Programme Management, Portfolio Management background.

The ideal EA team today will have a mixture of all kinds off staff from different disciplines and will not report to the IT function.

EA is a corporate level function and not just a Business or IT function.

Archimate User Group in the UK?

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)?

Avolution Abacus

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..

Evaluation tools
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.

These include:

• Archimate
  
• TOGAF
• zachman
• DoDAF
• MoDAF
• FEA RM
• SAP EAF
• IAF
• BPMN
• UML
• DFD
• ERD

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

Sparx Systems’ Enterprise Architect tool now supports TOGAF

Today I returned to the Sparx Systems web site to see what was new and was pleased to discover that the Enterprise Architect tool can now be extended with a new MDG technology add on for the TOGAF 8 Architecture Development Method, in addition to the previous add on that was available for the Zachman Framework.

The Enterprise Architect tool is already a great tool and this add on is sure to be popular. TOGAF is increasingly mentioned as a desirable skill in job specifications for Enterprise Architects.

http://www.sparxsystems.com/products/mdg/tech/togaf/index.html

Of course, now that the Open Group has adopted the Archimate  Enterprise Architecture modelling language standard, the next add on I’d like to see is one for Archimate.

Archimate and TOGAF

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.

See http://tinyurl.com/5es67c

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!

Would you change the Zachman Framework?

In his recent blog at http://4thresource.evernden.net/  Roger Evernden asks ‘would you change the Zachman Framework?’.

Recently Zachman and Locke have been doing great stuff to update the Zachman Framework themselves and it always sounds great at conferences, but it isn’t enough I think.

Their problem is that is it has been a good earner for them and since it is now their brand they can not be seen to change it too dramatically.

My general thinking is that an EA framework is multi dimensional (perhaps at least the 8 dimensions introduced in the book ‘ Information First’) and that the Zachman Framework presents one of many views that are useful.

I think the main issue is that many people find the language of ZF doesn’t match the names they use for deliverables in their own environment.

Also ZF is seen as too theoretical and formal, which puts many people off.

Many are looking for a quick win, keeping it simple, just good enough, just in time. However in real life the devil is in the detail and a more complex solution is needed.

The Zachman Framework talks about primitives and composites. The primitive information is what is classified in the Zachman cells. However most people produce complex composite deliverables as long documents whcih relate more to what Zachman calls the composites.

What needs to be changed I think is to add an orthogonal view of the Zachman Framework that just shows the composites. A mapping between composites and the deliverables promoted by Prince 2, OGC and other project management processes would be a good start.

I’ll post some of my other thoughts on the Zachman Framework later on.

Enterprise Architecture Framework

An Enterprise Architecture Framework need to be very accessible.
I have found that find the original Zachman Framework matrix can be too complicated for some people.
In most cases I find that people accept the columns based on the six questions, who, what , where, how, when and why.
The column names are not always understood.
There is confusion about all the rows and in which cell to put the ings such as User Interfaces, Use Cases, Objects, Classes, Components and Services.
The original Zachman Framework betrays its Information Engineering legacy and needs updating.

Does a class belong in the Data or Function Column ?
Where does a Service belong ?

If we distinguish between an organisational service (performed by people) , an application service (performed by a software application) and an infrastructure service (performed by the hardware and infrastructure platform), then should we put each of these services into a different column ?

How do we map strategy aspects and the architecture discipline ?

In response to this I have created a matrix with two dimensions:

• Levels of Abstraction {Strategy, Architecture, System and Operations}

• Architectural Perspectives {Information Architecture, Process Architecture, Application Architecture, Technology Architecture, Organisation Architecture and Performance Architecture}

I have found this to be more aligned with organisation view points and common terminology.