Communicat.us

In my previous blog, I discussed the idea that architecture is the mapping of requirements to capabilities.

Are these mappings "one to one" and "onto"?

The mapping is into – not onto, since some requirements may not be met by existing capabilities, and some capabilities may not satisfy any particular requirement, but are included because they come along as part of other capabilities that are required.

The capabilities that are required, but do not exist, define the scope of the architecture that must be engineered and developed.

The mapping is many-to-many. Many requirements can be satisfied by a single capability, and several capabilities may satisfy a single requirement. Of course, both requirements and capabilities may be complex concepts that can be decomposed into simpler entities.

For example:

• One requirement satisfied by more than one capability: A requirement to control access to a computer system could be satisfied by a userid/password authorization and/or biometrics authorization capability.
• One capability satisfying more than one requirement: Biometric identification can be used to meet authorization requirements, and provide usage pattern data.

So you are saying map some requirements to capabilities?

Yes, but even more than that.

End users are often much more conversant in expressing Requirements in terms of the capabilities that they envision they need in order to accomplish some goals or to complete a mission.

The IT guys, architects, designers and engineers, need Requirements specified in very precise terms in order to practice their magic. When end users evaluate a product they ask: "What does it do?", or "How do I use it?" – not: "What requirements does it satisfy?".

Ideally, end users express their needs in terms of capabilities that architects – through, modeling and analysis express in terms of requirements – usually functional requirements.

We make one further assumption, and that is, most of the requirements for any IT system have already been identified, analyzed, and realized in existing products. A key strategy that we are enabling is to map users’ expressions of capabilities directly to the capabilities provided by existing products. Using this approach, we can identify several candidate architectures that utilize existing products, and refine the design based on nonfunctional requirements. This gives the designers and implementers the luxury of concentrating on the really new and innovative aspects of a system and provides an infrastructure for testing those innovations that can be modified at the model level and generated as often as needed without extensive overhead.

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}

Service Oriented Architecture is moving toward being integrated and deployed as a platform.  In early SOA development everybody used  a different software vendor, many using several in an effort to go best of breed.  Over time people have realized that you can get a complex SOA to work with best of breed products.  You need a talented systems integrator, but it can be done.  However as time marches on, because the vendors are not synchronized with their releases, fixes, and so on, the stack falls out of sync.  Problems develop that are difficult to fix as they bridge multiple vendor modules.

A trend has developed that understands the core functioning of the SOA is not something by which an integrator can distinguish itself.  Furthermore, if they spend a lot of time in the bowels of the SOA they inevitably spend less time focusing on building mission services and functionality.  Because of this conundrum integrators have become receptive to software vendors delivering a fully functioning SOA stack.  This Core is then used as a springboard to jump start mission development.

The diagram above shows the basic configuration of a SOA Core.  Customers have learned that leaving capabilities once through optional, such as ‘Monitoring & Management’ until later causes problems.  IBM has developed a basic set of SOA software that comes preintegrated as a SOA Core capable of federating across multiple nodes.

This Core, deployable in a day, provides the basics of an SOA node.  This platform-based approach recognizes the need to lift customers up out of the SOA.  In the early days people were fascinated by SOA.  Now they wish it would just work.  This evolution of usage pattern is typical with technology.  Customers are at the phase where they’d like to get SOA working quickly and realize the mission value of it versus the technical wow factor.  When a software vendor, like IBM, can show up with a blade center, plug it in and the SOA is already up and running – then customers are happy to use SOA for their real mission problems.  This platform-based approach, being the natural evolution, will replicate itself at the federation level as well.  More on that later.