In order to evolve from a view of architecture focused on systems to one focused on capabilities, we need to define what a “capability” is. And as I’ve mentioned, that means defining what a “task” is. After all, if a capability is the ability to complete a task, then it follows that we cannot define “capability” until we define “task.”

A task is a representation of the change in the state of the world. Put another way, a task is a potential change in some set of values that measure the state of the world. To complete a task is to change those values–that is, to change the state of the world. For example, if the task is to sharpen a pencil, then we can say that the current state of the world (i.e., the pencil is not sharp) is represented by the angle formed by the point of the pencil, say 45 degrees. We can define the task “sharpen the pencil” as a change in the angle formed by the point of the pencil to some value less than 45 degrees. If we change the angle formed by the point of the pencil to 40 degrees, then we have completed the task of sharpening the pencil.

Stated more generally, we can define a task as a change in some set of values measured at time t1 and time t2. This gives us the foundation for formally defining a capability, but as a capability is defined as being able to complete a tasks under specified conditions, it follows that we must also define what we mean by “specified conditions.” At least some of those conditions are restrictions on the task itself. Possible conditions include:

• Thresholds for each value as measured at t1 and t2
• The time elapsed between t1 and t2
• The rate of change in any value over the interval t1 to t2

There are many other possibilities for “specified conditions” which I will explore in more detail as time permits.