Seven stages of SOA maturity: from silos to services

Many of you who have visited this site over the years may have noticed somewhat of a bias toward small-scale SOA as the best way to get things rolling within the enterprise -- particularly if there is resistance or benign neglect on the part of management to new ways of doing things.

But, sooner or later, if you have a bunch of under-the-radar efforts going on, they need to be brought together, or risk becoming stovepipe projects within their own right. This is where a solid enterprise architecture approach needs to come into play. As Dr. Chris Harding of The Open Group puts it:

"Many enterprises have undertaken small-scale SOA developments as part of a learning process. This is an excellent way for them to introduce SOA, but they often find it hard to extend beyond the initial pilot. Developers complain that they cannot justify the infrastructure that they need. Of course not! Expensive infrastructure cannot be justified on the basis of small projects and, in any case, looking for business justification for technical spend is putting the cart before the horse."

I've had the pleasure of participating in panels with Chris over the years, and he always has a keen grasp of what is happening at the ground level on up with all things SOA. Chris has just published a new book under the aegeis of Open Group entitled The SOA Source Book.

And let's face it, if SOA is as successful as you want it to be, it's going to be "large-scale" SOA at some point. The key is to always start SOA with the business need -- numbing or eradicating the business pain point -- and the way to make sure SOA is on track with the business is through a enterprise architecture. As Chris observes: "Enterprise architecture creates long-term IT strategy in the light of business possibilities and needs. Inclusion in such a strategy is the only good justification for large-scale SOA."

"It takes far greater knowledge and skill to erect a skyscraper than to build a house," Chris also points out.

Chris also identified the seven stages of SOA maturity, which provides some good reference points for an organization to see where it's at on the maturity scale:

1 - Silo: Need we say more? Chris defines this rudimentary condition as a situation where "Individual parts of the organization are developing their own software independently, with no integration of data, processes, standards, or technologies."

2 - Integrated: Getting better; at least advancing into the 1990s. "Technologies have been put in place to communicate between the silos, and to integrate the data and interconnections. The construction of an IT system that integrates across different parts of the organization becomes possible. However, integration does not extend to common standards in data or business processes. Therefore, connecting two systems requires a possibly complex conversion of the data, operations, and protocols that they use."

3 - Componentized: Sounds more like SOA. "The IT systems in the silos have been analyzed and broken down into component parts, with a framework in which they can be developed into new configurations and systems. There may also be some limited analysis of the business functionality into components. Although components interact through defined interfaces, they are not loosely-coupled, which limits interoperability between systems in different parts of the organization, or different organizations within the business eco-system."

4 - Services: "Composite applications can now be built from loosely-coupled business services. The way that services may be invoked is based upon open standards and independent of the underlying application technology. The services have an IT infrastructure that supports them with suitable protocols... However, at this stage the composition of services is still performed by developers writing bespoke code, thus limiting the agility of the development of new business processes."

5 - Composite Services: "It is now possible to construct a business process for a set of interacting services, not just by bespoke development, but by the use of a composition language to define the flow of information and control through the individual services. This permits the assembly of business services into composite business processes."

6 - Virtualized Services: "The business and IT services are now provided through a level of indirection. The service consumer does not invoke the service directly, but through a virtual service. The infrastructure performs the work of converting the virtual service invocation into an invocation of the real service...." The virtual service thereby becomes more loosely-coupled from the infrastructure on which it is running, permitting more opportunities for the composition of business services."

7 - Dynamically Re-Configurable Services: This is the actualization stage for SOA. "Prior to this level, the business process assembly, although agile, is performed at design time by developers (under the guidance of business analysis and product managers) using suitable tooling. Now this assembly may be performed at runtime, either assisted by the business analysts via suitable tooling, or by the system itself. This requires the ability to access a repository of services and to query this repository via the characteristics of the required services. In its simplest form, these characteristics may have been defined in advance, restricting the system to selecting and locating specific instances of services."