Kan een (SOA-) architect veranderen?

Soa, snel kunnen inspelen op veranderingen, ik dacht er eens over na…

Het afgelopen jaar is veel geschreven over Ssoa; geweldige mogelijkheden zijn geschetst om eindelijk flexibiliteit te gaan creëren in het it-landschap, hoge verwachtingen zijn gewekt   vanuit technologie leveranciers, vele seminars zijn gehouden over soa.

De voordelen zijn breed uitgemeten:  processen, eindelijk uit de "hardcoded" applicatie omgeving bevrijd middels bpm, herbruikbare services om de complexiteit van de point to point spaghetti te bestrijden, kortom "The future is really promising !". Alles gericht om snel te kunnen inspelen op veranderingen….

Snel kunnen inspelen op veranderingen…., ik dacht er eens over na en moest denken aan de situatie van vandaag:

• De budgetten liggen bij de business en "de eerste passagier wil niet de hele bus betalen"
• Een business die korte termijn gedreven is en snel resultaten wil en waarbij flexibilisering van het gehele  it-landschap niet op de agenda staat
• Een it-organisatie, of erger nog meerdere gedecentraliseerde it-organisaties, die nog steeds erg "applicatie centrisch" denken en maar matig samenwerken
• Een geoutsourced applicatie landschap naar een IT service provider, die ook zo zijn belangen heeft en waarmee contractueel geen afspraken over invoering soa zijn gemaakt
• Architecten die, in een zoveelste poging, soa aan de business proberen te verkopen, maar daarbij i.p.v. het menu van het restaurant het kookboek van de chefkok hanteren
• Top management die it maar te duur vindt en het ook allemaal veel te complex vindt
• Op papier  een prima governance op architectuur, maar in de praktijk  " nu even niet"
•  Informatie technologie leveranciers die met hun sales activiteiten al zoveel verwachtingen creëren, dat alleen om die redenen al de eerste pilots mislukken

  Snel kunnen inspelen op verandering…., ik dacht er eens over na.

Over waar als soa-architect  te beginnen. Hoe deze schier onmogelijke taak aan te pakken,  Want de cio verwachtte tenslotte wel wat ! Je bedenkt je op zo een moment dat je eigenlijk best veel van architectuur en technologie afweet, maar eigenlijk weinig of niets  over hoe te veranderen, hoe de bal in het spel te brengen, hem daarna verder te laten rollen en hem succes vol naar de finale te brengen.

Is bovenstaande herkenbaar ?

Uit eigen ervaring kan ik stellen dat het succes van een soa-implementatie in zeer sterke mate afhankelijk is van het vermogen om veranderingen op gang te brengen. Natuurlijk is het belangrijk de juiste services te creëren en datamodellen te definieren, maar waar het echt om gaat is hoe mensen ervoor enthousiast te krijgen, de business aan boord, en de beweging op gang (het is tenslotte geen eindig project).

Kortom het thema is verandermanagement en soa is m.i. slechts de technologie component daarvan. Vaker heb ik gesteld dat de invoering van soa voor meer dan 70 procent een "people issue" is, en dat die technologie echt wel werkt.

Kijkend vanuit de optiek van verandermanagement komen dan twee vragen naar boven: wat willen we veranderen en hoe pakken we dat aan.

Voor het "wat" kijken we in eerste instantie naar de business. It ondersteunt de business, en dus zullen de it'ers de business moeten begrijpen, hun taal spreken, zien hoe de markt in elkaar zit en wat de concurrentie doet, de strategie van de business begrijpen, of sterker nog mee helpen vormgeven; Goede relaties creëren met de collega's in de business en echt gaan begrijpen wat er in de markt verandert en hoe deze veranderingen doorwerken op de business ("outside in" denken).

(Wanneer heeft de architect voor het laatst met de productmanager of marketier gesproken en wanneer ging dat gesprek ook echt over de markt op een zodanig nivo dat de marketier toch even in zijn enthousiasme vergat dat hij met een iter om de tafel zat ?)

Voor een echt soa-succes is 100 procent  business/ it-alignment cruciaal.

Mijn visie op de architect van de toekomst is dat hij de taal van de business spreekt en dat hij als meerwaarde de eigenschap bezit de behoefte van de business te kunnen vertalen naar it en het soa-initiatief. Dat hij het continue proces van business unbundling en bundling, waardoor in de markt concurrentie ontstaat op deelproducten en processen gaat begrijpen en dit kan vertalen naar waar in it het "loosely coupled" zijn plaats moet krijgen.

De architect van de toekomst is ook iemand die een verandering in mindset in de organisatie weet te realiseren om daarmee het applicatie centrisch denken om te buigen naar service oriëntatie, en die daarmee dus oog heeft hoe een lerende organisatie te creëren. Ook dit vereist juiste verandervaardigheden. Bovenal zal de architect dus ook zelf moeten veranderen.

Enkele gedachten over " hoe het aan te pakken". Mijn beeld is dat de organisatie als een organisme te beschouwen is, dat continu in beweging is, met daarin vele spelers/actoren en met belangen. Om daarin succesvol tot een soa-implementatie te komen is een veranderaanpak nodig, die tenminste de volgende elementen omvat:

• Een goede analyse/diagnose van de it-situatie in meerdere dimensies (business doelen, stakeholders, belangen, organisatie structuren, pijnpunten, financiën en uiteraard ook it)
• Een goed plan van aanpak dat naast de gebruikelijke PRINCE 2 elementen ook andere aspecten adresseert, zoals welke interventie strategieën wanneer en waar te hanteren
• Het continu managen van stakeholders (een "enterprise breed" soa-initiatief loopt langer dan de gemiddelde tijd waarin it-management op zijn functie zit)
• Communicatie die gericht is op het enthousiasmeren en in beweging krijgen van mensen, en iedereen deelachtig te maken aan het succes (alleen dan beklijft het initiatief)
• Hoe lesssons learned ( en dat zijn er doorgaans nogal wat bij een soa-initiatief) "on going" te implementeren
• Hoe externe druk, business problemen, business projecten, organisatie dynamiek te kunnen hanteren als "driver for change" in het soa-initiatief, waarbij deze het soa-initiatief voorstuwen, en waarbij de waarde van het initiatief groter wordt als de som van de onderliggende business projecten
• Hoe effectief om te gaan met weerstand (want ook die is er !)
• De governance nodig om de verandering in gang te zetten, maar ook om het bereikte in stand te houden.

Zoals gesteld, het creëren van flexibiliteit en het vermogen om snel aan te passen, is met soa  m.i. tot op heden voornamelijk vanuit de technologie dimensie benaderd.

Wanneer we echter de in het vooruitzicht gestelde voordelen willen incasseren, zullen we  ook met de organisatie, het systeem, de mensen daarin, de mindset en de regels aan de slag moeten. En dat dus brengt mij bij de vraag waarmee ik startte: kan een (soa-) architect Veranderen ?

Zoals altijd, reacties zijn welkom