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

Thursday, October 13, 2011

The Service Oriented Enterprise

It’s now fourteen years since CBDI was formed. In the early days our mission was, as a think tank, to evangelize new ideas of modularity, separation, contract based and service orientation.

We had a vision then; it was the enterprise, every enterprise, as a set of services deployed in a cloud.

Of course over the years we have become immersed in the details of best practice, education, and assisting larger enterprises to leverage and realize the SOA concepts. But the vision is still there.

It was around 2005 that we first started thinking about capability as a formal concept. The first report on the subject was in June 2006, and at that time the CBDIers started a long running debate (well argument actually) about this concept. There were two primary issues. First, should a capability be standalone or could it be an integral part of a broader application and technology infrastructure. In the end we couldn’t agree and we compromised in identifying capabilities as standalone or not standalone. I will admit I was in the first camp, and remain there today.

The second issue was should organizations be planning for the entire enterprise to be comprised of capabilities. To be honest this issue received less attention and in the end we never published advice on this. Perhaps it was just too early. Also in those early days there was confusion over capabilities. Was a capability part of a business process, or did the capability subsume the business process? Well of course these questions have long been resolved with experience.

But whilst the capability concept is now widely understood, I wonder how many enterprises have actually taken it to the logical conclusion and organized (their SOA and indeed the business) around them? I see many pretty capability maps, but fewer capability services.

The reason I am returning to this subject is because many organizations are now rebooting their SOA initiative and they should be looking at capability services as the foundation of their architecture. Why?

1. Business capabilities represent a common perspective shared by business design and service implementation.

2. Properly structured capabilities are completely independent (see above) and facilitate change with the minimum horizon of impact. They also support practical analysis and classification of services as core or context which facilitates the sourcing decisions.

3. Looking at how the world works today, the primary strategy must be around ecosystem collaboration. Choose what capabilities are core to your enterprise and specialize in them. Organize around them. Conversely identify the context capabilities and figure out what collaborations will be most complementary and go make partnerships, or offshore or outsource or rent from the Cloud.

4. Plan to implement the entire core of the enterprise as a set of strategic capabilities that are smart, autonomic, and talk directly to the real “end user”. Eliminate all other process interventions and optimize the core capabilities using the very latest technology. Architect and engineer the capabilities to be capable of continuous evolution.

5. Stop talking about SOA, start talking about the Service Oriented Enterprise. It’s a business issue.

We have dedicated this October 2011 edition of the CBDI Journal to this topic. We advise that business design should be synonymous with capability design. In my report on Business Design for the Service Oriented Enterprise, I explore a series of patterns for the smart, continuously evolving, virtual enterprise. I discuss the convergence of ecosystem automation and autonomics, architecture for continuously evolving business, together with the merger of consumer and business IT and how these will have a profound impact on conventional business models, which will in turn affect business modeling techniques and enterprise architecture. In addition we have in depth reports on Capability, Planning and Analysis.

CBDI Journal October 2011

Business Design for the Service Oriented Enterprise

Capability Planning and Analysis


Tuesday, October 4, 2011

Mission Impossible? Or how to achieve the SOA vision.

When I am asked about the state of SOA, I sometimes comment that anything involving architectural change is bound to take a little time. But my more considered response would be that whilst the impression of SOA is now widespread, true implementation of the SOA vision, for most enterprises remains a distant vision, if indeed they still remember what that was.

For me the vision was encapsulated in the report by one of our customers on their SOA progress in 2009. They reported their systems were exploding in size and complexity. They had scant standardization, and there was no single truth. If a core process broke they would change it to fit the application, rather than the other way round. This was crazily expensive to maintain. After four years of transformation they report a 20% reduction in IT staff, 1500 systems closed down, the ability to turn services on automatically for customers virtually as they place their orders and a massive reduction in complexity demonstrated by a rental price change that previously required changes to 42 systems – followed by three months of testing, now requires just one platform adjustment that automates the change process. THAT’S STRATGIC!

In contrast I read a Forrester survey[1] from last year that reported while 47.4% of respondents work in organizations where SOA projects are underway, the original reasons for SOA, reuse and cost reduction, have morphed into data integration, legacy integration, flexibility of application development, and department-level application integration. Perhaps this is why we at Everware-CBDI are observing numerous inquiries about “SOA Reboot”, which is variously explained as interest in doing SOA properly, realizing the vision and or delivering real business benefit.

For many enterprises the root cause of this lack of achievement is very straightforward - SOA requires a strategic initiative that looks longer term than most enterprises are able to do. But for most enterprises this is mission impossible, they are bound by short term goals and budgets.

The solution is not rocket science. What’s needed is a governance system that manages a progression from tactical to strategic. Many SOA efforts today are business process project focused, because simply put that’s where the business priority is today. What’s needed is a governance system that ensures project service solutions can be evolved to become enterprise services, where it makes sense. The overhead in making this leap is that a few new policies are needed that spell out better working practices. Consider some candidate policies.

  • All new components and services MUST comply with a defined minimum level of reference architecture.
  • Implications and strategy for future service reuse is a REQUIRED element of all Plan or Feasibility phase end reports.
  • All projects MUST reuse and evolve existing (loose coupled) services and components before acquiring or building new components

There’s more; to make this work needs good governance plus a product (sic) management system in place, because it will get complex. But it works.

I am writing this practice up for the Quarter 4 CBDI Journal. Make sure you are a registered subscriber so you get a copy on publication.


[1] TechTarget/Forrester Research State of SOA Survey for 2010

http://media.techtarget.com/searchSOA/downloads/TTAG-State-of-SOA-2010-execSummary-working-523%5B1%5D.pdf