• English
  • Nederlands
HOME
SEARCH
CONTACT
NEWSLETTER
 
 
 
CONTENT
About us
About NAF
Contributions
Call for contribution
The CIO speaks
The Architect answers
The Business decides
Proceedings
Blogs
Master thesis
Events calendar
Links
Login/Register
THEMES
Effect of architecture
SOA
BPM
Methods
Principles
Financial services
Public sector
Health sector
advertisements
Zoek je een baan?
Zoek je hulp?
Zoek je een opleiding?
Zoek je een tool?


Logica
logo_5fsap.jpg 

 
 
Business relevance of Event-driven Architecture
Jack van Hoof   
Wednesday, 02 July 2008
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 quite as we would like to believe. 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?

Jack van Hoof




Be the first to write a comment
RSS comments

Only registered users can write comments.
Please login or register.

 

Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not permitted. Readers are requested to notify This e-mail address is being protected from spam bots, you need JavaScript enabled to view it of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
feed image