Communicat.us

Capability driven development is a big topic these days, especially in the DoD. What does that mean? Should system acquisition, design and development be driven by capabilities or by requirements?

We first need to understand the difference between requirements and capabilities.

One easy way to express that is:

What capabilities do we need to obtain and exercise in order to meet our requirements?

For the end user, it is often easier to express their needs in terms of the activities necessary to meet the requirements. If we call that a capability, then we can name it, categorize it, analyze it; and then acquire and deploy it. We can then measure its efficacy to determine if it indeed did meet the requirements.

Having a catalog of well defined capabilities that are already proven to meet various requirements, or can be shown to be insufficient in a measurable way, allows architects to design using known components, assembled in well defined ways, to produce predictable results and/or to design improvements to mitigate insufficiencies.

When we consider a Service Oriented Architecture, the Services are simply capabilities that have been instantiated and deployed. In a sense, Capabilities are abstract services.

If we can characterize, categorize and name capabilities and provide a catalog of them, then we can maximize reuse at a much earlier stage in the design and deployment of Services in a SOA.

Success is getting what you want. Happiness is wanting what you get."

- Brother Dave Gardner       

Requirements are what we want – Capabilities are what we get.

The SOA CORE Architecture team’s goal is to be able to map the customers’ requirements, expressed as capabilities and match them to the capabilities provided by our products. Our sales team will succeed to the extent that our marketing teams correctly read the market and its requirements and then our development teams produced products that provide capabilities that meet those requirements.

The customers’ requirements and the identification of the capabilities to meet them, including non functional requirements, define the "solution".

Requirements go into the product specification. Developers produce the product that provides capabilities to meet those requirements.

Matching the capabilities defined in the "solution" with the capabilities provided by the products results in one, or possibly, more candidate architectures. One or more of them may be chosen to be implemented depending on the customer’s situation.

Expressed (more or less) mathematically:

A problem can be expresses as a set of requirements

Problem = {Requirement}

A solution to a problem can be expressed as a set of capabilities that meet the requirements

Solution (Problem) = {Solution Capability}

So a solution of a problem – i.e., its set of requirements – is a mapping of the requirements of the problem onto a set of Solution Capabilities

Solution ({Requirements}) = {Solution Capability}

Architecture can be expressed as an assembly of products – i.e., the capabilities of those products

Architecture (Solution) = {Product Capabilities}

The architecture of a solution is a mapping of the Solution Capabilities onto the Product Capabilities

Architecture ({Solution Capability}) = {Product Capabilities}