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.

SOA and Architecture language Archimate

Service Orientation is said to bridge the gap between Business and ICT. In Archimate, the Architecture language, the concrete result of this can be seen. Services is a core element of the language. And this core element bridges the gap between different architecture levels. External business services bridge the gap to the outside world and external application services bridge the gap between business architecture and information architecture. Technical services do the same between information architecture and technology architecture.

Can services be drawn between the horizontal Zachman layers aswell, I wonder?

Remodularizing Heritage Systems

Some people might think that to fit heritage systems (nicer term than legacy) into service oriented architecture, you only need to create services on top of them. My opinion however is that, to acquire real flexibility, the decomposition of the heritage systems is at stake aswell.

As Harry Pierson writes here:
"SOA is a way of implementing IT systems as a web of interconnected yet independent loosely coupled subsystems (typically called services) instead of as big honking systems we have traditionally built that tend to be unwieldy, in-agile, difficult to change and probably obsolete by the time they were deployed."

and I totally agree with that. Simply putting services on top of heritage systems is good for integration and reuse, but not for flexibility.

Service Normal Form

Today I was working on finding relevant business services. As normal I used criteria like good abstractions, good separation of concerns, maximum cohesion and minimum coupling, added value of a cohesive set, in the numbers 7 +/- 2 for any level and a relevant service requestor could be found. But the design decisions I made did not completely satisfy me. Suddenly a thought struck me: just as in database theory there should be service normal forms, with standard rules to get to, validate and optimize the correct services.

Surfing internet it turned out that others had already had the same thought. They are researching "what kind of properties a "good" service should have". I will read it and come back on this subject later.

Initiative in an SOA architecture

I am charmed of the figure below (originally by BEA). Most of the layered SOA models put the GUI layer on top, near the user. Then follows the proceslayer, business logic layer and data layer.

I always wondered which layer had the initiative. It always seemed that initiative coming from the user had to come from the GUI layer and had to pass all layers.

In this figure however it seems (if the user is on top of the figure) that this composite applications layer wil have the initiative. Only after some action in that layer, the user will get a presentation. Presentation is not first. This seems a logical order to me. The Composite Applications layer also can access all other layers, without going through the others. That is the second thing I like. I am still wondering whether accessing Information Services directly is a wise thing to do, without going through Business logic. I can imagine that is ok when just accessing and viewing information.

SOA, the two speed architecture

I was in a discussion today with Ruud van Vliet about the two worlds that SOA seems to deliver.

We noted that SOA delivers a slower world of core competences, core services, that need to have high quality and robustness. Typically these services are delivered in cycles or releases of 3 months+. In most enterprises these services are hidden in heritage (nicer term than legacy) systems currently and must be freed gradually.

And we noted a fast world of Mashing up, Composing, Integration and Process Flow, in which changes can be done by the day. This is especially seen in the Web 2.0 world, where mashing up (combining and remixing) existing data and services on the web is a trend. Typically new services are and can be delivered in minutes or days.

This might result in new roles in the information landscape. On one side communicative, fast business analyst that can configure new experiences for the business in short periods of time, reusing existing services from a service repository. And techies, that deliver new core services on a longer timeframe.

How to make your enterprise a service oriented enterprise?

I was pointed at the contribution of Niels Klinkenberg to LAC 2005 with respect to SOE (Service Oriented Enterprise). The relation is made between service orientation to a network of organizaties, aimed at optimal flow. It states the conditions of success to install a SOE and make it work.

SOA in relation to Enterprise Architecture

Today I was busy with service orientation. The acronyms flew round my head. In the past I have tried to place those acronyms in the typical layers of enterprise architecture. I go back to the basics of the most elementary definition of service orientation to be able to do that.

I view service orientation as a way to view the world. With it, you devide the world into service providers and service requestors. A beautiful way to arrange the world (or enterprise or application landscape) in parts. A very old model as well, as it is the simple model of supply and demand from the economy. In short, I see service orientation as a decomposition paradigm, a classification style. Of course that is extended with ways to find what services to choose and to (re)combine services to larger wholes.

If you look at this way to the usual SOA stories, you recognize that talk about things like
webservices, enterprise service bus, certain standards (SOAP, XML, etc.). In short, technical architecture and especially the area of suppliers. This is what most books are talking about and most marketing talk. From this we recognize supporting services, like security services or transformation services or technical data services. Advantages you can get from doing SOA at this level is easy integration and better maintainability.

One level up in the enterprise architeccture, you find the information architecture. At this level service orientation is, as I understand it, about finding the correct decomposition of information area's, components or 'logical information systems'. By applying the service orientation criterium you might get a new module classification of application. I am only starting to understand the criteria to use to find those services or service units. I find the services found even less important that the service units found (you might therefor name service units to services). Internal and external application services are interesting on this level. Also, the service catalogue of COTS applications have their place here. You can compose services from here, via BPM or Mashup. I am wandering which advantages this view will have in practice.
I will go into this later.

The next level is the business architecture. The basic definition of service orientation is applicable at this level aswell. You could organise an organization as a network of service providers and requestors. In practice that is the trend in organizations. Due to outsourcing. But also within units, teams, who get the responsibility to deliver services to others. The hierarchical organization and direct supervision of HOW the work is done is disappearing somewhat. Tasks and services appear that must be performed according to specific criteria. This level I call service oriented enterprise (SOE).

At the highest level of enterprise architecture we find business context and scope. Here service orientation is the normal (economic) model. Deliver to customers as they ask.

In my current knowledge, organizations acquire the most advantages from service orientation, when operating from business context or business architecture level down. It seems that organizing your enterprise this way also helps to align business context, business, information and technology to be able to work in the same dynamics.

Information architecture

How come that information isn't used in organizations more innovative, more consistent and more effective?

That is a question which intrigues me for years now. I search for the answers in disciplines like enterprise architecture and information architecture. Although I started searching in structure sciences, I have broadened my view to the art and science of designing complex organizations and information structures. I will explore in this blog how it can be done differently. Different from other perspectives, through serving the informationworker.