Modeling Capabilities
A capability model provides a description of an ability to do something in terms of expertise and capacity. Capabilities are used to realize concrete goals that may or may not be repeatable within specific situations. They are realized by entities such as people, using other entities such as equipment, infrastructure, and systems. These entities are used in specific situations through interactions.
The 2 primary approaches for modeling capabilities are through an action-oriented (also known as intentional modeling) or an ontology-oriented perspective. The action-oriented approach analyzes all the activities users will want to do with the system, and defines a functional model based only on the actions. The things that an action will use to fulfil its functionality do not need to be modelled, or at best, they need to be modelled only as abstractions. An ontology-oriented approach, on the other hand, is interested in the nature and details of things. Seen through an ontological lens, certain aspects of Richard's life can be represented as entities.
An action-oriented approach (capability as a process component)
A purely action-oriented approach, or considering capabilities as a part of a process, is not primarily concerned with things. Things are only treated as property values, and each action uses and modifies a set of properties, and the manipulation of things is considered business rules. If I need to pack a thing, the action (packing) starts by obtaining the name of the thing (or some other unique identity), and uses the name to obtain all the property values it requires, such as the size and weight of the named thing. Logical operations are performed on these properties, without understanding the nature of the thing being packed. Let us consider steps for packing things into a box.
Fig.1: Using a purely action-oriented approach
determine size of thing: Place the object on a flat surface. Measure the distance from the surface to the highest point of the object, and assign this to a height value. Draw a line in your mind between the 2 points where the object is at its broadest. Measure the distance between the 2 points of this line, and assign this to a length value. In your mind, rotate this line on a horizontal axis by 90 degrees, and measure the distance between the 2 points on the object along this line. Add this measurement to the width value. Assign the values for height, length, and width to a size value.
determine weight of thing: Use a weighing instrument and determine the weight of the object. Assign the measurement to a weight value.
determine optimal box for thing: Using the values for the weight and the size, find the optimal type of box to package the object. Each type of box has a size and a carrying capacity. Find all the boxes where the carrying capacity is 20% greater than weight of the object, and the size (length, width, height) of the box is 20% greater than the size of the object. If multiple boxes are found that meet this criteria, select the cheapest box.
pack the thing into the box: Wrap the object in bubble-wrap, and place it securely in the selected box. Make sure that the object is not loose on any side, and use shredded paper to secure the object. Close the flaps of the box securely, and seal the box using clear plastic tape. If the flaps of the box do not close completely, remove the object from the box, and try and find an alternative box to pack the object.
An ontology-oriented approach (capabilities through objects)
An ontology-oriented approach is interested in the nature of things. Actions are also a type of thing that use other things to fulfil functionality. Ontologies represent the nature of things as they are, and not necessarily for a single business perspective. An ontology of fruits will capture the fact that oranges have orange-coloured skin, that they can be peeled by hand, and that they have light-coloured pips. They will capture the fact that fruits are perishable and edible; that different fruits have different nutritional values; that fruits grow on plants, and that vines, trees, and shrubs are types of plants. If the fruit needs to be packed on tables, they will capture the fact that tables have legs, and usually have a flat surface. They capture the nature of actions, and define different kinds of actions based on their intent, objectives, business contexts, and results. There is a tendency for ontology-oriented functional solutions to become bloated, and offer limited value to practical business problems. The most successful ontologies are references. An encyclopedia is an ontology of information, usually arranged by subject area in alphabetical order. Dictionaries are ontologies of the definitions of words arranged alphabetically. Ontologies can also be succinct. The periodic table of elements is an elegant and succinct ontology of the properties of elements. Ontologies, by principle, are developed independent of the actions that use them. Therefore, it is of limited value in building a business system on a purely ontology-oriented approach, as it is highly likely that the system will contain the characteristics of things that are never used in business scenarios.
In practice, actions will always use objects, and using a combination of action and ontology-oriented approaches produces the most flexible and pragmatic results. I "pack" my "clothes". I "drive" my "car". Making an abstraction on the object-level, based on a common property, will help fulfil the objectives of the system. For instance, if I need to pack apples, oranges, bicycles, and computers into different boxes and pallets on either a steel-reinforced table, conveyor belt, or on the floor, a pragmatic solution would be do define a system that will pack things (an abstraction for apples, oranges, bicycles, and computers) into containers (an abstraction on all the different kinds of boxes and pallets) on a surface (an abstraction of tables, floors, and assembly line). The only properties that would be interesting would be the volume and weight of the things, the size and capacity of the containers, and the size and capacity of the surfaces. The only attributes that matter for the object are those that are used in the context of the action.
Although a table may have legs, a bicycle may have wheels, and a computer may have semiconductor components, these properties are not of interest to the action. From the perspective of the packing action, the only interesting properties are the size and weight of the thing, the size and carrying capacity of the container, and the size, strength (total weight I can put on the surface), and the number of people that can work simultaneously on the surface.
The main benefit of combining an action and ontology-oriented approach is its flexibility. The same action can be reused for different objects and different processes. If variations in the action are required because of the specific properties of the object, a few modifications to the object's properties and the action will suffice. For instance, fresh apples will start rotting in a few days if not refrigerated. Adding the property of being perishable to a thing, adding a property of being refrigerated to some containers, and modifying the action to use refrigerated containers for perishable things will satisfy the requirement. The new properties of the object are all based upon the fulfilling the requirements of the action. It could be interesting to capture the fact that apples and oranges are fruits, and all fruits are perishable, but this additional logic will not add any value to the action.
Deriving an ontology based upon a fixed set of actions usually produces a satisfactory functional solution. However, actions are typically modelled from a single business perspective. In the example, the perspective was oriented around the packing of things, and the interesting properties were those used when the thing was being packed. Things however, can also be sold, so it becomes important for things to have prices. Things can be sold on websites, so it becomes important for things to have pictures and descriptions for customers. The floor can be considered a surface if it is only used for packing things. But a floor can also used for storing things and parking vehicles. From the perspective of a business scenario that uses the floor to store things, it is not a surface, but a large storage area. Similarly, from the perspective of parked and moving vehicle, the floor is a collection of spaces and paths. Arbitrarily adding properties to the surface on the basis of new perspectives will result in an unmanageable functional model, and a rigid system. Most business systems are built from a single business perspective, and modifications are attempted later to suit other business perspectives. This results in a business system that fulfils one perspective well, and others poorly. Over time, the business system's shortcomings result in several business systems for each business perspective.
Note: Some would argue that having a system for each business perspective isn't necessarily a bad thing. Each system can be specialized for a business area, and systems can work together through integration. This is certainly the view that organizations with a high quotient of legacy systems, or vendors of integration platforms, must take. However, the total cost of ownership, in terms of staffing, implementation time, service delays due to integration failures, maintenance, and support is much higher than a unified system.
Fig.2: Using a purely ontology-oriented approach
The optimal scenario would be for a functional solution to consider all of the relevant business perspectives. Returning to the example, things need to be ordered, stored, packed, and moved. Each of these form a different business perspective on the same thing. From the perspective of the order, it is important to specify which size or colour of the thing is being ordered and the price of the thing. From the perspective of storage, packing, and logistics, it is important to know if the thing is sensitive to certain conditions (e.g. temperature, vibrations, etc.), the stability of the thing (e.g. fragile, flammable, hazardous, etc.), the size of the thing, and the weight of the thing. Given these perspectives, these are the only properties of "things" the system must capture.
Note: Actions, within an enterprise architecture, can be translated as services, and the things can be translated into a domain model. The cumulative set of actions will form the basis of an enterprise service catalog, and the accumulated things with their properties and behaviour will form the basis of an enterprise domain model.
Fig.3: A combined action and ontology-oriented approach
Some awkward questions
What happens if we want to pack liquids or gases? What happens when we want to pack an extremely fragile object? What if the object has sharp edges? What if the object can change shape while being transported? What if the object contains parts that can easily fall off while being transported? What if the object is alive (e.g. a plant)? Under what pressure and temperature should the object be packed? What if the object needs to contains air when it was packed at sea-level and room temperature, and it is subsequently transported by air cargo? What if the object needs to be kept in a specific position (e.g. upright) while it remains packed? What happens if the box is exposed to rain? How long can the object remain packed?
Dealing with vagueness, unforeseen circumstances, and reductionism
For a capability to be reusable, it needs to be specified using generic and abstract language. On the other hand, generic and abstract language can be appear to be vague and incomplete to practitioners. The capability definition for packing didn’t specify the types of objects that could be packed and how to take into account non-solid objects. Assuming that the objects were solids, it assumed that all of these objects would fit well into a box. It didn’t take into account how the object and the box would be transported. It assumed that once an object is packed into the box, the box and the object will remain an integral whole and neither will change. The capability failed to specify the materials used to make the box. Someone practically applying the capability definition could assume that the boxes are made from the most common material for common boxes (e.g. cardboard). Someone else could assume that a variety of containers are available for liquid and solid objects. Some of the common errors in defining reusable capabilities are:
Poor generalizations: Generalizations make abstractions before considering a sufficient body of facts. Examples are: "all situations for packing are essentially the same"; "packing is a generic skill set, and a packer is a generic role"; "the tasks for packing different types of objects are the same".
Abnormal conditions: What if the box is exposed to rain or the object is exposed to extreme cold? What happens if the object contains air when packed at sea-level and room temperature, and then it is taken to sub-zero temperatures at very low pressures?
Incomplete definitions: The definition of the packing capability didn’t define the nature of objects or boxes. The packing definition will only work in these circumstances if the following are true: Objects must be solids that do not change state between temperatures of -20 to 55°C and pressures of 1.2 to 0.4 kg/cm2; It must be possible to pack the object into a cuboid box or a rectangular cuboid box; Objects being packed do not require to placed in any specific direction, i.e. their containers do not require a notice stating "this side up"; Objects cannot be living things; Boxes are made from cardboard and must not be exposed to rain or moisture, and should be stored in dry conditions at all times.
Conflicting defaults: Conflicting defaults occur when pre-defined state of an object conflicts with reality. Consider these 2 constraints for placing objects into the same container: High density goods must not be loaded on top of low-density goods, and liquids must not be loaded on top of solids in the same container. How would these 2 constraints apply to the transport of Mercury together with Steel? Mercury has a higher density than steel, and should therefore be placed below the steel. However, Mercury is a liquid at room temperature, and liquids should not be placed below solids according to the second constraint.
Unanticipated applications: Packages are boxes that contain objects. What about boxes that do not contain any objects, and are only used as "cushioning" to fill out the empty spaces in a transport container? Similarly, the "missed call" on mobile phones was designed to let users know that an opportunity to communicate with someone else was lost. However, what if the "missed call" was the intent of the call and contained communicative intent? If 2 parties have a pre-arranged understanding of what the missed call meant in advance, such as a couple deciding to meet in front of the shopping mall when either receives a missed call, then the missed call has an unanticipated application.
Artificial compartmentalization: The capability for packing suggests it is an activity that does not depend upon information from any other activity, and that no other activity depends upon it. Before packing can occur, the items that need to be packed are selected. This selection process is optimized so that each packer gets a set of objects that can be efficiently packed into a box. The packer must know the destination and manner of transport for the package, so as to ensure that the contents of the package do not get damaged. If the products being transported are unfamiliar, the packer must be able to obtain the handling information about the products.
It can be argued that many of the common errors in defining capabilities do not need to be defined as they fall under "common sense", "intuitions", and "habits". Indeed, capability definitions should not cover the obvious facts that do not add practical business value, such as the molecular structure of boxes. However, undermining a complex job such as a packer being easy or simple disrespects the knowledge required to fulfil the role. In order to develop a mature capability model, complexity should not be covered up by vagueness (e.g. "do work") or misdirection (e.g. "all this detail is not important"; "everyone knows how this will really work").
Using the power of anecdotes
Knowledge models have their limitations. After all, they are only representations of reality. Accompanying capabilities with anecdotal evidence can enrich them, illustrating how they are applied in practice. Consider this short extract from a larger anecdote given by a customer service representative:
"Only 20 minutes after I was assured by Customs that the complete package would arrive at the delivery location, the customer was calling me back asking why only 4 of the 6 packages in his order had arrived. I didn’t know what to tell the customer!"
In this short excerpt, we can feel the frustrations of the customer service representative, and the situation of confronting a customer you know you cannot help. Emotions are often lost in the process of requirements management, and stories like this one help connect capability models to the operational realities they must face every day.
Towards a more complete capability model
A key organizational decision is whether a capability model is designed to empower people as knowledge workers with computation systems playing a supporting role, or to put computational systems first, with people playing a supporting role. For the purposes of this article, I will assume you want to empower people before computational systems. As any formal model of a capability can never be complete, the best we can hope to achieve is to develop a knowledge model that most closely approximates the reality of applying the capability in practice. By clearly stating the goals of the capability, and the sub-goals for each task, a knowledge worker can determine the optimal manner to complete their work for the unique situations they face every day. Common knowledge required for all packing tasks can be represented as a shared ontology.
Fig.4: A capability model with goals, related events, perspectives, roles, involved objects, and common knowledge
In conclusion
A specification of a capability needs to be both reusable and applicable in practical situations. Capabilities could be modelled as process components, or be defined purely through a language of business entities. The ideal balance is to use both a language of actions and entities. In order to further refine the practical applicability of a capability, goals, related events, and common process knowledge can be added to the capability model. Unforeseen situations and vagueness can be avoided by attaching anecdotal evidence to the capability.
