Cloud Maturity Model

Over 7 years ago CBDI published its SOA maturity model and roadmap methodology. Over the years it has been widely used by larger enterprises as well as cloned and copied.

Those familiar with the model will recall that the maturity states use service usage patterns to characterize relative maturity - Early Learning, Integration, Enterprise and the mature state is referred to as the Ecosystem, which “follows” the Enterprise state.

Over the years I have worked with many organizations, assisting them to develop SOA maturity models and roadmaps and in most cases the focus has been on achieving Enterprise capabilities. The Ecosystem, while interesting, has been way beyond most enterprises' vision. That situation is changing, and it's interest in Cloud that is the catalyst.

Today the cloud is in a relatively immature state. But at some point the cloud and SOA maturity models will converge and at that point we should fully expect ecosystem like behaviors including commoditization and the concomitant price and cost reduction, standardization of higher order levels of functionality and massive reduction in cost of integration and deployment. At this point the changes to the IT landscape will be profound. The massive swing to specialized service providers that has happened may well be significantly reversed as mobile enterprise, functional standardization and improved economics become normal.

As usual profound market shifts of this nature will cause rationalization of market players – and in the case of cloud it’s by no means certain that big will be beautiful – because the nature of the cloud can actually favour small players.

It’s not too far fetched to imagine cloud based innovation driving macro economics, in the same way that in the past players such as Microsoft, IBM and Apple to name just a few have had deep impact way beyond their conventional market space.

We are still in the stage of maximum hype. Think SOA - it took 12 years to get here, and we are far from done. Cloud has similar architectural impacts but it's the economic and organizational impacts that may actually take SOA on to the next stage. And that was why all those years ago, I and my colleagues envisioned Ecosystem as the mature stage of the SOA maturity model.

I am working on ideas for updating the CBDI Maturity Model and Roadmap to incorporate and detail Cloud based capabilities, and of course to explore the wider capabilities. I hope to publish some initial work in the December/January CBDI Journal. I would be very pleased to hear from anyone who has interest in this area. I have some questions and would be pleased to dialog on same:

1. Is Cloud part of the SOA maturity model and Roadmap? Or is it a separate, parallel model?

2. What are the major stages in Cloud capability maturity?

And a related question - 3. How and when will the security issue be resolved?

4. How and when, if at all, will standards play a part in the Cloud? Looks a bit like the wild west today!
5. What does the Cloud cost benefit model look like?

Interested in Cloud? You may like to read the CBDI Report on Service Portfolio Planning and Architecture for Cloud Services

Minimum Set of SOA Standards?

This following is my reply to one of our customers that asked me to review an SOA standards document. For obvious reasons the client must remain confidential, but I am publishing this as my replies may be of interest to a wider audience.

Dear Xxxxx, The SOA Compliance Standards and Guidelines document you have provided me with for review is a good start. It addresses many of the technical level matters that are needed to create a consistent SOA. However, in my opinion, the document does not go far enough to establish a bare minimum set of standards.

1. The Reference Architecture illustrates a layered service architecture separating service behaviors. Beyond the diagram and superficial text, it is not clear whether there is additional policy information defining the behaviors at each layer. This impression is reinforced by the section on service granularity which talks in abstract terms about optimum granularity. If each service layer is well defined then service granularity will be appropriate to the service type and their behaviors.
2. The requirement for a service contract is good. However WSDL and Schema definition are insufficient. The contract should define a set of properties and behaviors that define the obligations of the parties to the contract in an unambiguous manner that a) effectively hides the implementation details, b) facilitates governance and c) test case generation. Pre Post conditions are strongly recommended.
3. The MDM strategy of entity ownership and (I assume) an event based subscription architecture to replicate changes is a good start, however this seems somewhat immature.
   - There will be entity occurrences that must be synchronized in real time and therefore be part of the core transaction.
   - It is usually preferable to classify individual some COTS services as underlying services and to expose consistent (canonical) core business type data using common services, and drive the pub sub from those common services.
4. The data strategy underlying the SOA is critical to service classification and design, and I would be concerned that this has not been sufficiently thought through.

As we discussed, it’s good to have a strong focus on policy setting – getting consistency of approach in key areas of practice. What is the absolute minimum set of policies I would expect to see in place (at what appears to be an early stage in the SOA maturity model)?

Here I recommend you use the policy structure in the Knowledgebase as a start point. I have summarized below, but the detailed tables will provide you with a much richer list of candidate policy types.

Planning Governance	Organization and control of Services.
	- establish a Service Portfolio Plan – this is an essential step to avoid proliferation, and to decide how you will manage the COTS provided services, and indeed shape the RFPs
Architectural Governance	Ensure the architectural quality integrity
	- get the reference architecture in place asap – again this is crucial to have this in place before you decide on the COTS acquisitions – so you place the COTS services in your architecture, as opposed to simply acquire a disparate set of services and then have to resort to conventional integration.
Sourcing Governance	Determine and control Service Sourcing
	- recommend you adjust RFPs as appropriate to align with architecture - recommend you require suppliers to provide comprehensive service behavioural contracts, not just WSDL
Usage Governance	Determine and control Service usage
	- decide service ownership and as discussed above, whether COTS services are accessed directly or indirectly through core business services
Operational Governance	Control run-time services, including QoS
	- you have a good start in this area – but see the Service Specification template – as this includes the opportunity to review the need for variations from defaults
Best Practice Governance	Determine appropriate development strategies and approaches; including modeling and documentation
	- recommend policies on data modelling and service specification
Service Asset Management Governance	Policies that manage Services as assets including control of state changes
	- bare minimum is change management and specification coordination
Organization Governance	Determine the organizational factors such as roles & responsibilities; funding strategies
	- service ownership needed

Regards, David

Searching for Goldilocks

Found on a ZapThink email:

"Not too technical, not too high-level

Unlike courses offered by SOASchool, CBDI, Web Age, SOA Institute, SOA Certified Professional (SOACP), Architecting the Enterprise (AtE), IBM, Oracle, Software AG, and others, we cover the technology without getting lost in the details. We discuss the big picture but connect it to the day-to-day reality of the IT shop. "

They say all publicity is good publicity, and I am minded to agree. But ZapThink should think carefully before suggesting CBDI courses are too technical! CBDI is renowned for providing a balance of business and technology practice at an actionable level for practitioners – independent of specific technologies.

The proof of the pudding - not too hot, nor too cold . . . . we are happy for you to test run our eLearning classes FREE of CHARGE!

Application Overhaul

Get ready for a stream of well worn ideas given a makeover as Gartner delivers its annual conference. Notably: Application Overhaul. The new name for Application Modernization.

According to Gartner “ . . . Application overhaul is a new take on legacy modernization methods that deal with the backlog of already-built applications – this overhaul is a task that must be successfully executed before IT can move out from the tremendous maintenance burden that saps budget from innovative projects.”

For the last couple of years I and my colleagues have been advising that Application Modernization needs to be more than simply technology driven legacy reengineering. Rather Modernization needs to be just that - application renewal that embraces modern practices particularly business driven SO architecture, but equally component based implementation, portfolio integration and best practices in the areas of contract specification and change management.

So what do we get from Gartner? The equivalent of taking your automobile down the road to the repair shop for a service! Change the oil, fit new brake pads and a good wash!

Concise OED: Overhaul - thorough examination (with repairs if necessary)

Lazarus or Thomas Effect

I note the Burton Group has published a paper titled the Lazarus Effect: SOA Returns. Key message is after a troubled time SOA is being reintroduced and recast in a business context. Don't bother reading it. The Burton Group (remember Ann Thomas Manes?) has a checkered track record in spinning SOA is dead, SOA is being resurrected with a new manifesto etc. It's simply marketing spin from an analyst group that need to keep telling us they still exist, even though they were acquired by Gartner. Or perhaps they feel they need to be active in self promotion to impress their new owners.

While Burton, Gartner and others make an industry by worrying about whether SOA works the world has moved on. Most serious enterprises ARE taking SOA seriously and just doing it. It's only the industry analysts that continue to play Doubting Thomas because they never actually get their hands dirty.

Practitioners in the real world realized years ago that SOA is not an end in itself; it's an architectural style that facilitates better solution delivery and business agility. Rant over!