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.
PingBack from http://msdnrss.thecoderblogs.com/2007/09/13/good-intentions-bad-soa/
PingBack from http://msdnrss.thecoderblogs.com/2007/09/13/good-intentions-bad-soa/
PingBack from http://msdnrss.thecoderblogs.com/2007/09/13/good-intentions-bad-soa/
"Miss on ANY of these points and your SOA will not deliver the value of reuse."
Doesn’t this amount to saying that SOA can never deliver the value of reuse?
No… it is possible.
On the other hand, I don’t talk about the value of reuse as much as the value of agility.
You can get a lot of agility with a minimum of reuse.
Nick
I enjoy the postings from you and JoeMcK.
Often when I read marketing literature or documents on IT tools I get the impression that these documents are written for global multinational organisations with huge IT budgets and hordes of technical people. The array of tools a good SOA shop needs and the array of technologies an IT organisation is expected to master is mind-boggling. Now you are adding another five teams to the SOA staffing.
Is there any hope for the "small" IT groups? Can we deliver a light version of SOA or should we just give up?
Hi Antony,
In a smaller company, this is a LOT easier to do. I talk about teams because in large places, you cannot effect change with only one person or a small team, but in a small place, you really can do it.
What you need for a smaller IT shop:
Executive sponsorship for the cost, complexity, readiness, and infrastructure issues that ANY major IT change entails.
A single leader who understands SOA and can share the goodness with every developer. Call him or her the chief architect or enterprise architect. This person decides what technology to use and shares the vision of SOA as enabler.
An information architect to create and own your common data model.
A business architect to create and own your business events ontology and business objects / entities.
A governance process where the chief architect, the IA and the BA all review the project plans of each project to make sure they are in line with SOA.
A process for improving the common models through the input and collective knowledge of the project teams.
That’s it. You DO need Enterprise Architecture to make SOA work. But you NEED SOA to make IT efficient, effective, and agile. It is not cheap, but neither is your network, an you pay for that because it is necessary infrastructure. So is Enterprise Architecture.
This cannot be done with getting CEO on board. Not in a small-to-medium company. Hiding from the CEO is planning for failure. Do this with his or her blessing and support.
In really small companies, the CTO is the Enterprise Architect.
Thank God for coffee…. Astoria/Orcas/Data Services The Astoria September 2007 CTP is now available