De blinde monnik Smalley en de olifant SOAM

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?