August 15th, 2005
Blueprints will cover both 'macho' and non-macho SOA
Much like SOA itself, the just-announced "SOA Blueprints" effort will be defined as it goes along. I recently spoke with Infravio’s Miko Matsumura, proposed chair of OASIS’ SOA Adoption Blueprints Technical Committee. (Interview posted here at the Webservices.Org site) Matsumura says the technical committee intends to stay above the fray of what constitutes a "proper" SOA, and work to define the architectures that people have up and running.
SOA Blueprints essentially will have three parts, he says: a business problem statement, a detailed functional requirement document, and implementations. Will SOA Blueprints help define exactly what SOAs should look like? No, Matsumura says — "we’re hoping to provide some guidance, but we’re taking a "barks-like-a-dog" approach. Which is, if it barks like a dog, it’s a dog. So our definitions of SOA are really going to hinge upon people’s requirements. We’re steering clear of any SOA fundamentalism. We’re even probably going to end up with some implementations that are decidedly not real ‘macho’ SOA."
What SOA Blueprints will do is provide a consistent and accepted format that end-users can use to compare their own and vendors’ approaches to SOA. The blueprints are intended to fuel the "law of mass action," and the "law of mass pressure," Matsumura explains. "One benefit is collective wisdom. Within a larger group of mutually interested parties, there are likely to be people who have considered elements of the problem you haven’t considered."
The second benefit, the law of mass pressure on vendors, also provides safety in numbers. "What vendor would not want a captive audience of product interested and implementation-focused people, all collected to serve as an audience for its products?"
Matsumura makes the point that by comparing blueprints in vendor engagements, end users will be able to see how clean, simple, an elegant an SOA approach is underneath the covers. "The question, ‘can your platform do x?’ is a lousy question, because the answer ought to almost always be ‘yes.’ The real questions should be, ‘how does it do that, and is it ridiculously complicated, and ludicrously unmaintainable? Or is it really neat and elegant, and seemingly designed to do what I want?’ To some extent, a blueprint and implementation path allows you to see what things look like when they are designed to be there."
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Subscribe to Service Oriented via Email alerts or RSS.
