Name: / Naming a capability is a first step in defining it. There is a long standing tradition in the pattern movement of collaboration and discussion towards finding the “right” name, the one that best describes what the capability is about. Having two or three people brainstorm about a name is quite useful. In our work we’ve found that the more often you use the name, the more meaningful it becomes to the group.
Intent: / This is the “elevator pitch” - one to two sentences describing the essence of the capability. Expect to take some time and apply careful consideration to create a statement of intent.
Description: / An explanation of how the capability works. Such explanations can range from a short statement to an extended overview.
Solution Story: / One or more “for example” pieces – a stories of a capability in action. Each story should include a short description of the situation, the challenges present and how the solution helped. We find that a screenshots and/or other graphic illustrations are essential to get stories better understood. The stories could be “real” or envisioned.
Vintage: / The maturity of the capability. Vintage can be “conceptual”, “research prototype”, “early commercialization”, “mature commercialization”, or “general industry adoption”.
Challenges: / A challenge is an obstacle or predicament that the business is facing that stands in the way of realizing some desired improvements or transformation of the business. Challenges are often revealed by barriers or ‘pains’ that users and stakeholders are experiencing.
Forces: / Business forces that indicate the need for the capability. By business forces we mean any new or existing condition that is affecting the business.
Business Results: / Results business wants to accomplish. For each key result we identify measurements that could be used to assess effectiveness of the capability towards achieving it.
Capabilities: / A list of functions that the Capability Case provides. These can be thought of also as “responsibilities” (in the CRC sense) and can be related to Use Cases.
Typical Use Scenarios and Guidance: / Best Practices and Lessons Learned for the capability, implementation guidance and some information on obstacles, technical or organizational, that an enterprise may need to overcome in order to successfully deploy the capability
Applicable Technologies: / When people are intrigued by the capability or see a possible application of it in their own context, they will invariably want to know “how was it done?” or “how could it be done?”A list of products or a brief description of the technology used completes the Capability Case.
Implemention Effort: / An order of magnitude estimate of implementation costs and complexity to help in prioritization and decision making.
Integration: / Capabilities are building blocks for business solutions. Two perspectives of integration are of importance: mechanism and strategy.
Integration Mechanism: / Mechanisms define ways in which a capability is invoked as a part of the overall solution. The following 4 mechanisms are distinguished:
- UI Integration - the simplest form of integration. Examples include making a capability accessible through a link on the web or as a “portlet” in a portal.
- Task-centric Integration - one example of this mechanism, is an Instant Helper screen with a "Can I help you?" message popping up when a user hesitates at a check out in the e-shop.
- Data-centric Integration - when data is shared, aggregated or exchanged.
- Process-centric Integration - when a capability is triggered by events in a process or has to generate events for other capabilities or processes.
Integration Strategy: / Strategies represent different architectural approaches for integrating capabilities. The following distinctions are made:
- Proprietary Plug-ins - used when integrating additional capabilities into large grained functional components that offer some degree of openness through proprietary APIs. The style could operate on multiple levels.
- Cooperative Applications - an example is a cooperation of MS Word and Groove where each serves a clearly separate function and operates independently. At the same time, a MS Word document could be stored and version controlled by Groove. Another example is two custom business applications that serve separate business functions where one sends a weekly data extract to another.
- Common Integration Framework - requires a set of agreed protocols used by different applications to communicate. Examples include various Enterprise Application Integration (EAI) platforms, Service Oriented Architectures (SOA) for Web Services, COM/DCOM, J2EE and CORBA platform and architecture frameworks. Interoperability is achieved through an application profile.
Copyright © 2005, TopQuadrant. All rights reserved.