Thursday, June 15, 2006

SOA doesn't add business value, but EDA does

Despite of the marketing hypes that try to make us believe that SOA adds great opportunities to the business, I state: well, it doesn't. Yes, with a good SOA implementation you may be more agile in building and changing information systems. And because of that you may be able to follow changes in the business processes more quickly in the supporting IT-systems. So your time-to-market might be better. Better? Compared to what? Better than with a set of old Clipper programs? Clever programmers with clever tools and clever designs may gain the same results in agility. And they do.

So is SOA a bad idea? No, not at all. It is a very good design practice, based on layering and functional decomposition. (Huh? Do I hear Stevens and Myers and Constantine and Yourdon somewhere back in the '70s?). Did your business client applaud when you told him that you will build a composite, layered application with reusable (sorry: sharable) API based modules to achieve flexibility in changing the program afterwards? Probably your lead IT-architect did, because... the IT-department gains most of the benefits. You can reach the same results otherwise, as I mentioned: with clever people and clever tools and clever designs.

But wait, heard of SOA 2.0? Disgusting the way how acronyms are stolen that AOSIS tries to define and standardize properly. Boo! But what is behind SOA 2.0 isn't disgusting at all. It's the long beloved (at least by myself) move to EDA. Hurrah! Here we are...

Imagine a big data warehouse, where all relevant business data is stored. So what? Wait, it is not just simple business data and it also is not just simply stored. No, it is there spontaneously. You don't explicitly model and store the data, it just is there. And the data is the actual real-time representation of all your business activities at this very moment; including all the history of it. It is just all there as a spin-off of a particular design pattern: detecting relevant changes of state - events - in your business and publish these changes of state in a global data space. What would you do with all this data? Triggering business processes, signal potential deflections of KPI's and SLA's and perform corrective actions, predict bottlenecks. Simulate "what-if" situations to improve business processes. And correlating detected events to generate new events to trigger new processes; on-the-fly in real-time! A hard job for even the smartest old-style programmers. And that's not all... processes are decoupled. They are stateless relatively to each other. So you can easily outsource them or scale them up by adding additional instances, or add new ones. Not a bad deal for our business people, is it?

This is EDA! Model your business events right and have their software representations travel in real-time through a global (enterprise wide) data space (call it an ESB), then you are offering your business huge opportunities. Think of connecting your global data space with those controlled by other enterprises: your fantasy is the limit.

Uh, is the data there really spontaneously? Well, not really. You need programs that publish the events. These programs are the programs that currently or in future support the business processes. And they update databases. Why do they update databases? Yep, changes of state. Or they write a record to a batch file. Again maybe a relevant change of state. That is where you may find events. But of course you can ask your business consultant for the business events. She will love you. If you have your applications talk to each other via the global data space (ESB) instead of using shared files, shared databases or direct calls, and you use a publish/subscribe pattern for that communication, then you might say the data is there spontaneously (don't shoot me if you disagree).

And what do we do with SOA? Leave it where it belongs: in the IT-department as a style to build applications. And don't bother the business with all of this hype.

SOA misused web services to get focus (you naughty: your concepts are at least 40 years old). And now EDA is going to misuse RPC-style SOA to get focus (SOA 2.0). Don't we live in a wonderful world?

4 comments:

Anonymous said...

SOA is the biggest hype in the IT industry today... after realizing that a box of ever changing technologies have confused and complicated the application development (in spite of the wide acceptance of Java based systems), some marketing person has invented the SOA concept to hide the realities and give the wrong perception that everything is under control.

It is not surprising to see that each vendors SOA definition and implementation are contradicting each other, leaving the reader to wonder what SOA is in the first place!

Mark Palmer, StreamBase CEO said...

Agree that SOA is a lot of hype, and, being involved in some technology that is becoming more hyped, I think we can learn a lot of lessons from SOA about how NOT to promote a "new architectural thing." The focus is simple, we have to work to identify, and work to promote, specific use cases around event driven architecture (EDA) and emerging technologies such as complex event processing. And we're doing that. Read here about the business value of EDA in my blog, and feel free to read about all the real customer use cases in this blog about the role EDA and CEP plays in adding business value:

The Event Processing Blog, and does EDA provide "more" business value than SOA?

Anonymous said...

Interesting points. I personally think SOA is a load of guff

MySpace Design said...

Interesting stuff. Stumbled upon your blog and enjoyed reading some of your posts.