Good intentions - bad SOA
Joe McKendrick brings up a very important point about "building SOA" in an organization where the developers have no idea of what SOA is for, and why it should be used. In his post, "How to ruin a SOA program and bankrupt IT", he discusses the value proposition of 'SOA reuse' and one of the reasons why that value proposition is often lost in the details...
Because you need more than executive buy-in. You need to know what you are doing.
I'll detail the things you need before SOA reuse starts to become feasable:
- Executive sponsorship for the cost, complexity, readiness, and infrastructure issues that ANY major IT change entails.
- A team responsible for making sure SOA is understood, evangelized, promoted, and measured.
- A team responsible for creating a common information model.
- A team responsible for creating a common business event and business object model.
- A process for insuring that projects are using the common information, event, and object models in their designs.
- A process for improving the common models through the input and collective knowledge of the project teams.
- Management engagement and communication so that collaboration among teams actually occurs.
- A team responsible for creating a clear vision for how different people will integrate, what technologies they will use, and who will own the development and maintenance of the infrastructure.
Miss on ANY of these points and your SOA will not deliver the value of reuse.
Important: There are other ways to value SOA. Reuse looks good, but it is not the one I promote.
If you want to deliver reuse through SOA, be prepared with all of these elements. If you cannot swing these elements, do NOT include reuse in your SOA business case.
Don't promise what you cannot deliver.