Brave New World with WS-*

What I think is that the current focus on RPC-style SOA design (which in fact is very old) will shift to a focus on Event Driven design style. ESB-s and WS-* make that possible at the business process level; standards based, a-synchronous open messaging systems, which was not possible up till now. At least not at the business process level and open standards based.

I see ESB as the company's global data space, where business events reside. So, an infrastructure. The ESB is the infrastructure to support standards based publish/subscribe patterns.

Where SOA focuses on services as functional components, I'd rather focus on business events (messages) that trigger processes. That's my view of EDA. The processes handle the life-cycle of the business events en may generate new business events that trigger other processes. Such a process can be a composite application which can be an EDA by itself (preferably) and which can use - at the lower levels of granularity - request/reply (RPC) patterns to services for message enrichment or data processing.

One of the big differences with the old world is that we don't have the program tell the messaging-infrastructure how to handle the message (JMS), but we use the message itself to tell the infrastructure how it has to be handled (WS-*). And all messaging-infrastructures will understand WS-*, even the network hardware devices like routers and switches. This way the message can - and will - break out of the closed systems and travel freely across heterogeneous infrastructures. Within or outside your company. With your ESB as the company's business events container, representing the real-time state of your business; including all the historical states in a fluent time-line to the past. Imagine its huge potential... (e.g. compared to our current, static, historical datawarehouses)

This will be the brave new world and it will change the way we look at IT-systems forever.

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?

Batch Job Flow Design is equal to EDA

I have my roots in the old IBM370 JCL. What I like about EDA is that designing an EDA is very similar to designing batch job flows. Where you write a record to a file, you publish an event. Reading from a batch file is consuming from a topic. Where you read multiple files in balance, you come to complex event processing. Batch programs are decoupled. Programs write records and others read records, without any knowledge of each other's existence.

Simply said: Just take out the read/write-to-end-of-file loop from a batch program and the program is modernized to play its real-time role in an EDA.

Another way is to slice up batch files to messages and to queue up messages to batch-files; both at the perimeter of the ESB.

This is the way I explain the EDA-mindset to our analysts and programmers. And it works... (as far is they are old enough to know anything about batch programming ;-)).