Help?! The boss decided that we will use SOA. Not a programmer, not an architect, he must have heard the buzz that SOA will solve our interface problems and simplify our product development.
Now that the office is buzzing with SOA activities, how far do we go and what will we gain?
Currently our suite of enterprise software consists of dozens of stovepiped applications. In some instances, we have created a web of interfaces to share one piece of data with another system here and there. The resulting complex system is unweildy. Anytime a system goes offline or changes a datatype, we have no idea of how the other systems will be affected.
So we are scurrying to build DoDAF views (OVs, SVs, and TVs) and arguing every aspect of development, saying, "is it SOA, what is SOA?"
The hardest part in this paradigm shift is to herd the cats into all sharing the same vision of 'how much SOA is enough.'
While SOA principles can lead to more consistent and documented designs, we need to understand that it is not reasonable to redesign all of our systems to fit a SOA-compliant framework. Supporting this position is the statement that no complex system has ever been successfully SOA-implemented.
I would like the team to perceive SOA principles as a guide to encourage loose coupling of interfaces and commonly defined data values that can be more easily shared throughout the systems.
In mentioning my dilemma to the new guy, William, he pointed me to a SOA maturity model that describes the spectrum in a hierarchy:
No comments:
Post a Comment