There has been a fair amount of chatter lately about defending the value of SOA projects or justifying such projects to the “C-level”. Many of these discussions will point at the business value of doing more with less and achieving IT cost reduction by reducing redundant systems and reuse of services in a SOA. Also streamlining processes in order to run the business more efficiently is a popular opinion,
which I agree with. David Linthicum in his blog summarizes a few of the points - http://weblog.infoworld.com/realworldsoa/archives/2008/01/more_on_defendi.html
Delivering business value from SOA is not a new concept. I have written a fair amount about the topic over the years: http://news.zdnet.com/2100-3513_22-6108621.html and http://www.oreillynet.com/xml/blog/2005/02/extracting_business_value_from.html.
Today, similar to a few years ago, extracting business value from SOA and using SOA initiatives as a means for aligning IT with the business is critical. Many of the same points are also relevant to “defending SOA” today.
To sum it up, I have always believed that the real business value of SOA is not so much about IT cost reduction but really about being able to react quickly to change.
Overall, the main business value of building a SOA is the ability to react quickly to changing business conditions including changing economic conditions. During such times executives need to be at the helm more than ever. Competitors will take drastic measures and you must be able to quickly alert, measure, and react, and measure again in order to quickly assess the effectiveness of your course corrections. Having flexible business processes, which can be changed without requiring a considerable engineering effort, tied into realtime analysis and metrics made available through things like BAM dashboards can help tremendously in that type of dynamic environment.
I have always been a strong proponent of approaching SOA by identifying projects that can achieve demonstrable ROI within a matter of months, and that this needs to be accompanied by the longer term vision of where you need to get to in order to be successful. This still holds true regardless of economic conditions or IT budgets.
One could even argue that if you weren’t already building SOA projects with these things in mind, then perhaps they were misguided to begin with.
Dave
The premise of SOA's approach is not going to succeed for the most part, because it's a solution targeting a symptom of an underlying root cause.
The root cause is nicely illustrated by the oft mentioned phrase "aligning IT with business", which points us in the direction of the problem: IT is NOT aligned with Biz.
Oooops!
Let's look back at history:
IT tries to prevent deployment departmental mini-computers.
IT tries to prevent deployment of PCs.
IT tries to prevent use of subscription SAAS over the net.
IT tries to prevent use of unauthorized mobile devices (PDAs, cell
phones, crackberries, and now iPhones).
IT tries to prevent unauthorized use of scripting and dynamic
languages (eg. ruby, python, xquery etc).
Remember, J2EE/EJB was supposed to solve all the worlds problems not that long ago, and so why need need for SOA, WS-* and all the other vendor-sponsored solutions? Didn't IT solve it last time round?
Most often these days, in large organizations (corporate, government, non-profit, etc.), IT's self-proclaimed role is as a "naysayer" and IT is an inherent part of the problem and not the solution.
Misguided indeed. On that point we agree. ;-)
Thanks to Andrzej for highlighting that the business is not aligned with IT!
We all now this type of employee. Frustrated IT person who thinks they know better.
It's exactly this sort of attitude that results in multiple disparate applications within an enterprise. This results in low business agility.
Let me look back at history:
Did the deployment of departmental mini-computers ever solve the problem?Did the deployment of PCs ever solve the problem?Did subscription SAAS over the net solve the problem?Did mobile devices solve the problem?Did the use of scripting and dynamic languages solve the problem?
Short-term gain, long-term pain.
And guess who has selective amnesia when it all goes wrong and still blames IT?!?!
Go back to your Access database and leave the enterprise level problems to the big boys.