ADM Blue paper: Confrontatie tussen theorie en realiteit
SOA: what’s in a name? Voorbeelden en conclusies uit de ADM werkgroep SOA (2009)
Inhoudsopgave Inhoudsopgave .................................................................................. 2 Inleiding ........................................................................................... 3 PRAKTIJKVOORBEELDEN ..................................................................... 5 1. Flexibele bekostiging Vlaams hoger onderwijs .................................. 5 2. Geautomatiseerde besluitvorming voor kredietverstrekkers ............... 6 3. Geen SOA naar de letter van het woord, wel alle voordelen ervan....... 7 4. Kredietwaardig in drie seconden ..................................................... 8 5. SOA in de mode ........................................................................... 9 6. Een derde bespaard dankzij straight through processing-methodiek ...10 CONCLUSIES ....................................................................................12 Top-down volgens het boekje, in de praktijk eerder bottom-up .............12 Full option of eerder SOA light ? ........................................................13 Wanted: alive .................................................................................13
2
Inleiding Met een servicegeoriënteerde architectuur of SOA kunnen organisaties hun computersystemen gemakkelijker laten communiceren met elkaar, via een netwerk of het internet. In dat communicatieproces fungeren webservices als bedrijfstolk. Omdat informaticasystemen zo beter geïntegreerd zijn, is efficiëntie- en tijdwinst mogelijk in de organisatie van de processen van een onderneming. Gebruikers krijgen ook meer grip op hun bedrijfsprocessen en hebben hun applicatiebeheer beter onder controle. De belangstelling voor serviceoriëntatie is dan ook groot. Maar is SOA ook zaligmakend? Een werkgroep van ADM boog zich over de vraag. De conclusies leest u in dit document. SOA leek alleszins de logische stap in de parallelle evolutie van softwareontwikkeling en bedrijfsprocesbeheer. Dankzij het concept van de serviceoriëntatie konden bedrijven hun informatica voortaan afstemmen op hun zakelijke processen en strategieën. Toch is SOA door sommigen alweer dood verklaard. Onder meer volgens het Amerikaanse onderzoeksbureau Gartner is SOA sterk op zijn retour. Dat komt in grote mate omdat er nogal wat terminologische onenigheid bestaat. Ook wat betreft de concrete invulling van SOA verschillen de specialisten van mening. Sommigen spreken over procesbeheer en systeemintegratie, respectievelijk business process management en enterprise application integration. Anderen zien er geen business case in. En er zijn er die menen dat SOA zal evolueren naar event driven architectures of alleszins de voorloper is van cloud computing. Ook in de academische wereld is er geen algemene, geijkte definitie van soa. Voor ADM het signaal om de Belgische IT-industrie samen te roepen voor een achttal workshops. Daarmee trachtten we tot een consensus te komen over definitie en invulling van de servicegeoriënteerde architectuur. Uit de workshops blijkt dat serviceoriëntatie springlevend is. De grotere ITbedrijven blijken SOA op een gelijklopende en bovenal pragmatische manier aan te pakken. Het model van Michael Papazoglou met een zakelijke, logische component op het infrastructurele, fysische luik werd door de werkgroep algemeen aanvaard als het standaardmodel voor servicegeoriënteerde architecturen. Parallel concludeerde men dat serviceoriëntatie onmogelijk kan losgekoppeld worden van procesbeheer. Voor die koppeling bestaan verschillende, zogenaamde maturiteitsmodellen. Welke van die bestaande modellen we best volgen, verschilt naargelang van het project en de behoeften van de onderneming. De werkgroep definieerde alvast acht standaardcriteria voor servicegeoriënteerde architecturen. 1.
Zijn de bedrijfsprocessen vastgelegd aan de hand van een Business Process Model (BPM)?
2.
Zijn de services in de architectuur ontwikkeld op basis van die zakelijke processtappen (business processes)?
3
3.
Zijn de services ontwikkeld op basis van bestaande gegevensuitwisselingen (entiteiten of data access) ?
4.
Is er een specifiek systeem gekozen voor het beheer van het BPMmodel, de SOA of de ESB (enterprise service bus) ?
5.
Is er een systeem in gebruik om de services volgens dezelfde systematiek uit te tekenen, te ontwikkelen en integreren (service provider)?
6.
Is er een toepassing ontwikkeld om de services op te roepen (service consumption)?
7.
Zijn er regels vastgelegd voor monitoring en operationele rapportering van de services (governance)?
8.
Is er een standaard vastgelegd voor de voorstelling van de webservices (unieke gegevensinterface volgens het zogeheten ‘canoniek’ datamodel)?
De werksessies streefden in eerste instantie naar een gemeenschappelijk standpunt over SOA. Of dat gelukt is, verneemt u in het laatste hoofdstuk van dit document. De werkgroep onderzocht tegelijk of SOA nog wel een bestaansreden heeft en zo ja, in welke vorm. Bovenstaande SOA-criteria hebben we getoetst aan zes Belgische praktijkvoorbeelden. Daaruit leren we alvast dat SOA zeker geen big bang hoeft te zijn, maar dat serviceoriëntatie even goed kleinschalig van start kan gaan.
4
PRAKTIJKVOORBEELDEN 1. Flexibele bekostiging Vlaams hoger onderwijs Het inschrijvingsgeld aan de Vlaamse universiteiten en hogescholen is relatief laag voor de student. De overheid past via subsidiëring aan de instellingen bij. Om het onbeperkt blijven studeren en herkansen op kosten van de belastingbetaler te beperken, riep de Vlaamse overheid in 2008 het leerkrediet in het leven. Dat is een hoeveelheid studiepunten die een student mag vergaren om als subsidieerbaar student beschouwd te blijven. Met de invoering van het systeem zocht de Vlaamse overheid naar een manier om de doorlooptermijn van alle studenten sneller te registreren. Een telling aan het begin van het academiejaar en een aan het einde van de rit, volstaat in het huidige regime niet langer. Er is immers een dagelijkse wijziging mogelijk van het leerkrediet door nieuwe in- of uitschrijvingen. Samen met partners EDS en Telindus zocht de overheid naar een systeem waarmee de 28 instellingen van het Vlaamse hoger onderwijs sneller en frequenter kunnen informeren over de individuele studietrajecten, in het kader van de studententelling. Die gegevensuitwisseling organiseert men vandaag via webservices. De informatie op de back-endsystemen van de instellingen wordt doorgestuurd via een servicegeoriënteerde architectuur naar de IBM-mainframes van de overheid, die leerkredieten en studiepunten automatisch herberekenen. Elk van de instellingen voor hoger onderwijs had een certificaat nodig voor een beveiligde communicatie via webservices. EDS en Telindus bouwden webservices voor de inschrijvingen, en ook voor de resultaten van de studenten, enzovoort. Elke instelling integreerde de webservices op eigen ritme met haar architectuur. Omdat sommige instellingen hun systemen moesten aanpassen aan de standaard webservices, duurde het project wel iets langer dan verwacht. De interfaces, standaarden voor de uitwisseling van de webservices en rapportage waren decretaal vastgelegd. Per academiejaar gaan er miljoenen zogenaamde webservice calls van de instellingen naar de overheid. Per academiejaar gaan
Niet alleen krijgt de overheid de nodige informatie veel sneller, de informa-
er miljoenen ‘webser-
tie zelf is ook rijker. Met de geautomatiseerde webservices moeten er min-
vice calls’ van de in-
der documenten aan de overheid bezorgd worden. Zo hoeft de student
stellingen naar de
geen attesten voor kinderbijslag meer te bezorgen aan de kinderbijslag-
overheid.
fondsen. Die hebben een dergelijk attest nodig om kinderbijslag te blijven toekennen aan meerderjarige studenten. De overheid kan de studenten
Johan Bruynseels, HP
sneller en correcter kwantificeren, een absolute noodzaak voor de flexibele
Enterprise Services
bekostiging van het hoger onderwijs.
(EDS) Technisch kunnen we besluiten dat de webservices werden gebouwd op basis van de bestaande gegevensuitwisseling en niet op basis van de processen. Ook selecteerde de Vlaamse overheid een certificate server. De webservices melden zich aan op de server, zodat de overheid de instelling kan identificeren. De webservices ontwierp de overheid volgens dezelfde systematiek, zodat men snel kan inspelen op nieuwe behoeften. EDS en
5
Telindus ontwikkelden ook een service consumption-toepassing waarop de instellingen zich kunnen baseren voor de integratie van de services in hun toepassingen. Ten slotte bepaalde men ook vooraf hoe de verschillende entiteiten in webservices moesten gestandaardiseerd of gepresenteerd worden. Daarmee beantwoordt het project aan vijf van de acht SOA-criteria van de werkgroep.
2. Geautomatiseerde besluitvorming voor kredietverstrekkers We denken bij leasing voornamelijk aan gebouwen, wagens of computers. Leasingbedrijven nemen echter ook kleiner kantoormateriaal op in hun aanbod. Om de administratieve kost van deze kleinere contracten zo laag mogelijk te houden, moet de beslissing van kredietverstrekking sneller en dus goedkoper kunnen. Enkel via een automatische kredietgoedkeuring kunnen leasebedrijven ook kleinere assets leasen. Daarbij moet de beslissing wel perfect getraceerd kunnen worden, om de vigerende wet- en regelgeving te kunnen naleven (ook wel ‘compliance’ genaamd) . IT-dienstverlener Spikes ontwikkelde voor deze kredietbeslissing een softwaredienst op basis van webservices. Brokers, die de diensten van leasemaatschappijen aan de man brengen, controleren aan de hand van een website of ze aan een bepaalde klant een krediet kunnen verlenen voor een bepaald product. Die automated decision engine webservice verzamelt een reeks gegevens van de klant en toetst ze aan een regelset. Nadien kan de automated decision engine het krediet toekennen of weigeren, of beslissen dat de kredietaanvraag manueel moet worden verwerkt. De webservice controleert onder meer via de databank van Graydon of de leaseaanvrager kredietwaardig is. Die enkelvoudige controles zorgen mogelijk voor extra kosten. Het beslissingmechanisme houdt daar rekening mee. Marc Vanderheyden van Spikes raadt daarom aan vooraf, naast alle mogelijke processtappen, ook de kosten in kaart te brengen voor een optimalisatie. En net als de andere praktijkvoorbeelden moest Spikes ook rekening houden met de geldende wet- en regelgeving (compliance), want om in België de kredietwaardigheid van een bedrijf te controleren in de Kredietcentrale van de Nationale Bank, moet je erkend zijn als kredietinstelling. Zeventig tot tachtig
Tussen 70 en 80% van de kredietaanvragen voor kleine tickets wordt nu
procent van de
automatisch behandeld. Met de zogenaamde rule engine automatiseert
kredietbeslissingen
Spikes in één stap een volledig manueel werkproces. Bovendien is de klant
verlopen nu
zeker dat alle regels die in het manuele proces gecontroleerd moeten wor-
volautomatisch. -
den, nu ook effectief gecheckt worden.
Marc Vanderheyden,
Bovendien haalt Spikes bij bepaalde verstrekkers, zoals Graydon, minder
Spikes
informatie op in vergelijking met vroeger. Immers, voor de automatische beslissing is, om maar iets te noemen, niet alle financiële informatie nodig van een kredietaanvrager. De beslissing kan evengoed genomen worden op
6
basis van enkele belangrijke gegevens. SOA maakt de datavergaring dan ook intelligent en efficiënt. De orchestratie van de automatische beslissing gebeurt via Microsoft BizTalk Server. De menselijke tussenkomst in het proces is met behulp van Windows Workflow Foundation georganiseerd. Spikes zorgde voor een open architectuur zodat die makkelijk kan mee evolueren met nieuwe gegevens, nieuwe serviceverleners of –afnemers. In tegenstelling tot de andere praktijkvoorbeelden beantwoordt het project van Spikes aan alle acht de criteria die de werkgroep vooropstelde.
3. Geen SOA naar de letter van het woord, wel alle voordelen ervan De bedrijfsactiviteiten van Fluxys zijn na de liberalisering volledig veranderd. Het bedrijf verkoopt niet langer gas, maar transportdiensten. Met het nieuwe commerciële model ontstond ook de nood aan een nieuwe informatica-aanpak. Voor 2003 programmeerde de IT-afdeling van Fluxys in allerhande talen, en was er weinig of geen sprake van applicatieve integratie. Gebruikers moesten twee tot drie keer dezelfde gegevens invoeren in Access-, Excel- of Oracle-databanken. In 2003 hebben ze daarom een volledig (nieuw) businessmodel uitgeschreven. Om de nieuwe organisatie beter te ondersteunen, vernieuwde en standaardiseerde Fluxys zijn technische architectuur met .NET- en C#-applicaties. Tegelijk bracht Fluxys zijn nieuwe zakelijke processen volledig in kaart. Voor het gastransport van punt A naar B zijn er bijvoorbeeld verschillende stappen. Voor elke grote tussenstap ontwikkelde de organisatie een gebruikersapplicatie. Die systemen moeten continu met elkaar communiceren. Fluxys had dus nood aan een groot gemeenschappelijk overzicht (common view) over al die systemen heen. Er zijn immers verschillende systemen voor het contact met de leverancier, de gas flow manager van Fluxys, de opdrachtgever, de meetafdeling, enzovoort. Toch gebruiken die allemaal in zekere zin dezelfde gegevensset. De applicaties hebben tal van gegevens nodig van andere software. Om er toch voor te zorgen dat er slechts een enkele versie van de waarheid is, controleert Oracle-software de referentiële integriteit van de informatie. Loose coupling was de
Vandaag beschikt Fluxys over een zelf ontworpen architectuur waarbij ap-
sleutel van ons
plicaties heel wat informatie kunnen recycleren van elkaar, zodat de ge-
architectuurmodel.
bruikers geen onnodig overtypwerk moeten doen en er dus ook minder kans op fouten is. Volgens Johan Van Damme van Fluxys ligt de sleutel van
Johan Van Damme -
dat succes in de loose coupling van de verschillende systemen via interfa-
Fluxys
ces. Fluxys gebruikt hetzelfde architectuurmodel nu ook voor zijn terminalling- en stockageactiviteiten. Daarbij kon het grotendeels de code hergebruiken van de architectuur voor zijn commerciële gastransportactiviteiten.
7
De moeilijkste oefening bestond erin een gezamenlijke common view of definitie van de zakelijke objecten te maken voor de verschillende afdelingen. Van Damme geeft toe dat, strikt gezien, de architectuur geen traditionele serviceoriëntatie via webservices kan voorleggen. Echter, in wezen geniet Fluxys wel dezelfde voordelen die een SOA-architectuur biedt. De technische invulling van de communicatie binnen de architectuur bleek voor Fluxys in eerste instantie minder belangrijk. Toch voldoet Fluxys’ huidige architectuurmodel al aan zes van de acht oorspronkelijke SOA-criteria van de werkgroep. Zo schakelt het bedrijf stap voor stap over naar webservices.
4. Kredietwaardig in drie seconden De bepaling en de uitvoering van zowel het nationale als het Europese monetaire beleid behoren tot de kerntaken van de Nationale Bank van België. Daarnaast speelt de Nationale Bank een belangrijke rol bij het financiële informatiebeheer in België, en organiseert ze het interbancaire betalingsverkeer. Ook levert de Nationale Bank belangrijke diensten aan financiële instellingen, onder meer voor kredietcontrole. Bij de aanvang van het decennium zette de NBB twee initiatieven op de werkplank om de kwaliteit en snelheid van zijn dienstverlening te verbeteren. Voornamelijk wilde de NBB meer automatisering stoppen in de dagelijkse verwerking van de vier miljoen interbancaire betalingen. Ook kredietcontroles voor privépersonen in het kader van leasing- of hypotheekaanvragen moesten sneller. De NBB had in 2001 immers steeds meer problemen met de inefficiënte en trage menselijke interfacing tussen de binnenkomende datacommunicatie en de mainframesystemen die in silo’s draaiden. Bovendien verplichtte de Belgische regering de nationale bank meer informatie te verstrekken over particuliere kredieten, leningen en hypotheken. Financiële instellingen kunnen voortaan online de kredietwaardigheid van particulieren controleren, er bestaat niet langer een zogenaamde zwarte lijst. Daarvoor introduceerde de NBB samen met adviseur Accenture een nieuw, open architectuurmodel voor een snellere, veiligere gegevensuitwisseling en een verlaagd operationeel risico. Centraal in de nieuwe IT-architectuur staat webMethods, software voor de ontwikkeling en het beheer van servicegeoriënteerde architecturen. Andere componenten zijn onder meer Entrust (PKI-technologie), Netegrity SiteMinder en Sun iPlanet Directory Server. Jean-Michel Ghyoot van Software AG meldt dat men in 2001 evenwel nog niet echt sprak van SOA zoals we die vandaag definiëren. De NBB wilde echter wel een soort van services implementeren voor de communicatie tussen de mainframes en financiële instellingen. Sinds de ontwikkeling van
8
die services kunnen commerciële ondernemingen volwaardige kredietcontroles uitvoeren voor privépersonen via de Centrale voor kredieten aan particulieren. De SOA van de NBB
Bij de bouw van deze SOA ‘avant-la-lettre’ wilde de NBB vooral vermijden
verwerkt minstens
dat de consumers zelf webservices zouden moeten bouwen. Alle financiële
300.000 krediet-
instellingen die een beroep doen op de geautomatiseerde real-time krediet-
aanvragen per dag,
controle, gebruiken de (web)service van de NBB. Wanneer een financiële
naast andere
instelling de kredietwaardigheid van een particulier wil controleren, vertrekt
transacties.
de kredietaanvraag via de SOA-servicebus naar de mainframe om via dezelfde weg terug te keren met de gewenste informatie. Die volledige opera-
Jean-Michel Ghyoot,
tie mag hooguit drie seconden duren. Dagelijks zijn er tot 300.000 van
Software AG.
dergelijke aanvragen. Welke tips moeten we uit dit gebruikersverhaal onthouden? Vooreerst raadt Software AG aan om het investeringsrendement permanent in de gaten te houden. De kloof tussen de tactische denkwijze van de zakelijke beslissingnemers en de architecturale aanpak van de informaticaspecialisten is immers groot. Klein beginnen, de SOA geleidelijk uitbreiden en bovenal de dingen onder controle houden, luidt het advies. Het is een van de redenen waarom Software AG en Accenture voor een graduele aanpak kozen. Zo kwam de algemene procesautomatisering pas in een tweede fase aan bod.
5. SOA in de mode Omwille van het open, conceptuele model en de schaalbare voordelen vindt SOA ingang in tal van sectoren. Zo ook in de modewereld. Adviseur Bizliner begeleidde recent een modehuis met vertakkingen in 100 landen bij de overgang naar zo’n servicegeoriënteerde architectuur. Een en ander moest de recente integratie van de beheersoftware SAP vereenvoudigen. Serviceoriëntatie zou het modehuis helpen om de operationele bedrijfsdata beter in te zetten bij de strategische beslissingen. Naast SAP schakelde het modehuis immers ook mainframesystemen in voor het algemeen dagelijks bedrijfsbeheer, evenals enkele tienduizenden Excelwerkbladen met bedrijfsinformatie. Opdracht nummer één voor Bizliner was dus het stroomlijnen van die zakelijke informatie. Daarvoor definieerde het eerst alle business objects. Een voorbeeld: hoe moet de omzet berekend worden, en hoe kan het modehuis die lokale omzet in alle landen op dezelfde manier laten berekenen? Op vraag van de CEO van het modehuis maakte Bizliner een common view van de zakelijke informatie en technische data. Die common view brengt de bedrijfsprocessen in kaart en koppelde ze aan de trafiek van de operationele data naar de beheersystemen. Door de business objects te verenigen met de operationele datatransfers of service data, is verbetering van de bedrijfswerking mogelijk. Er komt immers een functionele brug tussen de oude silo’s: informatica en business.
9
Dankzij de nieuwe
Alle systemen worden nu op basis van deze nieuwe common view geïm-
common view kon men
plementeerd. Dankzij deze oefening kon het modehuis zijn bedrijfsproces-
sommige bedrijfs-
sen vereenvoudigen en soms met de helft inkorten. Volgens Dominique
processen met de helft
Scheuren van Bizliner speelde de cultuur van het bedrijf daarbij zeker een
inkorten
rol, omdat elk land op ongeveer dezelfde manier werkt, met dezelfde taal. Dankzij de nieuwe common view kon het modehuis overstappen naar een
Dominique Scheuren,
ander en goedkoper datawarehouse. Daarmee kon het liefst 750.000 dollar
Bizliner
besparen. Dankzij de nieuwe omgeving kan het modehuis zijn strategische beslissingen meer funderen. In het verleden was de informatie vaak incoherent, omdat de verschillende componenten van de SOA-architectuur in silo’s werkten. Vandaag is er een transversaal informatiebeheer waardoor men echt kan spreken over business intelligence. De belangrijkste les uit dit praktijkverhaal is dat in het kader van SOA-projecten de grootste winst gemaakt wordt als je de webservices koppelt aan je bedrijfsprocessen.
6. Een derde bespaard dankzij straight through processingmethodiek Vele ondernemingen nemen ze op in hun salarispakket, vanwege het extralegale voordeel: de groepsverzekering kende de voorbije jaren een steile groei. Ook verzekeringsbedrijf Vivium kende na de eeuwwisseling die forse groeispurt. Alleen gold: hoe meer verzekerde werknemers of deelnemers Vivium binnenhaalde, hoe meer interne medewerkers er op de dienst operations nodig waren voor de verwerking van al die nieuwe dossiers. Voor de berekening van een groepsverzekering moet Vivium immers tal van informatie verwerken in zijn systemen. Meer procesefficiëntie drong zich op. De informatica-afdeling overtuigde de directie om de informatieverwerking om te gooien, en introduceerde de methodiek van straight through processing. Bij die dataverwerking is er geen menselijke tussenkomst meer nodig. Vivium bouwde een servicegeoriënteerde architectuur op basis van het drielagenmodel voor de presentatie van de gegevens, de bedrijfsprocessen en de data zelf. Dat model is vooral van nut als je data van verschillende bronnen afkomstig is en in verschillende dataformaten geleverd wordt. Vivium krijgt data vanuit vele hoeken: het eigen intranet, sociale secretariaten, het internet voor werkgevers en makelaars en ten slotte ook de kruispuntdatabank. De datacommunicatie tussen die systemen en de eigen, achterliggende COBOL-mainframes verloopt nu via services. De MQ Series-middleware is een soort van trechter die de informatie opvangt en verwerkt in de eigen systemen. Dat heeft als voordeel dat Vivium de gewijzigde of nieuwe verzekeringgegevens rechtstreeks kan laten registreren door de partners. De middleware zorgt ervoor dat de gegevensinput automatisch verwerkt wordt bij Vivium.
10
Ook als de wetgeving ter zake verandert, of Vivium zijn verzekeringsproducten wijzigt, moet de informaticadienst enkel nog de services wijzigen. Vroeger moesten er dan heel wat softwareprogramma’s aangepast worden. In het verleden gebeurde de gegevensinput immers via het intranet, maar ook via een dertigtal maatwerkinterfaces die Vivium draaide bij een aantal grote Belgische werkgevers. Dankzij onze SOA
Dankzij de intrede van de serviceoriëntatie is al het maatwerk intussen
konden we heel wat
weggevallen. Daarmee realiseerde Vivium een kostenbesparing van meer
manuele input
dan 30%. Niet alleen moeten bij wijzigingen enkel nog de services aange-
automatiseren, goed
past worden, door de automatisering via SOA kon Vivium heel wat beheer-
voor 30% kosten-
ders een andere functie aanbieden. Zo bereikte de verzekeraar het oor-
besparing
spronkelijke doel van de soa: de klantengroei is niet langer rechtevenredig met de personeelsgroei.
Wim Van Mol, Vivium Naast die interne winst is er ook een interessant voordeel voor de klanten. Vroeger had Vivium soms een achterstand van twee tot drie maanden bij de verwerking van de verzekeringsgegevens. Dankzij de automatisering worden wijzigingen nu binnen de twee dagen doorgevoerd. De klant krijgt onmiddellijk zijn benefit statement, de stand van zaken van zijn groepsverzekering. Voor Wim Van Mol van Vivium was het bovenal belangrijk om de architectuur goed en gedetailleerd in kaart te brengen, en zich er vervolgens strikt aan te houden. Daarom werkt Vivium met een service owner, die de services beheert. De groepsverzekeraar vermijdt zo applicatiewildgroei als gevolg van ontwikkelaars die services op hun eigen manier programmeren. Er is voortaan slechts één versie van de waarheid. Ten slotte beantwoordt dit project aan niet minder dan zeven van de acht vooropgestelde criteria van de werkgroep. Enkel de serviceontwikkeling op basis van data is niet van toepassing. Daarmee vormt dit project bijna het voorbeeld bij uitstek van hoe het moet.
11
CONCLUSIES Dat SOA een belangrijke trend is in de huidige bedrijfsinformatica, kunnen we wel concluderen uit de werksessies. De werkgroep heeft vrijwel alle invalshoeken van het SOA-paradigma nader bekeken. Het bleef zeker niet bij een summier overzicht van de zakelijke aanpak of de technologieën. Men stond evenzeer stil bij de integratiemodellen en het architectuurbeheer. De werkgroep heeft getracht SOA te vertalen voor ondernemingen en ADM-leden, zowel vanuit zakelijk als technisch perspectief. Door die kennis te delen zal de industrie ook beter presteren, meent de werkgroep. Een SOA bouw je niet alleen met wat nieuwe technologieën en interfaces tussen bestaande toepassingen. Het is een open architectuurmodel dat toelaat om de informaticaprocessen makkelijker af te stemmen op de zakelijke bedrijfsprocessen. Daarvoor moeten we de bestaande applicatiearchitecturen omgooien, luiden de theorieën, omdat kleine, oppervlakkige systeemintegratie niet leidt tot spectaculaire voordelen. Ook in de werkgroep is men het eens dat een grote common view (waarbij men de zakelijke processen koppelt aan datatransfers) de basis is voor SOA.
Top-down volgens het boekje, in de praktijk eerder bottom-up Uit de praktijkvoorbeelden blijkt dat we in België nog in een vroeg stadium van SOA zitten. Belgische bedrijven voeren SOA inderdaad niet kamerbreed in. De meeste SOA-projecten gingen al wel van start, maar worden nog selectief toegepast volgens concept of technologie. Men werkt bij ons in de meeste gevallen vanuit de automatisering van de datatrafiek om de voorziene efficiëntiewinst te boeken (bottom-up). Toch is de werkgroep van mening dat de grootste efficiëntiewinst geboekt wordt als men de automatisering organiseert vanuit de bedrijfsprocessen (top-down), op basis van een common view. Net als bij andere informaticamodellen of –technologieën moest SOA zorgen voor flexibiliteit, data-integratie en kostenbesparing. Inhoudelijk geeft iedereen het model een andere definitie: voor sommigen zijn het webservices, voor anderen interfacing via het internet. Ook binnen de werkgroep bestond er daarover wat onenigheid. Een geijkte definitie en dito technische invulling was evenwel minder belangrijk voor de deelnemende informaticabedrijven. De groep heeft het liever over serviceoriëntatie, met als doel een zo groot mogelijke procesverbetering. Maar de business heeft weinig aan wat services die je aan elkaar lijmt. De serviceoriëntatie moet de dienstverlening van het bedrijf optimaliseren. Serviceoriëntatie moet een bedrijf flexibiliteit en een sneller reactievermogen opleveren, tegen een aantoonbaar investeringsrendement. En of dat via SOA-, -B of -C gebeurt, is onbelangrijk. Uit het voorbeeld van Fluxys merkte de werkgroep dat een efficiënt architectuurmodel gebouwd kan worden zonder traditionele webservices. Ook uit academische hoek hoorden we dat men de oude principes vooral niet overboord mag gooien. Dat geldt zeker ook voor SOA. Het is niet omdat we nu
12
spreken over xml-services dat voorgaande modellen niet meer van toepassing kunnen zijn.
Full option of eerder SOA light ? In de Belgische praktijk blijkt dat de eerste toepassingen van SOA eerder voortvloeien uit alleenstaande acties dan uit een algemene bedrijfsaanpak met enterprise service bus. Liggen theorie en praktijk dan ver uit elkaar? In de realiteit heeft de praktijk altijd wat vertraging op de theorie. Het loont niet altijd de moeite om alles meteen door te trekken. Je kunt een SOA zeker geleidelijk aan bouwen, op basis van de entiteiten (data), om in een latere fase de processen te automatiseren die de services gebruiken. Ook dan ligt efficiëntiewinst binnen handbereik, zeiden we hierboven al. Bestaat er dan geen volwaardige servicegeoriënteerde architectuur? Toch wel: het voorbeeld van Spikes beantwoordde bijvoorbeeld aan alle criteria. Bovendien heeft het raakpunten met de case van de Nationale Bank. De processen gaan over de grenzen van de organisaties heen. Als je systemen communiceren met de buitenwereld, kan SOA duidelijk een goed hulpmiddel zijn.
Wanted: alive Volgens de Burton Group is SOA dood, maar leeft het principe verder in de vorm van serviceoriëntatie. Hoewel de ADM-praktijkverhalen vaak een light-versie zijn van de SOA volgens het boekje, ze tonen aan dat ondernemingen nood hebben aan gedeelde services, gedeelde vaardigheden en gedeelde bronnen. Zonder serviceoriëntatie kunnen we ook geen basis leggen voor software-as-a-service en cloud computing, de toekomst van softwaredienstverlening. Je kunt je applicatie niet naar de cloud verhuizen als je er niet voor zorgt dat ze integreerbaar is met andere systemen, zowel interne als externe. Het debat hierover is dus zeker niet gedaan. Met deze whitepaper wil ADM de neuzen alvast in dezelfde richting brengen, zodat we onze applicatiearchitecturen beter kunnen organiseren, op maat van toekomstige systeemmodellen. Serviceoriëntatie, op welke manier dan ook, leidt tot efficiëntere en betere bedrijfswerking. En elk bedrijf wil zijn zakelijke processen optimaliseren en het juiste aantal toepassingen inschakelen om die processen te ondersteunen. Het alternatief is dat geen van je applicaties met elkaar verbonden zijn. En dan zitten je processen ook niet goed. Eindconclusie: het principe van de SOA is duidelijk niet dood.
13
Met dank aan alle deelnemers aan de ADM werkgroep SOA, vooral HP Enterprise Services (EDS) en Microsoft voor de coördinatie ervan.
© ADM 2010 www.adm.be
14
