Wednesday, October 26, 2011

Let's Kill the Confusion About Capabilities for Once and All!

I note in the Business Process Trends Advisor Paul Harmon is confused about what is a capability. What Harmon is missing is that capabilities are not just another modelling device that further helps to understand the business. Rather they are core structural concepts that allow us to establish independent units of capability. Capabilities are coarse grained business components that are inherently reusable. We define the characteristics as follows:

  • Service Oriented: Offers a software service.
  • Composite: May encapsulate all manner of behaviors including process, utility, core business (data) services.
  • Enduring: Outlives changes to how it is realized or the business processes that use it
  • Process Independent: May be used within several business processes
  • Implementation Independent: independent of how, where or by whom the capability is realized. Does not pre-empt or expose how each action is executed internally. Internal processes could therefore be changed and not impact the user of the capability service providing the contract remains unchanged.
  • Minimum Dependency: May depend upon another where a) it needs some other capability to have been exercised first or b) where there are internal dependencies. Some capabilities can be independent or self-contained. See below.
  • Measurable: Performance must be measurable

CBDI recommends:

  • whilst “not standalone” capabilities may be tactical necessities, standalone, fully independent capabilities are essential for maximum business agility, enabling replication, offshoring, ecosystem partner provisioning etc and reducing the horizon of change
  • also enabling maximum business agility, capabilities should offer a software service which is externalized, exposing the business capability to a wider world.

Harmon asks for examples. Look no further than Amazon – they offer well-formed capabilities that externalize the Amazon business such as Cloud Service; Storefront etc.

For more on this topic see the October CBDI Journal. It is free with simple registration.

Business Process Trends Advisor - Capabilities Again

6 comments:

  1. Very good description of capabilities. I would add that the boundaries of the capabilities must be defined at the business level and extend through both the technical and data levels.

    I don't agree that reusability is a core characteristic of capabilities.

    From my perspective, capabilities are "discovered" through partitioning the business into closely related ("synergistic") clusters of business functionality.

    ReplyDelete
  2. Hi Roger, Great addition, fully agree with the business context. Regarding reusability, I accept it's discretionary, but given the fast moving nature of business today and in the future, I believe strongly that real agility is engineered with these reusable blocks of business capability.

    ReplyDelete
  3. The problem with reusability is complexity. The amount of complexity we need to add to components to make them reusable is usually (but not always) not justified based on the reuse value that is actually achieved.

    ReplyDelete
  4. Perhaps we are talking at cross purposes with the term "reuse". Reuse of a business capability happens because the capability is naturally stable, generalized and customizable (by the consumer) and can be used in many different contexts. Think about my examples of the Amazon services.

    ReplyDelete
  5. This is a good description of capability. I have a couple of questions.

    What's the relationship between capability and responsibility (e.g. why capability and not responsibility from the CRC modelling technique).

    What's the relationship between capability and service. Can a service provide multiple capabilities? Can a capability be presented via multiple services (at the same provider)? Why would you want/need to do either of these beyond a basic 1-1 mapping between capability and service?

    ReplyDelete
  6. Hi John, Great questions see below.

    Q: What's the relationship between capability and responsibility (e.g. why capability and not responsibility from the CRC modelling technique).

    A:Great question. The CRC Responsibility is (according to Fowler) something that an object should do; an action the object performs, some knowledge the object maintains, or some important decisions. It’s therefore a matter of granularity and refinement. CRC may be a great technique for discovering capabilities, but you need to apply the filters (characteristics) outlined in my blog.

    Q: What's the relationship between capability and service. Can a service provide multiple capabilities?

    A: If it’s a process service Yes. If it’s a capability service I suggest No.

    Q: Can a capability be presented via multiple services (at the same provider)?

    A:Yes if they are process services. The more complex scenario is how about if you have multiple instantiated capabilities – for performance, capacity, load or geographic reasons. However I would handle this by mediation and therefore offer one capability service interface and use the broker pattern to switch depending on context.

    Q: Why would you want/need to do either of these beyond a basic 1-1 mapping between capability and service?

    A: I think I have answered this.

    ReplyDelete