The magical A of SOA and EDA

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:

• Components
• Separation
• Arrangement
• Connections
• Purpose
  

It doesn't say anything of domains. It can be about a piece of music, electronic circuits, buildings, IT, organizations, landscapes. Everywhere you recognize structures of distinct components that are determined, distinguished and arranged based on predefined (concurrent) purposes I mention it architecture. So the structure of a tree has no architecture (not based on predefined purpose), but the structure of a garden has. The architecture of a building recognizes spaces as components and combines purposes with regard to function, aesthetics, safety, maintainability, adaptability and cost. Purposes put constraints on the architecture and may be conflicting. It is the architects job to balance between conflicting purposes. The less conflicting purposes there are, the more freedom the architect - as the conceptual arranger of components - has. In arts purposes are often limited to not much more than aesthetics and triggering emotion,(triggering emotion sometimes is the only purpose), which gives the artist, being the architect of the work of art, very much freedom. Like purposes put constraints on architecture, architectures put constraints on development. See also this nice posting.

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")

Note that these purposes are commonly accepted with regard to services, but at this moment in time hardly mentioned in the context of messages (representing events). As it is desirable that events can trigger multiple unrelated services in concurrency which can be changed by configuration on the fly, these purposes are also applicable to messages.

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)

If you are a daredevil you possibly have the courage to say that SOA and EDA make the enterprise level application landscape, painted on the companies screen canvas much like modern GUI-development tools.

I think I am a daredevil...!