The essential characteristics of capabilities


Figure 1

A capability is defined as that which provides the ability to achieve a desired effect under specified standards and conditions. Desired effects must manifest themselves as measurable changes in the resources consumed to achieve these effects. These resources must be available when needed by the set of activities selected for a particular course of action in pursuit of these effects. Such courses of action provide the ingredients for an organization to pursue its mission, and for stakeholders to employ the concepts of operation of the systems employed by that organization.

Different architectural frameworks have different interpretations for the concept of a capability. For example, the TOGAF framework uses the word 'capability' to delineate business capabilities for architectures, while using the concept of 'capability increments' in capability planning. In contrast, the DODAF framework uses the data model depicted in figure 1.

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. Within the architecture, activities consume resources that are in one state, and produce resources that cause a transition to another state. Performers perform activities that change the state of resources. Performers do this under conditions that affect their performance. Performers do this by following guidance to perform tasks under specified conditions. All this can be measured, so the performance of an activity can be assessed against standards of performance. In architectural terms: tasks are activities, ways are guidance, means are performers, conditions are conditions, standards are a particular sort of guidance, and desired effects are changes in the states of resources.

Architectural models organize and displaying data in a format which is suitable for making decisions. Viewpoints are thematic collections of models which focuses on data within the scope of some concern, such as capabilities, systems, or standards.  As such, they visualize architecture data as diagrams, 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 an architectural description. Together, these concepts describe all aspects of architectural description.

The meta-model for an architecture definition focuses on defining the architectural data which is required, rather than on the structure or packaging of the artifacts that provide that data. It identifies, defines, and specifies the information needed to describe something within the organization in architectural terms.  There is a wide range of architecture tools that can collect, organize, and store architecture data. The focus on data supports the production of models which can be tailored for multiple fit-for-purpose uses. When these models are sufficiently robust, these tools may also supports analysis and simulation of the content in support of  core decision making processes. Consequently, tools are expected to comply with the well-formed specifications that enable exchanging the underlying architectural data.

The portion of an architecture meta-model relating to its capabilities and their relationships is intended to support a wide variety of activities, including systems engineering, planning, budgeting, portfolio management, acquisition, development and integration,  operations, and execution processes. All components developed within the organization are expected to conform to the meta-model. Because architectural descriptions are employed at many levels, contexts, and purposes within the organization, they vary in content, structure, and level of detail. Based upon an architectural description, developmental and operational activities can be performed which, when realize well-articulated and understood purposes, ensuring that the necessary data collection occurs at the appropriate level of detail to support specific decisions.

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 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 person performing a role may be a part of a system, a service, or an organization, and information is essential for these roles to be performed effectively. 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 to describe activities, guidance, conditions, resources, locations, or capabilities, the data is not pertinent to an architecture definition.

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. Among these conditions are the degree to which the human performers understand, accept, and agree to support this execution. This is particularly relevant when the new capability changes how others think, feel, believe and act about the activities they are expected to perform. This requires 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.