SOA is not dead; the dream of silver bullet is, again!

Chris Han — Wed, 11 Feb 2009 00:17:58 GMT

Anne Thomas Manes has an interesting post stated that SOA is dead.

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!

Our first case study on Microsoft patterns & practices!

Chris Han — Fri, 02 Jun 2006 13:49:00 GMT

http://geekswithblogs.net/chrishan/articles/80454.aspx

Although the story only mentions the external apparel we did with ASP.NET 1.1/2.0, the biggest challenge in terms of architecture design we are constantly facing is to balance between the desire of SOA's flexibility/maintainability/reusability and the performance demand by such as a high volume system.

Our client is in fact a typical Application Service Provider in financial circle.(one of those actually survived ASPs.) Their business model has born with a demand of integration. Both integrate with different partners and with a whole spectrum of technologies from legacies to cutting ages, you name it we got it. That’s where the BizTalk gets in the play.

Due to the size of the messages and the processing time restriction, we are trying to use parallel processing as much as possible. The top utilized integration patterns in this project are:

· Scatter-Gather

· Splitter

· Aggregator / Convey

The management patterns implemented are primarily:

· Wire Tap

· Control Bus

I find to implement Wire Tap in pipeline component is very interesting. The challenge here is that we need some information on the incoming message even before it hits the message box, meanwhile you are suppose to process the message here in a streaming manner. A pipeline component is a perfect fit because you don’t have to stop the processing of business messages. All you need to do is to get a copy of the incoming message by pInMsg.BodyPart.Data. From there, it’s all old world you used to.

SOA ain't born of air.

chrishan — Sun, 02 Oct 2005 18:03:00 GMT

I'm reading Pat Helland's article: Data on the Outside vs. Data on the Inside. It's much like a history of software architecture that many of us have gone through. I'm always amazed by the history because you can really predict the future by looking at the patterns it repeats itself again and again. The problems arise just in different faces perhaps in a different abstraction level or a different view or a different context. But fundamentally, they are same.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/his_2004Main/htm/his_planning_for_transaction_integrator_node_adxt.asp

Architecture!

SOA is not dead; the dream of silver bullet is, again!

Our first case study on Microsoft patterns & practices!

SOA ain't born of air.