SOA Lessons Learned
KerrieH 110000JQ5R Comment (1) Visits (5795)
Understanding lessons learned from SOA initiatives and projects provides insights on how to get started, creating business value and avoiding pitfalls. For example, some obvious lessons I discussed with a federal government client today included: (1) leading from an IT perspective; (2)treating SOA as same old architecture; (3) big bang approach; (4) equating SOA and Web Services; (5) ignoring or treating SOA governance as an after thought; (6) failure to integrate SOA and Enterprise Architecture thinking and (7) treating SOA as the what and not the how.
Clearly IT leaders should lead, whether its SOA initiatives or not. However, there ought to be business value proposition associated with SOA adoption, whether its flexibility, integration, cost reduction, integration, reducing process cycle time, or others. Of course the key is to take platitudes like flexibility and actually define what is meant. This is a longer discussion but the point is be clear and specific about your business intent and don't let SOA become just another science project.
Treating SOA as what we have done in the past or saying we did this 15 years ago missed the point. Its burying our heads in the sand. Its important to separate the hype but its also important to understand what is actually different from DCE, CORBA and other past approaches.
Obviously risk is lowered by taking incremental steps versus big bang. Organizations must adopt in line with their current maturity.
Many companies have seen the folly of thinking they will get SOA benefits by just using Web services standards and associated technologies. In fact for many companies they are seeing performance issues with their architectural decision to use Web services choices and in others little to no reuse. The point is the choice of Web services is an architecture decision.
Increasingly organizations are seeing that SOA governance must be planned and implemented in order to both achieve project benefits from SOA but especially to see sustained SOA benefits.
SOA can be used to jump start failing or ineffective Enterprise Architecture programs as SOA can be one way to increase the convergence between business and IT. However, SOA and EA are complimentary and SOA should be included in EA not the other way.
Lastly, the goal should not be to implement SOA but rather companies, organizations ought to have a vision where SOA is the how, as where there is no vision, people perish and in this case where there is no vision of how SOA will bring actual value, initiatives stall and fail and SOA gets blamed.