SOA is een modegril

De weg naar een service georiënteerde architectuur ligt bezaaid met wrakken. Tal van organisaties hebben SOA-initiatieven zien mislukken, of vroegtijdig “geherprioriteerd”. En wat is er nou eigenlijk zo nieuw onder de zon? Services zijn toch ziet wezenlijk anders dan wat eerder componenten werd genoemd in “component based development?” Je zult zien, over een paar jaar dan hoor je niets meer over SOA. Dan heet het al lang SOB of SOZ. Zelfs steeds meer architecten zeggen jeuk te krijgen van de term SOA (no pun intended). Dus kunnen we onze tijd nu maar beter aan iets nuttigers besteden.

Flauwekul!

Iedereen die zegt dat SOA een hype is die wel weer overwaait, heeft niet echt begrepen waar SOA in essentie om gaat. SOA gaat namelijk om ontzuiling. Om het bestrijden van de aderverkalking die zoveel organisaties in zijn verstarrende greep houdt. SOA draait om het moderniseren van bedrijfsmodellen. SOA draait om flexibel kunnen meebewegen met een organisatie die niet langer meer in staat is om jaren vooruit te voorspellen welke kant de ontwikkelingen op zullen gaan. SOA is Serving your Organization with Agility.

Maar SOA was toch niets nieuws?

Dat is grotendeels waar. De aloude AMRO bank had al ruim voor de fusie met ABN een centrale contacten- en contractendatabase die je tegenwoordig zonder blikken of blozen een “customer relationship service” zou noemen. Zij waren erin geslaagd om die functionaliteit uit alle achterliggende systemen te halen en op een centrale plek te implementeren. Dat creëert overzicht en biedt allerlei mogelijkheden voor strategisch verkopen van diensten. Zij kregen dat voor elkaar op een klassiek mainframe platform, zelfs lang voordat het begrip EAI was uitgevonden. Voor ABNAMRO was dit naar verluidt een belangrijke reden om na de fusie voor de AMRO backofficesystemen te kiezen.

Van UBS is bekend dat zij heel ver zijn gekomen met het ontwikkelen van enterprise services op hun CORBA platform. En er zijn ongetwijfeld vele andere voorbeelden te noemen. Zo bezien zijn moderne hulpmiddelen als ESB en webservices helemaal niet voorwaardelijk om de SOA ontwerpprincipes toe te passen. Ze maken het hoogstens wat makkelijker.

In het recente verleden zijn er al eerder aanvallen gedaan op de traditionele, verzuilde manier van werken, bijvoorbeeld onder de koppen

• Business Process Redesign
• Business Process Innovation
• Customer Relationship Management
• Multi-Channel Management

Dat dit niet 1-2-3 succesvol is, valt best te begrijpen. Generaties bedrijfskundigen zijn opgevoed in de school van Porter. Een waardeketen bestaat uit een serie winst-creërende eenheden. Iedere schakel in de keten heeft een aantal kernfuncties, met name inkomende en uitgaande logistiek, productie, marketing & verkoop en nazorg. Hieruit zijn de horizontale silo’s in organisaties ontstaan. De door Porter benoemde ondersteunende functies, bijvoorbeeld HRM, ICT, Inkoop, Juridische zaken en Boekhouding, zijn traditioneel buiten de silo’s met kernsystemen gehouden en in de verticale systemen terecht gekomen. In die bedrijfsfuncties zit, volgens het gedachtegoed van Porter, het synergiepotentieel voor organisaties met meerdere winst-creërende eenheden. Logischerwijs zijn die dus doorgaans op enterprise niveau georganiseerd. De dominantie van dit referentiemodel verklaart waarom het zoveel makkelijker is om in een organisatie een centraal HRM systeem in te voeren, dan een centraal CRM systeem.

De architectuuragenda

Het is een fascinerende tijd om als enterprise architect te werken. De vraagkant is volop in beweging met innovatieve business modellen als drijvende kracht. Netwerken nemen de plaats in ketens, dynamische landschappen komen in plaats van starre zuilenstelsels. De zakelijke belofte van het internet begint eindelijk tot wasdom te komen. “Blown to Bits” wordt alsnog realiteit.

Tegelijkertijd is de technologie enorm in beweging. Je ziet dat het internet nu echt breed geaccepteerd wordt als volwassen distributiekanaal, met “Web 2.0” als drijvende kracht. Daar heb je te maken met een golf aan nieuwe technieken en ontwikkelingen. Er komt steeds meer interactiviteit tussen een aanbieder en een afnemer, maar ook tussen de afnemers onderling. Hoe kun je dat in goede banen leiden?

Business georiënteerde hulpmiddelen als Business Rules Engines en Business Process Management Systemen, maar ook technologieën als ESB en AJAX zullen daarbij een rol spelen. Het is immers ruimschoots aangetoond dat business analisten in staat zijn om met deze hulpmiddelen de dynamiek in de business op eigen kracht te vertalen naar gewijzigde bedrijfsregels en procesmodellen. De techniek zorgt er dan voor dat die wijzigingen zonder tussenkomst van hard-core IT-ers doorgevoerd worden in de systemen.

In de praktijk valt het echter nog niet mee om deze technieken goed toe te passen; zeker niet in onderlinge samenhang – wat uiteindelijk de kracht van een SOA is. Het is makkelijk gezegd om de proceslogica te isoleren, de integratielogica te isoleren en de beslislogica te isoleren, om uiteindelijk de klassieke kernsystemen te reduceren tot een stabiel, betrouwbaar maar dom register. Maar welke logica beschouw je precies als proceslogica, en welke als besluitvorming? Waar houdt proceslogica op, en begint integratielogica? Welke kerngegevens horen in een register, en welke feiten kun je beter in een business rules engine vastleggen? Wie mag eigenlijk op welk moment beslissen over het doorvoeren van welk soort wijzigingen? En hoe kun je in zo’n gedistribueerde wereld toch robuuste compliancy waarborgen inbouwen? Stuk voor stuk lastige vraagstukken. Maar zo lastig dat je ze maar beter aan een opvolger kunt overlaten?

De omslag in het denken over organisaties is gaande. Er is nog geen nieuw, dominant paradigma ontstaan. Dat zal ook nog wel 1 of 2 managementgeneraties duren. Het zou mij niet verbazen als er nooit meer zo’n breed geaccepteerd model als dat van Porter zou ontstaan. Het beste dat je als enterprise architect op dit moment kunt doen is ervaring opdoen met ontzuilen, al was het maar om te voorkomen dat je zelf onderdeel wordt van een legacy probleem. Want als de markt vandaag de dag ergens behoefte aan heeft, dan is het aan enterprise architecten die in staat zijn om de complexiteit te ontrafelen die nodig is om ontzuiling te realiseren.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 1^ste in een reeks flauwekul die op dit weblog gepubliceerd zal worden.