If we are going to define a “capability-focused architecture,” it follows that we must define what, exactly, a “capability” is. The US Department of Defense defines a capability as “the ability to complete a task or execute a course of action under specified conditions and level of performance.” This is a more specific definition than that provided by most dictionaries, and in the arena of solution architecture, specificity is important.

Given that definition, how do we specify what a “capability” in terms that are meaningful enough to support a formal architecture model? To do that, we have to break down what a capability really is.

To start, let us take it as axiomatic that a capability may be composed of other, lower-level capabilities. For instance, the capability to drive a car is composed of the capabilities to start the car, to keep the car in the selected lane, to accelerate, to slow down, etc. So, any definition of “capability” must be recursive–there will always be some lower level of capability that could be decomposed. Given this, our primary tsk is to define how to describe the lowest level of capability that we desire to break down.

First, we must define what we mean by “task” or “course of action.” For the sake of simplicity, let us confine ourselves to defining a “task” at this time. Another way of thinking of a task is to effect a change in the state of the world. That is, there is some characteristic of the world that we can measure, and a change in the value of that measurement by some specified value indicates the task has been completed.

Second, we must define “specified conditions.” This is another way of saying “the current state of the world.” That is, the specified conditions are in reality a set of measurements of the characteristics that we care about. Completing a task means changing one or more of those values by some specified amount. “Specified conditions” means the initial measurements of those values that define the state of the world (obviously, limiting our definition of “world” to those characteristics that are meaningful to the problem at hand).

Finally, we must define “level of performance.” Level of performance has two aspects. The first aspect of level of performance is to define the acceptable rate of change of the characteristic of the state of the world which defines completion of the task (e.g., complete the task faster than some established time). The second aspect of level of performance is to define the acceptable amount of change to all the other characteristics of the state of the world (e.g., change characteristics X by amount Y white characteristic Z remains constant).

Defining a capability in this fashion provides the foundation, but by no means the full structure, for a capability-focused architecture. In fixture posts, I will try to flesh this idea out in greater detail.