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 Capablity 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 think 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.
R&A IT Strategy & Architecture 
I removed an error. The original post said that Requirements can only be Realized by Services, but in ArchiMate any core object can Realize a Requirement. I was confusing ArchiMate with the limited way we use it so far: using Requirements for modeling Risk and Security, where the Control Measures (or Controls) are modeled as Requirements that are always Realized by Processes (e.g. an Audit Business Process) or Services (e.g. an Application of Infrastructure Service).
LikeLike
in Dragon1 the following three concepts are distinguished 1) capability from 2) ability from 3) function: the ability of a system is what a system can do by itself/on its own (I am able to handover coins to someone else myself). A capability of a system is what a system can do because of something else / supported by others (I am capable of paying the rent if I have a job that pays my salary on time). The relationship between ability an capability is that capability is an enhanced performance or quality (such as capacity) of an ability, often caused by other systems helping the system (with goods, products or services). A function of a system is an activity or task a system is able to perform / execute.
A function of a carkey is to unlock a car door. An ability of humans is to open doors. If you have the right carkey your are capable of opening the car (by unlocking the car door using the carkey) without damaging the car or setting of the car alarm. If you have the master key you are capable of opening hunderds of cars of the same model at the same time.
I am curious how you would model the carkey-paragraph above!
LikeLike
Well, for one, I would probably not be interested in this level of detail in analysis. I can’t yet see this kind of precision bringing me a lot of extra benefits. A bit like not modeling the hardware Interfaces of a Device, but using a simpler pattern. I also do not quite understand what the difference in your definition is between ability (“what a system can do”) and function (“what a system is able to perform”) — note the use of ‘able’ in your definition of ‘function’ — unless from your example I take it that the ability is connected to an active element and a function to a passive element. Anyway, it does trigger the feeling of ‘word play’ in me. Like giving a different meaning to ‘a person’ and ‘a human’. There will be small differences in use of the terms and thus — following Uncle Ludwig — small differences in meaning, but in practice it will be very hard to find a sentence where I can use one and not the other.
In that case, your function could be a Requirement of a passive element in ArchiMate while your ability could be a function in ArchiMate and your capability could be a function where ‘because of something else would be’ relations of that function. A Function in ArchiMate may or may not need something else (some service), so it covers both ‘by itself’ as well as ‘supported’.
The ability could also be modeled as a Requirement (a skill) for the Actor. The capability would follow again from dependencies in the model (e.g. a function requiring another behavioral element’s realized service / an active component requiring another active component’s interface).
I find all of this difficult to place in a real EA situation. Can you come up with a non-analogy example so I understand how this is used in EA work you do?
LikeLike
What a great post 🙂
LikeLike
I agree with your separation between business planning and business realization.
In your proposal that have the top-level ArchiMate artifact of business realization to be the “Business Product”, based on the ArchiMate models, and that a capability could realize a product.
From my reading of BIZBOK and other things Business Architecture, the equivalent top-level artifact is “Business Capability”. From my readings, I the set of business capabilities of an organization as the ability of that organization to execute their business.
BIZBOK – Definition of Capability
A particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome.
BIZBOK – Usage of Capability in a Business Architecture
A business is broken down into business units, which have certain capabilities. Capabilities are enabled through a series of value streams, which require information. Organization, capability, value, and information comprise the foundation of the business architecture.
In the BIZBOK use, business capability keeps focus on what and where the business wants to spend its time and resources. A great business opportunity is not so great to the organization if it cannot be executed or it takes focus off the core competencies of that organization.
I think your proposed ArchiMate “Capability” and how capability fits in the Business Architecture model (as described by BIZBOK) are sufficiently different in their definitions and usage to be incompatible with each other.
LikeLike
Lengthy but valuable post! Definitely a frustrating topic; not helped at all by TOGAF’s lack of clear consistent definitions, Archimate still not addressing Business Capabilities, and the wonderful thing about language that a simple word like “Capability” an in particular “Function” can have so many meanings. (Putting “Business” in front of it helps somewhat, but still doesn’t give a clear singular meaning to “Business Function”).
With the concept diagram, I would suggest a toolbox icon for Capability rather than a hammer or spanner. I would also have Business Service as a realization of the Business Capability, used by a product. Reasons are that I’m inclined to favor Forrester’s definition that “Business services encapsulate the implementation of business capabilities”, and also a business service can be used for more than one product. I would also expect the business service to have its own contract (e.g. SLA).
LikeLike
Btw, I see a Business Capability having a one or more business services; possibly mapped to a sub-capability (function?!). And a business service can only belong to one business capability.
LikeLike
I certainly would not say that ArchiMate is wrong (I’ll wait till I’ve read your book and done my training before I’d go there). It is just not clear. Again, your blog is great as it clearly highlights this problem and tries to address it. But why or why, has this not been resolved yet in Archimate (or TOGAF for that matter)? How can we have a meaningful dialogue with the business if we don’t have a simple consistent language, using terms that the business understands and itself uses, and models that therefore make sense to the business.. Sigh. Keep up fighting the good fight, Gerben!
LikeLike
There was a small misunderstanding: I was reacting to Ron Beernink, but your comment as added while I was writing my answer to him (about saying ArchiMate is wrong)
LikeLike
Haha, happens to be that Beatnink and Ron Beernink are the same 😎
LikeLike
Hi Ron,
You’ll find quite a few more criticisms and suggestions on improving ArchiMate in the final section of the book (“We gaan door tot het gaatje!” 🙂 ). These I have added there because understanding the limits/problems of the language is part of understanding it, I think…
LikeLike
You can create Products for each Business Service you want and have a Contract element specifically for that Product. That creates your ‘Business Service has its own SLA’.
Using a non-ArchiMate definition of what Business Service or Product is (e.g. Forrester’s), to look at ArchiMate is of course an option and not ‘wrong’ in a broad sense, but an approach that has a fundamental ‘problem’: it is like using one yardstick to measure another with everything that that entails (we’re getting close to Uncle Ludwig here…)
I’ve seen often that people take some other standard (TOGAF, UML, etc.), then say ArchiMate is ‘wrong’ because its definition of something does not fit that other standard. ArchiMate’s Function is often analysed that way, because of ArchiMate’s rather unique actor/behaviour dualism and an existing strong idea that is fundamentally different (e.g. see GOFBF in an earlier post).
LikeLike
I agree to @beatnik that capability and service have a strong resemblance.
A (core) capability I see as a (outstanding) complex of people, tools, knowledge and services to realize a distinguishable value for customers.
I like the distinction of Capability as it was, if I remember well, used by BOOZ (now “Strategy&”/pwc):
In the Business behaviour matrix two dimensions : Generalspecific and Activity Outcome make a foursquare.
> under Activity: Function is a Generalization of Process ,
> under Outcome : Capability is a Generalization of Service.
That makes modeling in ArchiMate as easy as Process vs Function, by (re)using the Service element (and distinction in labeling, ideally as an icon a bit deviating from BusinessService)
An attempt to define;
A business capability is defined as a service organisation to realize a distinct value for a market (internal or external)
Whether there should be some difference in relational options I have not yet figured out.
LikeLike
I like to think that in capabilities we have a way of separating demand from supply and try and overcome the “innovators dilemma”.
Capability = Job that can be Done by actor (org, team, individual)
Function = Current Best Way to Do it.
Example:
Capability = Deliver goods to customers homes
Function Today = Truck based logistics
Function Future? = Drone based logistics
LikeLike
Nice article (little long), but I’m going to disagree completely because my gut is telling me too. And I’m interested in the fallout… 🙂 And I realize this article is nearly 3 years old…but ArchiMate hasn’t changed so it’s still relevant discussion.
I came across your article because I googled ‘model ArchiMate business capability’. I wanted more information after reading an article on a BizzDesign blog post that showed a Capability model using ‘ArchiMate’ (i.e. BizzDesign’s stereotyped ArchiMate). I knew ArchiMate did not have a capability object and was curious to see how others were (maybe) doing this.
I don’t think Capability is a function, and definitely NOT something that aggregates Actors, Nodes, Business Functions, etc. and absolutely NOT something that realizes a product. My gut feeling doc is you’re ‘in the weeds’ so to speak. If I build a 50,000 square foot building that is completely empty it has the CAPABILITY to be a lab, a warehouse, a manufacturing facility, a hospital, a play ground, my office, because it’s nothing more than a square slab of concrete with poles and a roof, right? I could park my truck in there and call it a garage, or park my Ferrari collection in there and call it a museum. It has the CAPABILITY to be whatever I want, right? At least within the capacity of a building. It does not have the capability to be a hot air balloon or an automobile.
But, I built that building with a specific purpose. Ask WHY was the building built? You could ask why does your business exist? I have a business license, a degree, money, I want to start a business. Why? I want to own a trucking company. What’s my capability? Owner of a trucking company. To realize that capability I need to break my overarching capability (own a trucking company) down to manageable components (strategic management, business planning, Maintenance management). If you did a CAPABILITY assessment on my trucking company right now I’d score 0 across the board. All I have is a building, license, capital. My full capability has not been realized. right? We do maturity assessments right? What are the assessments measuring/scoring? Our…capability.
This sounds like Capability is realized by GOALS. “I want to be at a level 3 capability by end of 2nd quarter” <– strategic goal. Capability is a measurement of your business model/architecture, whatever you want to call it. Capabilities are measurable, report-able, assess-able, (I'm making up words, yes, but that's the English language for ya), etc. It's a measurement. You're goal is to reach a level X maturity across the all capability's to realize a fully mature organization. Capability's are not a function of the business, they ARE the business. It defines the 'why' of the business in a sense. Example: I wouldn't need a 'product management' capability for a trucking company. I'm not selling a physical 'product'. So having a 'product management' capability defined would be ludicrous. Same with 'Inventory Management'. But I would consider a 'Logistics Management' capability. This sounds like capabilities are what make MY business unique. Hmm. Now, how do I REALIZE that capability? By realizing goals of a capability, er stategic plan (did I just say that?). How do I realize goals? Well, ArchiMate has already defined how to do that.
A capability sits at the highest level of the business architecture. Call it your 'business meta model' if you want. Or totally disagree with me. It's not like ArchiMate has defined a 'Capability' object, but TOGAF has, and it sits in the 'Architecture Realization' section of the Content Metamodel.
I'm not interested in being 'right' or 'wrong' here, I'm more in this for the (hopefully) ensuing dialogue.
Disclaimer: I do not own any Ferrari's, have any desire to own a trucking company, or have a 50,000 square foot 'garage'. Nor do I use BizzDesign's product.
LikeLike
Nice comment (little long) 🙂 (sorry, couldn’t resist)
I think I disagree here. You seem to use capability in a meaning close to ‘potential’. I think that 50,000 square foot empty building can be part of a capability ‘hospital’ (to take one example). One could also say it can become a hospital. In natural language we might say it has the capability of becoming a hospital.
But I (and I think most others in the EA world) use capability not in that sense, but in the sense of being able to get some result. The military, for instance, uses it that way. The ‘capability to deny someone to cross your borders’ or something along those lines. Or ‘the capability to get a fighting force of X size operational anywhere on the world in two days’. For that you need many things that together make up the ‘capability’ and that is the sense I have used. That is what you call (I think) the ‘full capability’. Such differences do not improve the clarity of the situation.
Capabilities can of course be built. That is also what TOGAF says and that is quite clear. I don’t think a capability is ‘realised by goals’, but instead a goal can be that you want to realise a capability. The goal itself does not realise the capability, just as a plan itself does not realise the result. There is often some hard work in between.
Anyway, language, especially natural language, is a dangerous tool when trying to be precise. Thinking ‘capability’ is a ‘single concept’ falls (I think) under Uncle Ludwig’s ‘bewitchment by language’.
LikeLike
Ok. What you’re saying is not “the 50,000 square foot building is capable of becoming a hospital” it’s “what is OUR capability of making it a hospital”. Is this correct?
LikeLike
No, that is not what I meant. I mean that if you call a hospital a capability, you may build it from a building, doctors, nurses, beds, energy, etc. etc.. A warehouse can be made of that same building, a way to stack and move stuff, warehouse personnel, etc.
So, it is not about ‘the capability to become’ (potential) but about ‘the capability of being’ (actual).
A building has the potential to be a hospital or warehouse. A hospital is a capability that is made up of (amongst other things) a building.
LikeLike
The joy of language! It is all about what context it is used in. So you can talk about a “Business capability”, which at a minimim encompasses people, processes and technology. Then you can have “People capability”, which can be the skills, competencies and availability. Or “Technology capability”. Etc, Etc. Sometimes the likes of Business Capabilities can be broken down into sub-capabilities.
Important to identify the services provided by the capability and how these are used by who.
LikeLike
How does this work then from a capability-based planning perspective? If my group is looking at getting into mobile app development, and we have no ‘capability’ of doing so because we lack everything we need to write a single iOS app (business, people, technology to borrow from Ron), how would you describe this since your perspective is locked in at ‘being’ instead of ‘becoming’?
Good discussion by the way. 🙂
LikeLike
Well, it seems to me that you define the capability that you do not have yet (“everything we need”), then you create the capability (e.g. via projects), after which you have the capability.
Of course, the capability to create new capabilities is also a capability which you then apparently have. 🙂
LikeLike
You would define your current and target state for your capability, determine the gap, and then address this through capability increments. This is very well described by TOGAF: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap32.html
LikeLike
It is just too sad, that according to the ArchiMate 3.0 standard, the Business Capability can only be associated with a Business Process and not – as suggested in your nice article – aggregate it (see http://pubs.opengroup.org/architecture/archimate3-doc/apdxb.html#_Toc451758118).
LikeLike
Nobody said that TOG should listen to me 🙂
LikeLike
Quote from the article (third paragraph before Summary): “I have doubted about adding Role to the Capacity aggregate, but in the end decided against it.” should most probably read: “I have doubted about adding Role to the Capability aggregate, but in the end decided against it.”
Regards, Tom
PS.: Excellent and interesting article
LikeLike
Fixed. Thanks. The article is of course out of date now that ArchiMate 3 has a Capability concept (though quite different from the one I proposed).
LikeLike