One of the most often heard complaints about ArchiMate is that the concept Capability is missing. People often use ArchiMate’s Business Function for Capability as it comes closest. Are they right? And: What is ‘Capability’ and how should we model it in ArchiMate?

Capability is widely used as a concept in many different definitions, both in Enterprise Architecture and in natural language. For instance, TOGAF 9.1 gives the following definition of Capability:

Capability: An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.

From an ArchiMate perspective, that sounds like (potential) behavior. But TOGAF also says this when it describes the Core Metamodel:

Function: Delivers business capabilities

Here, from an ArchiMate perspective, TOGAF’s Function sounds like an active object. But TOGAF also says:

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.

Here, the description of Function casts a very wide net which not so much delivers but is Capability at a more fine-grained level. Then, when discussing ‘implementing’ an Architecture (the domain of ArchiMate’s Migration Extension) TOGAF says:

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

Work Package: A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.

Are you confused yet? I am, but probably that is because I am not TOGAF certified (anymore — I did the 8.1.1 certification a few years ago). Anyway, TOGAF 9 uses (and as we know from Uncle Ludwig: meaning lies hidden in use) ‘capability’ as a concept mostly when discussing realizing an architecture (e.g. in ‘capability based planning’) and secondly as something that is encapsulated by a Function. TOGAF’s idea of what a Function is differs fundamentally from what ArchiMate says it is. While ArchiMate’s functions are purely behavioral siblings of separate active objects (‘the other side of the same coin’), in TOGAF Function seems more like an form of GOFBF (see also section 10.3 in the Mastering ArchiMate book), a mixture of active and behavioral objects. It also makes the ease with which many use the Business Function concept from ArchiMate for Capability slightly suspect. Do they have ArchiMate’s function concept or GOFBF in their mind when they use the word ‘function’? Are they ”bewitched by language” as Uncle Ludwig would have it? Or are they satisfied with what ArchiMate offers?

Such differences, by the way, make plans to integrate TOGAF and ArchiMate fraught with peril: though names of concepts may be the same (think ‘Function’) their meaning is quite different in both standards and trying to link them will be difficult in the extreme as you have either to fundamentally adapt one of the current meanings or you have to live with the utter confusion of two related but different meanings (‘uses’) for the same word. Before you know it, you will be, as suggested above, “bewitched by language“. It seems that for any chance of success with respect to integration, TOGAF could adopt ArchiMate’s metamodel of the enterprise and re-phrase its method. Adoption the other way around (apart from some additions like Capability that can be made in the proper ArchiMate way, see below) would probably destroy a unique contribution of ArchiMate: looking at active versus behavioral concepts to describe multiple aspects of what is essentially one ‘thing’.

Now, TOGAF’s metamodel sometimes seems not a metamodel about the enterprise, it sometimes feels like a metamodel about the artifacts of enterprise architecture (TOGAF artifacts instead of enterprise artifacts) and its use (again, I am not a TOGAF expert). ArchiMate on the other hand, has a metamodel that consists of artifacts that are about the enterprise (the artifacts in the extensions are meant for modeling change and architecture). So, when TOGAF talks about ‘capability’ it is often in the context of capabilities that are realized by ‘implementing an architecture’ via ‘work packages’ which sounds like a metamodel for enterprise change instead of a metamodel for enterprise.

Still, these concepts are close enough and the first definition given above seems pretty usable to me from an ArchiMate perspective. So, I will start from the TOGAF definition of Capability (the first one, not the second one) and see where that takes me when looking at it from the ArchiMate side. In fact, I am looking here at how ArchiMate could get inspiration from TOGAF.

From ArchiMate’s perspective, what a business produces are Services and these are — in ArchiMate — purely behavioral objects (though in principle always linked to an Interface — an active object). ArchiMate is a bit skimpy on allowing passive objects to be produced. ArchiMate’s Product concept aggregates Services and a Contract, and that’s it. No Interface or other active objects at all. No passive objects other than Contract. So, if your business for instance builds web sites to customers, you can model the offering of a ‘web site building’ Service, but you cannot model the ‘web site’ code itself as part of the ArchiMate Product. That seems to be an omission in ArchiMate. I think it would be a good idea to have the possibility to aggregate a Business Object as well in a Product, then the Business Object could be ‘web site’ and this one is realized by — for instance — a zip file (Artifact) with a Joomla setup. But I digress.

So, given that Capability, as defined initially above, is missing from ArchiMate, how would we add it? My initial thought would be to create a concept related to Product. Before everybody gets bored by the lack of illustrations in this post, here is a first attempt:

As we are talking Fantasy-ArchiMate here, I have also added Business Object to the Product aggregate (currently not so in ArchiMate). There is more here to discuss, think about the question if — just as with Services from many layers that can be aggregated in a Product — passive objects from all layers could be added to Product (e.g. Artifact).  Related to that discussion there is the strange overlap between Representation (which can be a PDF file) and Artifact (which can be a PDF file too) in ArchiMate. And should we be able to add active objects to the Product aggregate? Suppose we offer support on-site, could the actor also not be part of the Product? But I digress again and even more so this time around.

For the icon, I think a hammer would be appropriate, as one of the proverbial tools. A wrench maybe better, but was too much work to draw.

I have doubted about adding Role to the Capacity aggregate, but in the end decided against it. A Role is a responsibility and as such seems not tangible enough to add to a capability. Then again, it is not enough to have just any Actor to add to a certain Capability. After all, the Actor must be able to perform the right activities. In other words, what we need is Actors with certain Skills.

Would Skills be another potential new ArchiMate object? Maybe, but for now I see those Skills as a form of Requirement for the Actor. Which brings me temporarily to the different subject of Requirements in ArchiMate, currently available in the Motivation Extension, something that can be Realized by any other type of object. Skills, then, could be modeled by a Requirement object that is Realized by an Actor.

As you can see, these are just initial thoughts and they are not fully worked out. But I do thing the Capability concept, if added to ArchiMate, should be like the Product concept: an aggregation, in the case of Capability of passive, behavioral and active objects.

Summary

• We could add Capability as a new concept to ArchiMate 3, a bit like the current Product concept: an aggregate of other objects from the Core metamodel
• Product too, could be extended to aggregate passive and active concepts
• A Capability could Realize a Product
• Product, Capability and (as suggested in the book) Group & Location could be ‘neutral’ or ‘aggregate’ concepts (neither active, behavioral or passive, but ‘generic’ aggregations of all three types)
• We could do more with Requirements in ArchiMate (maybe for a later post)

Off-Topic Addendum

We use (today’s meaning, especially under architects) ‘capability’ as the ‘ability’ or ‘power’ to provide something (a service, a product, etc.). E.g. Wikipedia says:

Capability is the ability to perform actions. As it applies to human capital, capability is the sum of capacity and ability.

I would prefer the explanation ‘Capability is the ability to produce results’. Anyway, the term ‘capability’ has an interesting history. From the online etymological dictionary:

capability (n.): 1580s, formed in English from capable + -ity. Capabilities “undeveloped faculty or property” is attested from 1778.

capable (adj.): 1560s, from Late Latin capabilis “receptive,” used by theologians, from Latin capax “able to hold much, broad, wide, roomy;” also “receptive, fit for;” adjectival form of capere “to grasp, lay hold, take, catch; undertake; take in, hold; be large enough for; comprehend,” from PIE *kap- “to grasp” (cf. Sanskrit kapati “two handfuls;” Greek kaptein “to swallow, gulp down;” Lettish kampiu “seize;” Old Irish cacht “servant-girl,” lit. “captive;” Welsh caeth “captive, slave;” Gothic haban “have, hold;” Old English hæft “handle,” habban “to have, hold;” see have). Related: Capably.

Capability and capacity have the same Latin origin: capax (able to hold much). Just for completeness, the ‘ability’ in ‘capability’ is a happy coincidence:

ability (n.): late 14c., from Old French ableté “expert at handling (something),” from Latin habilitatem (nom. habilitas) “aptitude,” noun of quality from habilis “easy to manage, handy” (see able). One case where a Latin silent -h- failed to make a return in English (despite efforts of 16c.-17c. scholars); see H.

-ability: word-forming element expressing ability, fitness, or capacity, from Latin -abilitas, forming nouns from adjectives ending in -abilis (see -able). Not etymologically related to ability, though popularly connected with it.

Language is wonderful, isn’t it?

The etymological roots of ‘capable’ also shows an example of the conservative nature of the Dutch regarding their language. The Old English ‘hæft’ means ‘handle’, in today’s Dutch it is still ‘heft’ and is even still pronounced like ‘hæft’. The same is true for ‘to have’, which in Old English is ‘habban’ and in Dutch is ‘hebben’, pronounced like the Old English ‘habban’. You find more sounds and words in Modern Dutch that you can find in Old English or Old German. And I even recently saw a grammatical construct in German that has gone out of style in German recently and still is available in Dutch. Dutch is a language that seems to change slower than the ‘larger’ languages that surround it. It has been theorized that the ‘big neighbors’ have made the Dutch ultra-conservative in their protection of their language as a token of their independence. This is now changing. Slowly. Hmm, I digress to the extreme, it seems.