Infoworld

Veel bedrijven lopen in twee verschillende valkuilen als ze SOA-governance willen implementeren. De eerste valkuil is het ontbreken van een robuust governancemodel. De tweede valkuil is dat er dusdanig veel processen zijn dat het veel te lang duurt om dingen gedaan te krijgen. De truc is een balans te vinden tussen de processen en flexibiliteit.

Te weinig proces leidt tot chaos

Bedrijven hebben geen robuust governancemodel om een aantal redenen:

• Geen volledig begrip van zowel ontwerptijd als runtime best practices
• De cultuur ondersteunt de standaarden en best practices niet
• Geen budget voor governancehulpmiddelen en -gereedschappen
• Onrealistische deadlines
• Gebrek aan ondersteuning door de leidinggevenden

Zonder een effectief governancemodel kunnen je dromen over een SOA-hemel veranderen in nachtmerries vol platliggende systemen, hoge ontwikkelingskosten, onbeheersbare productie-omgevingen en ontevreden klanten.

Om het hergebruik, de flexibiliteit, de wendbaarheid, en het gemak van integratie te krijgen zoals SOA dat voorspiegelt, moet ontwerptijdgovernance ervoor zorgen dat diensten consequent worden gebouwd op een manier die bedrijfswaarde oplevert, voldoet aan bepaalde prestatie- en beveiligingseisen, platformonafhankelijk is en bovendien niks kapot maakt wat op dat moment al gebruikt wordt.

Gezien de abstracte en gedistribueerde aard van SOA is runtimegovernance van cruciaal belang. Eén enkele bedrijfsdienst kan uit een aantal componenten bestaan binnen allerlei verschillende architectuurlagen. Als die dienst uitvalt, kun je maar beter de juiste processen en gereedschappen bij de hand hebben om de problemen snel op te sporen en te herstellen... voordat je klanten het merken.

Dan is er nog de complexiteit van het managen van versiebeheer bij services, het proactief toezien op prestaties en beveiliging, het zorgen voor compliance, het afdwingen van gereguleerde controles, en nog veel meer.

De implementatie van SOA zonder een degelijk governancemodel is te vergelijken met een vliegveld zonder verkeerstoren. Natuurlijk zijn er goede vliegtuigen en piloten, maar zonder de juiste planning en stipte informatie zijn de gevolgen funest. Dus zorg ervoor dat je een verkeerstoren bouwt en een aantal verkeersleiders inhuurt.

Teveel proces belemmert innovatie en zorgt voor starheid

Daar lijnrecht tegenover staan de organisaties die geloven in processen omwille van processen. Ze creëren zoveel processen dan het team bedolven raakt onder documentatie en het zicht kwijtraakt op hun rol in de bedrijfsprocessen. Ik heb mensen diensten zien opheffen die zo fijnmazig zijn dat ze weinig tot geen waarde opleveren en nooit meer opnieuw worden gebruikt. We hebben het dan over “overkill governance” of “dood door processen”, wat zorgt voor een robot-achtige denkwijze bij de architecten, waardoor ze alleen nog maar doen wat de documenten of controlelijsten voorschrijven. En dan zijn er nog de lange beoordelingsprocedures, waarbij het weken duurt voordat dingen goedgekeurd worden, terwijl dat ook in een dag of twee zou moeten kunnen. Redenen voor dit type model:

• SOA wordt beschouwd als een technologieprobleem in plaats van als vehikel voor bedrijfsprocessen
• Gebrek aan vertrouwen in en empowerment van architecten en managers
• Een cultuur die barts van de processen, gewend aan lange omlooptijden
• Gebrek aan technische en bedrijfsexpertise onder leidinggevenden

De juiste balans

Elke bedrijfscultuur en ieder SOA-initiatief is uniek. Er is geen gouden standaard voor een governancemodel. Leveranciers, adviesbureaus voor SOA-implementatie en de organisaties die standaarden beheren hebben allemaal goed gedocumenteerde methodologieën voor SOA-governance. Kies er één die het beste past bij jouw cultuur en pas het aan aan de behoeften van je bedrijf.

Hoe kunnen we tegelijkertijd flexibel zijn en SOA-governance hanteren? Eén manier is over te stappen van zware tekstuele documentatie naar visuele documentatie. Met andere woorden: stop met het genereren van honderden pagina’s lange Word-documenten en begin met het bouwen van UML-modellen en bedrijfsprocesmodellen en het gebruik van casus- en architectuurdiagrammen. Deze hulpmiddelen zijn als blauwdrukken voor een bouwkundig architect. Zou jij bij het bouwen van je droomhuis de specificaties voor je huis uittypen in een Word-document en aan je aannemer geven, of zou je hem liever blauwdrukken aanleveren? Richt je op hulpmiddelen die waarde toevoegen en ontdoe je van al het andere. Laat je personeel geen stappen uitvoeren die geen enkel ander doel hebben dan het afwerken van een controlelijst. SOA-governance zou niet door projectmanagers tot stand moeten worden gebracht; het zijn de architecten die het moeten definiëren. Het draait allemaal om het managen van levenscyclussen van diensten en de standaard n-tier processen zijn daarbij niet van toepassing.

Laat governance evolueren

Zelfs als het je lukt processen en flexibiliteit in balans te krijgen, is het niet verstandig alles tegelijk te implementeren. Net zoals SOA zelf is SOA-governance een traject zonder einde. Begin klein en implementeer alleen de stappen die op dat moment nodig zijn.

Als bijvoorbeeld je eerste implementatie vijftien tot twintig diensten heeft, is het misschien helemaal niet nodig een robuust SOA-center of excellence (COE) te hebben, met name wanneer het team slechts uit een handjevol technici bestaat. Naarmate het aantal diensten toeneemt en het aantal architecten en ontwikkelaars groeit kun je je governancemodel mee laten groeien. Sommige bedrijven zijn meer dan een jaar bezig met het installeren van alle juiste governanceprocessen. Dat is een jaar waarin er helemaal geen waarde aan het bedrijf wordt toegevoegd. Voeg SOA-governance toe als een cruciaal stuk van je SOA-roadmap. Uiteindelijk word je beoordeeld aan de hand van de bedrijfswaarde die SOA oplevert. Dus zorg ervoor dat je SOA-governancemodel de juiste balans heeft tussen SOA best practices en zakelijke flexibiliteit.

Mike Kavis is een software architect met meer dan 23 jaar IT-ervaring in onder meer distributed computing, SOA, BPM, data warehouse, business intelligence en enterprise architecture.