Does the industry need an SOA maturity model? While there is agreement that organizations need guidance in implementing...
an SOA, what a maturity model should include and who should be driving it —vendors, consultants or independent third-party organizations—is where opinions diverge.
Since SOA is about the approach to the development of systems, it has many similarities with object orientation, component-based development and general software development practices, "all of which had supporting maturity models," said Sam Higgins, a senior analyst with Forrester Research Inc. who is based in Australia. "It would not be unreasonable for SOA maturity models to merely be additional perspectives on existing maturity models. Many of the vendors we have spoken to indicated that they based their thinking on these existing models."
David Sprott, CEO and principal analyst of U.K.-based CBDI Forum Ltd., said the aspect of SOA maturity most applicable for standardization is in the area of collaboration between organizations, for "helping disparate organizations to understand what capabilities they need to put in place to establish repeatable and well-managed processes between organizations." He stressed that a maturity model should focus on processes rather than infrastructure.
In Sprott's recent report on SOA Maturity, he examined vendor-led efforts from IBM, BEA Systems and the vendor group including AmberPoint, BearingPoint, Sonic Software and Systinet. None of these vendors are "helping their customers to understand how to adopt SOA," he said. "At the moment, vendors as a group only have infrastructure products to sell in the SOA area. Consequently, that's what they market."
Major enterprises, he said, are looking to not only adopt new architectural practices, but all other aspects of best practices, such as managing lifecycle processes and organizational issues. "There are all issues that relate to maturity in an enterprise," Sprott said. "Infrastructure is important, but that is merely one dimension."
Ron Schmelzer, a senior analyst at ZapThink LLC in Waltham, Mass., said an SOA maturity model should be about architecture and "help organizations determine not just how mature their services are, but how mature their policies and governance are, as well as organizational changes and the issues around that," he said.
Some SOA maturity models are based around the Software Engineering Institute's (SEI) Capability Maturity Model Integration (CMMI). "CMMI is generally accepted as a 'best practice' approach to measuring and monitoring process maturity in key areas," said Forrester's Higgins. "It is certainly better to link SOA to existing practices within an organization. Using CMMI as a basis can provide that. However, SOA is more than just an IT issue, so using CMMI as a basis is fine as long as the approach is not narrowed to an IT-only process view."
CBDi's maturity model is modeled on the CMMI, "in so far as we've identified and defined a series of capabilities as the backbone of a maturity model," Sprott said. Others [models] have looked at CMMI maturity levels, which is a mistake. These levels are inappropriate to SOA."
Jon Bachman, senior director of product marketing for Sonic Software Corp., Bedford, Mass., said their vendor group based their SOA maturity model around CMMI because "the majority of managers know it. In the CMMI world you talk about the capability of my organization to produce software on time/on budget. The SOA maturity model tries to add to that. We're not trying to say it directly ties to CMMI, but we wanted to use it as a touchstone for understanding."
He said the intent is to show the business value of SOA. The model, he said, is organized around the business benefits available at each level of maturity. "It says something about the skill sets you need to have, the standards to be aware of, the goals and practices you need to put in place."
The viewpoints of the vendors were taken into consideration, he said. "We've used it to describe where our products fit," he said. While the model indicates which products fit at which level, the intent is not to imply that organizations have to use a particular product or even particular type of product at each level, he said.
According to ZapThink's Schmelzer, "Sonic's model is a service maturity model. It doesn't say anything about how mature your architecture is. You can have highly mature services and an immature architecture. It's self-serving for the vendors."
IBM's model, Schmelzer said, "is not a SOA maturity model either. They call it a Service Integration Maturity Model. [It's a guide for] how integrated and loosely coupled different services are. It's more accurate in terms of the value it offers."
However Forrester's Higgins said, "To date, IBM's is the most mature and appears to have a broadest coverage with along the right assessment methodology. However, there has been some good work done by Microsoft to raise the bar and thinking."
This begs the question, who should be leading the effort? "Certainly vendors and consultants have the most exposure to what works and what doesn't. So they can add a fair degree of practical value to the models," Higgins said. "The issue is if a maturity model is developed solely for the purpose of selling services or technology. As a result, it is often better if these models ultimately become the intellectual property of an independent third party."
Both Sprott and Bachman said they'd be willing to turn their models over to a third-party organization. "There are a number of folks at OASIS who have been encouraging us to give it to them," Bachman said.
As to the bottom-line question—does the industry need an SOA maturity model—ZapThink's Schmelzer said it remains to be seen. "I'm not 100% sure we need one." However, he added, "People do need guidance on how to advance the state of their SOA."