We are all talking about SOA and EDA, trying to explain what services are and – a bit less intensive – what events are. But what is the A in SOA and EDA? What is architecture at all?
There are formal definitions (IEEE 1471 for software architecture) and less formal definitions of architecture. Many books and articles are written about the subject architecture.
In my lingo architecture means "purposeful composition". This implies:
The enterprise may be your scope of the architecture with regard to SOA and EDA. But be careful with enterprise level IT architecture. The enterprise IT is fading into a bigger global IT in the context of Internet, SaaS, Service Orientation, outsourcing, off-shoring, and so on. All kids in the street are participating with their own LEGO blocks to build your castle.
One of the purposes of IT architecture at the enterprise level is the ability to follow changes in the context. Not only in the business context, but also in the technology context. So the components must be defined and connected in a way that makes it possible to deconnect them and reconnect them in other arrangements and other contexts. This puts constraints on the components and here is where autonomy based on strong cohesion and loose coupling comes in place.
SOA is an architectural style the recognizes services (functionality representing process steps) as components. EDA is an architectural style that recognizes events (messages representing process states) as components. Both styles focus magically on the same architecture from an inverse viewpoint. The components in EDA are strongly related to the component connections in SOA; events connect services by transferring process state from one service that detects and publishes events to other services that are triggered by specific events. On the other hand the components of SOA are strongly related to the component connections in EDA; services connect events by transferring the process from one state to another; a service triggered by an event may cause a new event bringing the process in a subsequent state. The two main purposes of both SOA and EDA are (among others):
- Support ease in rearranging the components (commonly known as the LEGO metaphor)
- Support concurrent use of components in different contexts (commonly known as "reuse")
SOA prescribes constraints on the services to fulfill these purposes (autonomy, strong cohesion, statelessness). EDA prescribes constraints on the messages to fulfill these purposes (loose coupling, canonical messages with self contained context). SOA can hold synchronous patterns as well as asynchronous patterns. As EDA prescribes an asynchronous pattern, EDA not only puts constraints on the messages, but on the interacting services as well (publish/subscribe, deliver and consume full contained messages). Note that in consequence EDA puts constraints on SOA, but SOA not on EDA. From this perspective EDA might be seen as of a higher architectural magnitude then SOA.
This does not improve business processes themselves, but it improves support for adaptability of business processes; so it also supports changing lousy processes from bad to worse. Ultimately business processes may be changed without any IT changes.
It is like painting a GUI-screen where the buttons, entry-fields and display-fields may be reshuffled over and over again to the most ugly and poor screen design, without breaking the under laying functional support. Just as easy as that.
Why is screen-printing so easy?
- Because functionality of the screen objects is based on stateless autonomous functions (reusable in different context)
- Because interaction between the screen objects is based on self contained messages representing the state of the screen (button_pressed, mouse_clicked, field_entered)
- Because the screen objects are configurable by the user to the user’s needs and wishes (color, position, size, values)
I think I am a daredevil...!