Acht blinde monniken komen voor het eerst in hun leven een olifant tegen. En ene betast zijn poot en voelt een boom. De tweede heeft zijn slagtand vast en denkt aan een speer. Enzovoorts. Alle monniken hebben een deel van een nieuw fenomeen te pakken en geen van alle heeft een compleet beeld. Zo voel ik me regelmatig bij mijn onderzoek naar het fenomeen service-oriented application management (soam) . Desondanks ben ik in de gesprekken die ik in het afgelopen jaar met verschillende klanten en leveranciers heb gevoerd tot de conclusie gekomen dat je extra aandacht moet besteden aan drie zaken: architectuur, governance en een adhocratische aanpak.
Er wordt heel veel over service oriented architecture geschreven en gesproken en stukje bij beetje worden op soa gebaseerde applicaties gebouwd. De voordelen zijn immers aantrekkelijk: meer flexibiliteit en betere integratie van informatie, zowel binnen als buiten individuele organisaties. De ontwikkeling van dit soort systemen is al uitdagend genoeg meer beheer ervan is nog lastiger. Om ermee te beginnen, de ontwikkelaars praten raar. Ze hebben het bijvoorbeeld over registries en repositories en over service publication en service invocation. Nooit van gehoord, zegt de gemiddelde beheerder, kun je dat eten? De bouwers praten soaliaans, terwijl de beheerders itiliaans en asliaans spreken. Dat schiet niet op. De met moeite gebouwde brug tussen bouw en beheer lijkt af te brokkelen.
Het gevaar is groot dat wanneer soa-systemen niet effectief worden beheerd de beoogde voordelen in onvoldoende mate zullen worden behaald. Dit heeft dan tot gevolg dat organisaties niet bereid zijn om verder in deze technologie te investeren. Maar door aandacht te besteden aan architectuur, eigenaarschap en de wijze van organisatie worden de risico's verkleind.
- Architectuur: Zonder vakmensen die volgens architectuurprincipes werken en zonder management dat architectuurprocessen inricht en controleert is de kans van slagen voor SOA heel klein. Beleg dus de verantwoordelijkheden voor het vaststellen van architectuurprincipes en het erop toezien dat men zich daaraan houdt!
- Governance: Omdat een soa-systemen uit allerlei componenten bestaat waarvan vele door andere systemen en verschillende afdelingen worden gebruikt zijn er uitdagingen ten aanzien van sturing en financiering. Je moet vast stellen wie voor welke deel van het systeem verantwoordelijk is en hoe je gebruik van gemeenschappelijke componenten verrekent.
- Organisatie: Erken dat beheer van soa-systemen lang niet uitgekristalliseerd is en dus nog onvoldoende geformaliseerd is en organiseer het beheer op een adhocratische wijze (multidisciplinair team met hoogwaardige expertise, veel onderlinge afstemming en weinig formele procedures). Zodra de spelregels van dit nieuwe beheer zijn ontdekt, kan het geformaliseerd worden en worden gepromoveerd tot normaal beheer bij de reguliere beheerorganisatie.
Zijn er andere blinde monniken die hun ervaring willen delen?
Mijn zicht is nog prima en het celibaat als middel tegen SOA lijkt me ook wat overdreven. Evengoed heb ik wel de behoefte om SOA beheerervaring te delen. Mijn ervaring met SOA is dat het “vreet” aan de basis van de bekende driedeling van beheer; functioneel, applicatie en technisch beheer. In het pre-SOA tijdperk deed ieder zijn kunstje, al dan niet met hulp van de ons bekende best-practice frameworks BISL, ASL en ITIL. In het SOA tijdperk zijn de drie delen gedoemd tot samenwerken volgens een gemeenschappelijk best-practise framework. De business kan hier als vierde en belangrijkste “deel” aan worden toegevoegd. Het beheer van “serviceketens” en “servicecomponenten” is me binnen het kader van technisch beheer niet vreemd. Tot op heden betrof dit echter diensten rond technische componenten die het hosten van applicaties ondersteunen. Door toepassing van een SOA krijgt een serviceketen een nieuwe betekenis, namelijk een keten van functionele applicatie componenten. Deze functionele componenten ofwel software services zijn dusdanig gestandaardiseerd dat ze volgens bekende best practices als infrastructuur beheerd kunnen worden. De onderliggende technische keten “verdwijnt” hierbij in de service implementatie. Ik ben van mening dat we als beheerders bij onze leest moeten blijven en niet de huidige beheerprincipes en frameworks over boord moeten gooien. Wat mij betreft absorberen we de nieuw te beheren “bouwstenen” in het referentiekader dat we kennen. Dit kader passen we aan daar waar dat nodig blijkt. Ik geloof dus niet zo in een top-down benadering van beheer waar architecten gaan bepalen hoe we de beheeruitdaging gaan slechten. Beheerders hebben verstand van beheer en architecten van principes. Beheerarchitecten zijn er (nog) niet.
Een adhoc organisatie bied een opening naar anarchie. Ik verwacht meer succes van een evoluerende aanpak waarbij de vier beheerdisciplines in de context van een eerste business projekt SOA principes toepast samenwerkt en leert. De bestaande werkwijze en regelgeving kan vervolgens aangepast worden naar aanleiding van leerpunten uit het eerste projekt. Zodra de beheerders zich “volwassen” genoeg achten kunnen ze meer kritische business processen ondersteunen met SOA oplossingen. Om de communicatiekloof te slechten kunnen de vier beheerdisciplines een SOA framework kiezen zodat we in ieder geval dezelfde taal spreken. Het maakt hierbij feitelijk niet uit welk framework je kiest, als je maar allemaal dezelfde kiest. Ik zelf ben nogal gecharmeerd van het framework van CBDI omdat dit vendor onafhankelijk is en ook relatief veel aandacht heeft voor beheeraspecten van SOA.
Robert Smit
SOA activist bij KLM
Ik ben niet alleen blinde monnik maar ook paradigmaloog en ik herken dat “vreten aan driedeling van beheer”. Ik ben er nog niet uit wat het nieuwe paradigma is maar de spanning voel ik.
Over dat leren ben ik het met Robert eens. Vooral met zijn allen leren.