Geeks With Blogs
BizTalk Blog by Chris Han System Design for Enterprise Agility,
Despite the dramatic eye-catching writing style, she does get a little bite on the issue. "Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. Does this sound familiar to you? If not, let' see this part "The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility"
I hope Michael Hammer can tell her how the Business Process Re-Engineering didn't work out in the early 90'. Just to make a comparison: The Business Process Reengineering method (BPR) is described by Hammer and Champy as 'the fundamental reconsideration and the radical redesign of organizational processes, in order to achieve drastic improvement of current performance in cost, services and speed'.
The reason why I say Anne got a bite on the issue is because I did realized that SOA is not about technology. The point is well addressed by Eli. Goldratt in his interesting book "Necessary But Not Sufficient" - SOA as a way to enterprise illities is necessary but not sufficient. One of the reasons of many failed SOA initiatives is because the CTO/CIO is too exciting and busy to buy and build a SOAish system, and 'forget' to really think about the real value that the business ask for. I don't mean that they did create a business case. But how much the word like 'agility' mean to the business? Can you have an account of it on the book?
The interesting part is that at the end, Anne herself falled into a rush and easy conclusion that we need a radical change. Yes, as an engineer by education, I hope we have that easy button only technology will change everything from scratch. But people do live and work around us. The quick and dirty analysis and solution is the last thing we need here now.
So, enough big pictures. As an engineer by education, I'd like to provide my view on the technical problems in SOA implementation. My point is not fresh. It firstly traces back to the book I read in the college -  No Silver Bullet by Fred Brooks. My experience just confirmed his brilliant idea again.  His idea is that basically there are some problems (or complexity) we created our own and we can fix or automate; and there are certain problems we just have to deal with it, in a hard way. Brooks is talking about the software complexity. But it applies to any there in engineering in my opinion. The other part of my point comes from Eli. Goldratt’s Theory of Constraint – technologies elevate constrains, but it won’t eliminate them. With these two pieces of great ideas, I come up with this idea that on the way to achieve enterprise illities, SOA helped us to ‘open up’ our architecture and elevate us to a new design space, but there we are facing hard-problems or as Brooks described as ‘essential complexity’. Anne has line I quote here ‘Service-orientation is a prerequisite for rapid integration of data and business processes’. I give you an example I had on my journey: One of my projects is to integrate an accounting system and a reporting legacy. The network is no big deal, access control is all set, service on accounting system is up and running, ESB returned XML data to reporting system, the UAT passed, and a SOAish application seems a classic case study, until 3 reporting cycles later. Suddenly the aggregated numbers are getting off between two systems. What’s wrong?
When we talk about integration, by my education and experience, there are three level of integration: connectivity, interoperability, and semantic confirmation. Generally speaking, internet/intranet, solve connectivity problem, XML, web service, ESB enable the great interoperability, but semantic confirmation of the information is the new problem in my case. Yes, we did data analysis, by ‘subject matter experts’. The business entities look and act like same in most of the cases across the accounting and reporting domains. But do you cover all the cased in your analysis? Even you did, do you have a procedure to govern the changes and manage dependants? SOAish applications provide a great flexibility and loosely coupled system of system, but the same ‘good quality’ open up a whole new can of worms for the architecture maintenance and governance.
That’s what I mean by SOA is not dead, the thing you need to kill again and again is the mentality of finding a silver bullet. SOA is rather a road map, a discipline.  Engineering is about solving problems step by step in a deciplined way. Unfortunately, there is a bunch of hype-driven marketing professionals competing with us engineers. Speak up, people!
Posted on Tuesday, February 10, 2009 6:17 PM Architecture! , BPM and Enterprise Architecture | Back to top

Comments on this post: SOA is not dead; the dream of silver bullet is, again!

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Chris Han | Powered by: