Error message

User warning: The following module is missing from the file system: mollom. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1156 of /volume1/web/drupal/includes/

The essential characteristics of capabilities


Figure 1

A capability is defined as that which provides an ability to achieve a desired effect under specified standards and conditions. Such desired effects must be observable as changes in the resources consumed in performing a defined set of activities. Such activities provide courses of action which form the means for an organization and its performers to pursue an organization's mission.

Different architectural frameworks have different interpretations of the idea of a capability. For example, the TOGAF framework uses the word to delineate business capabilities for architectures without prescribing how such capabilities to be achieved. The TOGAF framework uses the concept of 'capability increments' as building blocks which are essential to capability planning. but delegates the means of developing, enhancing, and delivering necessary capabilities through other governance instruments. As a result, when either underlying governance is limited, ambiguous, or inconsistently applied, it can prove difficult to diagnose and resolve problems of performance which may be hidden by the abstract idea of a capability itself.

In contrast, the DODAF framework adopts a more specific meaning for the concept of a capability, which is depicted in figure 1. This representation is notable in its modeling of resources as abstractions of information, material, and performers. Architectures define how such capabilities should be resourced to achieve these desirable effects. This requires consideration of the system of interest's variety, mode, and mereology, as well as the praxis of its production. Within the DODAF framework, activities consume resources that are in one state and produce resources that result in a transition to another state. Performers perform these activities under conditions that affect their performance. Performers do this by following guidance sufficient for guiding them to competently perform tasks under specified conditions which will produce acceptable outcomes. All this should be measurable so that the performance of an activity can be assessed against standards for that performance. 

Architectural models are expected to organize and display data in a format which is suitable for making decisions, which may require the synthesis of information from many sources. Viewpoints are thematic collections of this information which focuses attention on the scope of concerns of these sources and of the decision-makers, with respect to capabilities, systems, and performers that are used in managing performance.  As such, they visualize architectural data as combinations of diagrams, pictures, narrative text, matrices, tables, dashboards, and other representations. A set of viewpoints, accompanied by definitions of the entities they use and their relationships, are the ingredients of these architectural descriptions. Together, the elements which make up these descriptions must be adequate to achieve all significant aspects necessary to achieve architectural coherence, 

In general, activities consume resources and produce other resources. Activities produce resources which can be used by other activities to accomplish further transformations of resources. Since performing an activity by trial and error is unreliable, the steps of an activity should be performed under a defined set of conditions. These conditions affect the way a performer can carry out an activity, and these conditions are seldom perfect in the real world. These constraints limit anomalous behaviors; this guidance can take the form of rules, standards, and agreements. An important example of such constraints deserves special attention since activities are performed at physical locations, which make it important for co-location, since certain resources are only available at specific locations. 

Each activity associated with a capability is performed by a special kind of resource, which is called a performer. Projects select performers which meet specifications for realizing capabilities by consuming materiel, resources, and time. Materiel encompasses anything a performer needs to perform an activity. Systems, services, and organizations are all types of performers, and thus are resources which must be managed as assets. Performers can consist of a complicated mix of systems, services, organizations, and persons performing roles. A particular individual person performing a role may be a part of a system, a service, an organization, and many different combinations of these elements; information and competency are essential to the effective performance of these roles in each context. This information may describe activities, guidance, conditions, resources, locations, and capabilities. Data is a kind of this information and is also a kind of resource. Unless data is necessary for the description of activities, guidance, conditions, resources, locations, or capabilities, the data is not pertinent to an architecture definition.

Figure 2

Changes are ever present in the pursuit of each capability's target outcomes. These changes include intentional changes in a system of interest's state as the result of informed decisions, changes introduced by the environment that require evolution in how the system operates, changes necessary to correct or complete some component the system, and changes in the selection of activities to be performed as a result of prior inputs and states. In each of these situations, the system changes behavior as it transitions from one configuration of information to another over time. This evolution is particularly interesting when the transitions are initiated by one or more decisions, whether performed by a human or an algorithm; the combinatorial pathways through the system quickly explode and complicate the required integration of each capability with others it interfaces with.

The level of resources necessary to perform a capability may vary according to the conditions under which it is executed, such as the lifecycle model which it is performed within. These conditions include the degree to which the human performers understand, accept, and agree to support this execution and assure the fitness of artifacts which they produce and consume. This is particularly relevant when an enhanced capability requires changes to how others think, feel, believe and act about the activities they are expected to perform. The cognitive aspects of these changes are of particular concern and require them to recognize situations, properly infer the meaning of those situations, formulate intentions, and translate those intentions into courses of action. This means the human factors are among the most important of those necessary for a capability to be successful, yet they are not even acknowledged in most architecture frameworks. Perhaps that is why such frameworks so often fail to meet their intended purposes.