Service Gerichte Architectuur (SOA) heeft een flinke hype-cyclus doorlopen. Voor veel organisaties is het dal van ontnuchtering al ingegaan. Het moet vaak al weer REST of HTML5 zijn om de interesse op te wekken.

Dat is een ernstige misvatting. Door wéér mee te bewegen met nieuwe ontwikkelingen in de vorm van een hype, gooien we (weer) het kind met het badwater weg. SOA heeft ontzettend veel toegevoegde waarde, vooral in complexere omgevingen. Maar de wijze waarop het is toegepast is vaak fout gegaan door een verscheidenheid aan oorzaken:

  1. ook SOA is als een hype opgepakt. D.w.z. alsof het iets nieuws zou zijn, en we alle geleerde van voorgaande ontwikkelingen (die op hun beurt ook vaak als hypes zijn opgepakt...) kunnen en zelfs zouden moeten vergeten. Daardoor hebben we de belangrijke lessen die ons geleerd werden door gestructureerd programmeren, object-oriëntatie, component-based ontwerpen, en ontwerp- en architectuurpatronen, niet voldoende of zelfs helemaal niet meegenomen in wat we zijn gaan doen met SOA.
  2. SOA heeft de focus teveel gelegd op het proces aspect: de executie van service-calls vanuit een service bus.
  3. SOA heeft de focus teveel gelegd op het data aspect: service calls die niet veel meer waren dan CRUD services aanroepen op een dun schilletje om een legacy systeem.
  4. SOA heeft de focus teveel gelegd op het integratie gedeelte: een heterogeen landschap van legacy systemen beter met elkaar laten praten.
  5. De focus lag teveel op de implementatie van een complex en omvangrijk product. De implementatie van WebSphere, Oracle Fusion, SAP of Cordys. Weliswaar leveren deze producten ontzettend veel zinvolle functionaliteit, maar organisaties die nog niet eens precies weten wát ze willen gebruiken, laat staan hóe, moeten zich de oren niet laten wassen door consultants van leveranciers die hen dat wel even uit willen leggen.
Hoe had het dan wél gemoeten? Dat komen wij u vertellen. En u daarbij helpen. Een aantal punten:
  1. De focus moet liggen op directe business behoeftes, aansluitend bij het gewenste of bestaande bedrijfsproces
  2. Dit bedrijfsproces moet niet centraal staan in de implementatie van services, maar omgekeerd: de service implementatie moet gevalideerd worden door het proces. De implementatie zélf moet ontstaan vanuit een solide en op de juiste wijze opgebouwd model van de business.
  3. De aansluiting moet niet te ver in de toekomst liggen: SOA moet nú zijn toegevoegde waarde bewijzen. Dit betekent extreem kortcyclisch implementeren, en dit vraagt weer om specifieke competenties op verschillende plekken in de organisatie, waarbij een solide architectuurproces een belangrijke rol speelt.
  4. Services moet geen CRUD services zijn maar daadwerkelijke dynamische procescomponenten (gedrag) activeren.
  5. De enterprise service bus (ESB) moet zo licht mogelijk zijn. De minimalistische benadering werkt hier het beste.
De gehanteerde methodiek is gebaseerd op Thomas Erl, en sterk geïnspireerd door architectuurpatterns van Fownler en Hohpe.