David Sprott

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

by

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

The Service Oriented Enterprise

by

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 enterpr…

The Service Oriented Enterprise

by

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


Mission Impossible? Or how to achieve the SOA vision.

by

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

… so you should do a SOA Certification! But which one? And how?

by
After a near death experience SOA is alive and well. After mixed early learning experiences, most enterprises are seeing SOA in a fresh light. Just the other day one company was discussing with me their “SOA Reboot” project! They are in good company.
I observe widespread activity that is based on doing SOA properly a second time around, including portfolio planning, shared services, good governance and not least education and certification of in-house practitioners and service providers’ personnel.
There are several sources of SOA education and certification including ZapThink, SOA School and Everware-CBDI plus several of the larger vendors. At Everware-CBDI we have approached the certification process as a result of our extensive model based practitioner experience and the creation of a comprehensive methodology and approach documented in the CBDI-SAE Knowledgebase. Our customers who have subscribed to the CBDI Journal over 14 years acknowledge us as an authoritative source of in-depth practice guidance for business driven architecture, specification, design, management and governance.
Our approach has been rather different to the other vendors.
1. We realize that while certification is important, it is critical to minimize the cost and particularly the time involved in obtaining a quality certification.
2. We have prioritized making the entire process online from start to finish.
3. Time and cost optimization is particularly important for service providers who are driven by high utilization targets. Equally end user enterprises and government departments are also under pressure and appreciate sharp focus.
4. We don’t re-label videos of Face to Face classes as eLearning; we create short, narrow focused, fully scripted elearning modules that are purpose designed.
5. We organize the modules into syllabuses for different roles. Of course SOA is about architecture, but we package the learning for architects, designers and project managers to make it as efficient as possible.
6. We believe education and certification is part of continuous learning and skills development. That’s why our certification is backed up with the CBDI-SAE Knowledgebase containing detailed meta models, profiles, process descriptions, patterns, task and technique descriptions, together with deliverable templates and other useful tools, plus a vast inventory of guidance. All cross referenced and consistent with the eLearning. A practitioner’s toolkit!
The table below attempts to compare the options available for education and certification. E&OE.

CBDI ZapThink SOA “Schools” Vendor Training
Online Learning and Certification ☑ ☑ ☒ ☒
Online Price $1200 or $399 per syllabus $1995 ☒ ☒
Integrated Best Practices, Guidance and Resources ☑ ☒ ☒ ☒
Syllabuses for Architecture PLUS other roles ☑ ☒ ☑ ☒
Self Study Resources Bundled ☒ $1596 or 50% discount with F2F course ☒
Certification and Exam Cost Bundled Bundled Bundled $200 – 300
In house Corporate or individual use. Volume discounts ☑ ? ? ?
SCORM compliant for enterprise LMS integration ☑ ☒ ☒ ☒
Vendor Independent ☑ ☑ ☑ ☒
Deployed online by world leading service providers and enterprises ☑ ? ? ?

Try the sample CBDI eLearning and Certification Modules (no charge registration required)

Service Oriented Cloud (SOC)

by

I am almost shocked by the vast volume of tweets hitting #Cloud. Of course it’s a reflection of the frenetic level of interest in the subject. But it’s also because Cloud Computing is such a huge, complex domain.

Following in the well-trodden path of many new information technology concepts we might expect morphing to occur. Much of the Cloud focus has been about infrastructure and technology, plus commodity applications, productivity tools and multi-tenant Web applications. Whilst all the really good Cloud environments are Service Oriented, it’s very much the minority of consumer SaaS that is today.

Yet it’s very obvious the next stage of Cloud will be about enterprise services. And as private and virtual private Clouds become respectable and trusted, we should expect a huge push by enterprises to demand modernization and rationalization of application landscapes into the Cloud with cost and agility objectives in mind.

But while everyone calls everything a service there’s potential for huge confusion. Further everyone needs to know that right now few existing applications, regardless of how recently they have been “modernized” are Cloud ready. Regardless of private or public Cloud deployments, they need to be genuinely secure, componentized and service enabled and many of them need to be multi-tenant architecture if they are to deliver the expected cost benefits.

To differentiate between the morass of stuff that’s happening and what’s needed in a genuinely Cloud ready SOA environment, I propose we start right now referring to the SERVICE ORIENTED CLOUD or SOC for short. It’s small step, but it will make life easier for everyone, and indeed allow those of us focused on the SOA enabled SaaS layer to have a nomenclature that works, as opposed to continuously committing unintended double entendre.

I recommend we start by hitting #serviceorientedcloud