SOA, Cloud Computing, and Event and Model Driven Architecture

In a recent post (see Functions Required in the Cloud PaaS Layer to Support SOA), I discussed two SOA patterns and two Cloud Computing patterns and showed how they are, in fact the same patterns applied to the SOA and the Cloud Computing domains.  For SOA, the concepts are Enterprise SOA (ESOA) and Ecosystem or Internet SOA (ISOA), while for Cloud Computing, the concepts are Private and Public Clouds. The correlation of these concepts is shown in Table 1.

	Ownership Domain		Integration Type		App. Layer Comm.
SOA	1 Dom	2+ Dom	Orchest.	Choreo.	ESB	Internet
ESOA	X		X		X
ISOA		X		X		X
Cloud
Private	X		X		X
Public		X		X		X
MAEDA
Model	X		X		X
Event		X		X		X

There are three attributes for both SOA and Cloud Computing shown in Table 1; Where the Services operate (the Ownership Domain variable), whether the service uses orchestration or choreography (Integration Type [see SOA Orchestration and Choreography Comparison]) and where the service components interact (The Application Layer Communications).  As the table demonstrates, on the dimensions shown, an ESOA is a model of the Software as a Service (SaaS) layer of the Private Cloud, while the ISOA is a model of the SaaS of the Public Cloud.  Consequently, SOA and Cloud Computing can be the same at the SaaS layer.  Since the SaaS drives most of the requirements for the Platform as a Service (PaaS [see Functions Required in the Cloud PaaS Layer to Support SOA]) and the Infrastructure as a Service (IaaS) layers, the results should be a nearly identical Technical Enterprise Architecture (or functional design) [Sidebar: but, perhaps with different labels to satisfy the purists, perhaps, “True Believers”, in each camp].

Model and Event Driven Architecture

In a Part 3 of a four part paper, The Future of Information Technology: Enterprise Architecture 2006 to 2026, Part 3: Model and Event Driven Architecture (2008 to 2017), The Journal of Enterprise Architecture (February 2007), p. 28-39, I posit Model and Event Driven Architecture as an outgrowth of SOA.  This is an integration of Model Driven Architecture as espoused by the Object Management Group and a widely discussed, but somewhat nebulous Event Driven Architecture.
Model Driven Architecture and SOA
The current concept of Model Driven Architecture (MDA) starts from IT functional requirements, as modeled in UML diagrams and ends up with a complete application to roll into production.  With respect to SOA, using MDA would mean that the software developers create the Service Components using MDA and assemble these components into a Composite Application using orchestration based on MDA.  In fact, modeling the assembly of the composite application is a quick way to spot both coding and system functional design defects.

However, in a broader interpretation of MDA, implementers of new systems, application, and/or services could start with Business Process Modeling to identify business process requirements and functions and use these to derive the IT functions.  This enables the Systems Engineer and System Architect to capture more complete requirements and trace the IT functions to the business or organizational functions they support.  This modeling concept better fulfills the process envisioned for SOA, than merely using MDA to create the composite applications.  Now the services are traceable to the business or organizational processes and functions; which means that when the process changes, the effects on the composite application can be modeled and the composite application is more easily updated to enable and support the new process or function.

Event Driven Architecture and SOA

Event Driven Architecture (EDA) focuses on creating agile software, that is, software that can successfully react to external stimuli in a timely manner.  To perform this mission an EDA must be able to dynamically change both the functions it performs and the ordering of these functions in response to the stimulus.  This function falls along the branching logic dimension, which at one extreme is the simply “IF” statement and at the other is Artificial Intelligence (AI).  Obviously, the concepts from Knowledge Management (KM) can come into play with the functions along this dimension.  The key to EDA is determining what really constitutes an event.  This requires Complex Event Processing (CEP).  In terms of the OODA Loop, CEP constitutes the OO portion (“Observe” and “Orient”).

Actually, EDA can support three of the four functions of the OODA based on the concept of types of “event” rules.  There are three type are Knowledge Rules, Event Rules, and Value Rules.  A knowledge rule supports the Observe function of the OODA loop.  A Knowledge Rule

An event rule supports the Orient function of the OODA loop. Several measurements may predict an Event.  An Event Rule is a codification or formalization of this grouping and ordering of the measurements within a confidence interval.  For example, in the 1920s the prediction of a hurricane forming was decidedly hit or miss (a very wide confidence interval).  Today, hurricane and tornado predictions are much more valid (a much smaller confidence interval); in fact, there are possibilities for predicting earthquakes and Tsunamis.

In many cases, it is not a single event that causes a major or catastrophic problem or issue, but an event chain.  This has been found in the vast majority of recent aircraft accidences.  Understanding these event chains is CEP.  Another example is that now, the weather service not only predict that a tropical storm or hurricane will occur, but also identify where it will make landfall, and or if it will make landfall.  These two events, “there is a hurricane”, and its “coming our way” are part of the event chain that determine whether, “we’ll sit this one out”, or “it’s time to leave”.  To decide requires the decision-maker to understand the risks and rewards of the choice.

A value rule supports the decision-maker in the Decide function of the OODA loop.  A value rule determines the value to the organization of alternatives when an event or event chain has occurred.  In the case of the hurricane, the decision-maker makes the decision-based on the events, and value of staying versus leaving.  One well known example of value rules comes from Isaac Asimov.  The three value rules for robotics are:

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.

While the knowledge rules are state attributes and change of state attribute, the events create decision points in the process.  With SOA, the orchestration or choreography engines use the processes flows from the assembly process plus the rules, based on the governance, to enable the process flow among the functions (service components) of the composite application.  If the SOA is the Ecosystem SOA (public cloud), then the composite application uses choreography to dynamically interlink the service components [Sidebar: In a web services type of application, these service components are the web services.]  Choreography enables the application to choose which function or service component to use next anywhere on the Internet.  By coupling the choreography repository and engine with a organizational rules repository, and CEP rules repository and engine, the composite application can dynamically link to any appropriate service component that is available that, according to its combined rules will produce the best outcome.  The down side to this is that, first, as the number of alternates increases, the composite application will slow down, and second, the composite application may become much more stochastic than would normally be expected or useful.

Model and Event Driven Architecture is an amalgamation of Model and Event Driven Architecture, and in such an alloy increases the speed of the composite application, while reducing the risk that the application may become stochastic.  At the same time, the composite application is much more agile than that built using MDA.

The cost of this amalgamation is in terms of the complexity of the combined orchestration/ choreography/CEP engine (functionality) and the leadership and management discipline needed to ensure that the governance and “event” rules are enabling and supporting the organization’s vision and mission, and that they are as internally consistent as possible–that is, a minimum number of “catch 22s”.  This will require the a person with the role and responsibilities of an Enterprise Architect, as well as those of Systems Engineer and System Architect.