SOA en governance; de ene hype kan niet zonder de andere
Een goed functionerende, servicegerichte architectuur (SOA) bouwen lukt niet zonder een degelijke governance onderbouw. Maar zodra SOA volledig functioneel is, wordt het weer eenvoudiger om aan governance te doen. Zo ziet Accenture de complexe relatie tussen twee van de meest gehypete begrippen.
Een volledig functionerende SOA bereikt men niet op enkele maanden tijd, waarschuwt Ezio Armando, SOA specialty director van Accenture EMEA: ‘Men dient vier adoptiefases te doorlopen, en tussen het allereerste begin en de volledige voltooiing kunnen al snel vier jaar of meer zitten.’ De vier fasen zijn, ruwweg ingedeeld:
– Fase 1: organisatie en strategie. Hier moet men bekijken of de IT-infrastructuur wel klaar is om het SOA-traject te doorlopen, en wat er moet veranderen. Maar evenzeer dient men na te gaan welke bedrijfsbehoeften bestaan voor SOA-projecten, en (best op basis daarvan) management buy-in te verkrijgen voor het SOA-traject.
– Fase 2: proefproject. Een eerste SOA-project heeft als hoofddoel het omzetten van een toepassing in een service, en het samenvoegen van deze diensten tot een eerste bedrijfsproces. Uiteraard kiest men hier best niet voor een bedrijfskritiek project, maar wel voor eentje met hoge zichtbaarheid.
– Fase 3: SOA-platform. Hier gaat men van het tactische niveau naar het strategische. Door het bedrijfsbreed inzetten van een ESB (Enterprise Service Bus) kan men alle diensten en processen beginnen samenbrengen en hergebruiken, op voorwaarde dat ze goed en uniform gedefi nieerd zijn. In deze fase begint men ook servicegericht te ontwerpen en te ontwikkelen.
– Fase 4: ‘Geïndustrialiseerde’ SOA. In deze fase is het ontwikkelen en koppelen van services al een geïndustrialiseerd, lees: herhaalbaar, proces geworden. Sommige processen overstijgen zelfs de bedrijfsgrenzen. Men krijgt een bijna real-time zicht op de bedrijfsprocessen.
‘De helft van de Fortune 500-bedrijven zijn nu net voorbij fase 2 en zullen nog wel enige tijd in fase 3 vertoeven,’ schat Ezio Armando, ‘en haast niemand zit al in fase 4, vooral als we de diensten tussen verschillende bedrijven als criterium nemen. Dus u kunt zelf wel uitrekenen wat dit voor het gemiddelde bedrijf betekent.’ Vrij vertaald: een volledige SOAarchitectuur moeten we de komende jaren nergens in België verwachten.
‘Het grote probleem voor vele bedrijven ligt in de overgang van fase 2 naar fase 3,’ meent Armando, ‘waar een bedrijf SOA niet meer tactisch inzet maar strategisch. Om SOA bedrijfsbreed in te zetten, volstaat het niet om enkel te zorgen dat de verschillende diensten in het proefproject op elkaar zijn afgestemd. Op dat moment moeten alle IT assets goed gekend zijn en uniform gedefi nieerd worden.’ Het uniform defi niëren van software als service houdt de nodige uitdagingen in, omdat het ook op gegevensniveau de nodige standaardisering vergt. ‘Zelfs een eenvoudige basisdienst zoals ‘maak een klant aan’ is complexer dan het lijkt,’ waarschuwt Armando, ‘iedereen moet het eens zijn over de defi nitie van ‘klant’, welke informatie beschikbaar moet zijn, enzovoort. Zonder goede afspraken tussen alle afdelingen is dit onbegonnen werk. SOA gaat hier al een heel stuk verder dan SOI (serviceoriented integration), een verschil dat sommige bedrijven vaak niet helemaal begrijpen.’
Maar daar houdt het nog niet op: er moeten ook goede afspraken gemaakt worden rond het gebruik van deze diensten, vervolgt Armando: ‘Als je software afkomstig van een bepaalde afdeling ter beschikking stelt als dienst voor het hele bedrijf, wie is dan verantwoordelijk voor het onderhoud, het versiebeheer en de levenscyclus van deze dienst? Hoe factureer je voor het gebruik van deze diensten? Welke machtigingsregels gelden voor het gebruik van een dienst? En hoeveel gebruikers mogen deze dienst maximaal tegelijk gebruiken voor de software het laat afweten? Zodra je van de pilootfase overschakelt naar de bedrijfsbrede fase, word je met al deze vragen geconfronteerd. En zonder volledig antwoord, loopt het vroeg of laat goed fout.’
Maar het goede nieuws is dan weer dat achteraf IT governance eenvoudiger wordt dankzij SOA. Armando: ‘Vooral het monitoren van de beschikbare assets wordt achteraf een heel stuk eenvoudiger, omdat alles in kaart is gebracht voordat het als service kan worden aangeboden. Maar het wordt vooral SOA en governance: de ene hype kan niet klant aan’ is complexer dan het lijkt,’ waarschuwt Armando, ‘iedereen moet het eens zijn over de definitie van ‘klant’, welke informatie beschikbaar moet zijn, enzovoort. Zonder goede afspraken tussen alle afdelingen is dit onbegonnen werk. SOA gaat hier al een heel stuk verder dan SOI (service oriented integration), een verschil dat sommige bedrijven vaak niet helemaal begrijpen.’
Maar daar houdt het nog niet op: er moeten ook goede afspraken gemaakt worden rond het gebruik van deze diensten, vervolgt Armando: ‘Als je software afkomstig van een bepaalde afdeling ter beschikking stelt als dienst voor het hele bedrijf, wie is dan verantwoordelijk voor het onderhoud, het versiebeheer en de levenscyclus van deze dienst? Hoe factureer je voor het gebruik van deze diensten? Welke machtigingsregels gelden voor het gebruik van een dienst? En hoeveel gebruikers mogen deze dienst maximaal tegelijk gebruiken voor de software het laat afweten? Zodra je van de pilootfase overschakelt naar de bedrijfsbrede fase, word je met al deze vragen geconfronteerd. En zonder volledig antwoord, loopt het vroeg of laat goed fout.’
Maar het goede nieuws is dan weer dat achteraf IT governance eenvoudiger wordt dankzij SOA. Armando: ‘Vooral het monitoren van de beschikbare assets wordt achteraf een heel stuk eenvoudiger, omdat alles in kaart is gebracht voordat het als service kan worden aangeboden. Maar het wordt vooral veel eenvoudiger omdat een goede servicegerichte architectuur volledig is gebaseerd op standaarden, wat het onderhoud en beheer heel wat eenvoudiger maakt.’ Als belangrijkste standaarden noemt Armando hierbij: WSDL, WS-Security, WS-Transaction maar ook BPEL, XML en JMS. Maar op semantisch vlak is er nog heel wat standaardiseringwerk aan de winkel.
SOA KAN JE NIET KOPEN
Ezio Armando windt er geen doekjes om: de weg naar een volledige, volwaardige SOA is lang en hobbelig. Te meer omdat u (voorlopig) weinig of geen steun moet verwachten van de softwareleveranciers. ‘Veel softwareleveranciers misleiden, al dan niet bewust, hun klanten door SOA op hun softwaredoos te schrijven.
Klanten denken dan dat ze al een servicegerichte architectuur hebben als ze bijvoorbeeld een degelijke XML tool in huis hebben. Maar een SOA kan je niet kopen, je kan enkel de architectuur bouwen met zo veel mogelijk herbruikbare componenten, met uiteindelijk specifieke bedrijfsobjectieven voor ogen.’ ‘Bovendien zijn de meeste softwareleveranciers nog helemaal niet klaar voor de nieuwe realiteit die SOA met zich meebrengt,’ merkt Armando op, ‘de ITinfrastructuur is niet meer opgebouwd rond verticale toepassingen maar rond bedrijfsprocessen.
Deze radicaal nieuwe manier van denken brengt heel wat softwarebouwers in de problemen, want zij willen nog altijd producten verkopen in plaats van processen.’
