The recent drafting of an SOA manifesto raises new questions about the current state of service-oriented architecture and the need for an SOA manifesto. Why do we need an SOA manifesto at this point in time? How will this manifesto help companies build better software? What work is left to be done for SOA? To answer these questions, DZone spoke with two people who have studied the evolution of SOA for several years. Miko Matsumura is deputy CTO of Software AG and the author of “SOA Adoption for Dummies." Kirk Knoernschild is an industry analyst at Burton Group after working on software projects for 15 years.
Kirk Knoernschild believes some have lost sight of what constitutes SOA. The need for a manifesto with defining principles is apparent he says, when for so long companies have tried to "buy their SOA." "SOA isn't something you buy, it's something you do. And you do it by applying SOA principles," said Knoernschild.
Miko Matsumura says the need for an SOA manifesto was not prompted by a failure of SOA to fulfill its promises. "SOA is an architectural style--architectural styles don't make promises. People make and break promises," asserts Matsumura. He says that in spite of the criticisms, a Forrester report by Randy Heffner shows that less than 1% of SOA efforts have been abandoned. "I was saying to Joe McKendrick (one of the Manifesto signatories) this morning that that's probably lower than the abandonment rate for the iPhone," said Matsumura.
Knoernschild hopes that the manifesto will bring clarity and consistency to what people mean when they say 'SOA'. DZone asked Knoernschild and Matsumura if there were concerns that the 'high level' wording in the SOA Manifesto might lack clarity and direction. Knoernschild responded, "The manifesto should be high level. It's a manifesto, after all. If they're looking for more direction, they should be digging into SOA principles such as loose coupling, autonomy, statelessness, etc." Matsumura said, "SOA initially launched with a set of design principles. The SOA Manifesto depicts principles for implementation, therefore I would prefer it to be called the 'SOA Adoption Manifesto'. The principles are not at the same level as SOA principles such as "coarse granularity" or "loose coupling"
Matsumura further explains, "The concern that the manifesto is too "high level" reflects the pragmatic day-to-day blocking and tackling around SOA in the Enterprise. This is driving a tremendous thirst for specific "what do I do" instructions. The Manifesto provides a set of guidelines but in a way it is almost a roadmap of what NOT to do." Matsumura adds that its hard to make generalizations about architecture without going onsite for a SOA strategic advisory session. He says the needs of an SOA depend on the intentions of the stakeholder groups.
When DZone asked Knoernschild and Matsumura if the SOA Manifesto would become a mouthpiece for SOA product vendors, they were both in consensus. "I don't think there's much concern that vendors can hijack the manifesto," said Matsumura. "I don't think the manifesto is at all a mouthpiece for SOA vendors. The agile manifesto wasn't, and I don't think the SOA manifesto will be either," said Knoernschild.
Knoernschild says the SOA Manifesto is no silver bullet, but it does allow organizations to focus on building software using SOA, instead of trying to figure out SOA's definition. Matsumura emphasizes that the work of SOA leaders is not over. "Leaders and visionaries in the SOA space continue to believe that SOA is a rational response to the problems of scale in Enterprise IT. So I think it's likely that all of us will continue to advise, encourage and promote the good use of SOA, and of course discourage the bad," said Matsumura.