SOA in relatie tot Enterprise Architectuur

Vandaag was ik bij een klant bezig met service orientatie. De technische acroniemen en invalshoeken vlogen om mijn oren. Herhaaldelijk legde ik uit dat SOA voor mij niet technisch is. En dat SOA veel te maken heeft met de enterprise architectuur. Daarvoor ging ik terug gaan naar de meest elementaire definitie van service orientatie.

Ik beschouw service orientatie als een manier om naar de wereld te kijken. Daarmee deel je de wereld in in service vragers en service aanbieders. Een mooie manier om de wereld, een organisatie of een applicatie landschap in delen op te splitsen. Een erg oud model, want het is het model van vraag en aanbod in de markteconomie. Kortom, ik zie service orientatie als een decompositie paradigma, een classificatie wijze.

Als je naar de gebruikelijke SOA verhalen kijkt, herken je dat die over zaken gaan als webservices, enterprise service bus, bepaalde standaards (SOAP, XML, etc.). Kortweg over technische architectuur en in het bijzonder leveranciers van technische hulpmiddelen. Dit zie je in de meeste boeken en presentaties over SOA. Het type services dat je dan tegenkomt zijn ondersteunende services, zoals security services of transformatie services of data services. Dit niveau in SOA is relevant, op dit niveau haal je voordelen in gemakkelijker integratie en betere onderhoudbaarheid.

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.