Then you’d start to describe the process: The potter scoops up some wet clay from the bottom of a river; she slaps it around, spins it and shapes it, before sticking it in an oven. ‘Hold on’, says the Martian, ‘Do you really expect me to believe that a potter, however skilled, can make a waterproof pot out of wet clay?’
And when you put it like that, of course, it is hard to believe. If we hadn’t seen it done with our own eyes, we’d start to doubt it possible.
In the days of component-based software engineering, we were often presented with an equally implausible story. A software engineer scoops up some wet COBOL from a legacy system, slaps it around a bit, wraps a few shells around it, and voila! - a fully interoperable, WS*-compliant business object.
Champions of SOA are faced with a similar challenge. A complete story of SOA has to contain at least four things.
- A story about structure. Not just the structure of a single service, but the whole architecture. This is like explaining the shape of the pot.
- A story about process. How do these services get produced and consumed? How does the model-driven, contract-first approach actually work? What are the roles and responsibilities in an organized SOA approach?
- A story about raw materials. What are services made out of? Lumps of software? Lumps of executable model? BPEL or OSLO?
- A story about value. Who can extract value from these services, and how?
I'm not saying you have to explain the intricacies of software engineering or service engineering to your Martian (or businessman). But you do have to have some broadly plausible story. Because without a decent structure, a decent process, and decent materials, the value ain't gonna happen.