Event Driven Architecture

In my last blogentry I wrote about SOA as just one architectural approach. So I restudied older approaches I have been using and looked into new ones. Event Driven Architecture, based on the business events that trigger the business to work, is a new one. I once bought David Luckham's The Power of Events, as an introduction to Complex Event Processing.

Reading on the internet I found Jack van Hoof's blog about the relation between SOA and EDA. He sees SOA as manifested in the earlier in this blog defined strongly coupled information systems. SOA as based on command and control style, the 'slower' world of core business services.

And he sees the EDA as the fire and forget style, the mashup style of very loosely coupled services, the 'faster world'. Events form the linking pins between core business services.

This way, it seems my original SOA consists of two patterns, which you have to combine by making the right design decisions/trade offs.

Service oriented paradigm versus other paradigms

I had a SOA round table last night with some clever minds. I told them that in my opinion the service oriented paradigm is just one paradigm I use as an enterprise architect. I use for example also the data oriented approach, a proces oriented approach, all columns of the Zachman framework and more. One of them http://www.futurefurniture.nl/jeroen-j-van-beele asked me to make that more manifest. I will do that in due time. But for the time being I found will refer to some descriptions in NORA: http://matrix.e-overheid.nl/row.aspx?matrixid=nora&rowid=4&view=Architectuur (in dutch, especially paragraph 4.4.5).

Creating flexibility

Some-one refreshed my insight today into flexibility, especially in the alignment between business and information architecture and technology. He told me that inflexibility in information architecture and technology in relation to the business comes into existance if the (flexibility in the) model used for information architecture and technology is very different than the (flexibility in the) model of the business. In that case, simple changes in the business (for which flexibility they designed themselves) turn out to be very complex changes in information or technologie. In that case ICT becomes the main bottleneck for flexibility.

This might be a very good argument for the case of service orientation, if you use similar models of service decomposition throughout business architecture, information architecture and technology architecture. In that case, all models have the same flexibel and inflexible pieces, and the flexibility was in all models as chosen by the business (model). If anything, SOA gives flexibility (and inflexibility) design decisions back to the business in that case.

This is also a strong case for not using very different (disjoint) models in the different architectures.