In his blog, Grady Booch (of UML and Rational Fame) talks about 'how Bottom Up approach for SOA can be a disaster'.
"Going back to the A part of SOA, the issue then is one of abstraction, separation of concerns, and all the usual fundamentals of architecture. I've seen some folks suggest creating an SOA from the bottom up: look at a silo, identify the potential services, and publish them, then weave a system together from them. This is in essence technology first. In my experience, this is a recipe for disaster and/or serious over-engineering. You've got to start with the scenarios/business needs, play those out against the existing/new systems, zero in on the points of tangency, and there plan a flag for harvesting a meaningful service. These styles, and their resulting costs/benefits, are rarely discussed. "
Following things should be kept in mind while deciding on the approach for SOA
1. It is business first and technology afterwards.
2. Do not think SOA as the panacea of all Business and IT alignment issues.
3. Keep it simple... Do not over-engineer.
4. Understand your business, existing IT assets/systems before going for something like SOA
No comments:
Post a Comment