I'm back from the IBM event, which was an immersion in all things SOA, the IBM way. As I bounced from presentation to presentation, I felt that SOA was a very different concept depending on who was presenting. Nothing new there, but there has to be a much better way to think about SOA, and as all things in the United States, we want it to occur in three easy steps.
The truth of the matter is that I've defined SOA as at least a ten-step process, first looking at the data, the services, and the processes, or at the "as is." Next is defining the logical "to be" around the decomposition of data and services, and the restructuring of that data and those services, around a logical grouping, and then a process or configuration layer to create and re-create solutions.
[ Keep up on developments in SOA with InfoWorld's Technology: Architecture newsletter. ]
Wake up! I know it's architecture, and thus there is a special breed of person known as an "IT architect." They -- OK, me -- are able to find that stuff fascinating, but nobody else does. Indeed, I almost hate to have somebody ask me what I do. I figure I lose them at "I make IT more effective by ..."
So what are the three easy steps that will make SOA so much more exciting? Let's go with:
- Blow up
It sounds a bit like an action movie, but keep up with me here.
Infiltrate: We're driving into the problem domain looking at all of the existing architectural issues, as well as getting buy-in from the stakeholders.
Blow up: We're looking to break the architecture down to functional primitive, services, data, and processes, and build it up again into something better.
Control: We're looking to create an abstraction layer where we're able to control processes and business rules, typically through a configuration layer that provides the architecture with the core benefit of agility or control.
So next time somebody asks you how to do SOA, you tell them you infiltrate, blow up, and control. It seems descriptive enough and sounds a whole hell of a lot cooler. However, it could be a bit problematic when presented on the consulting agreement.