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