evaluatie SOA t SOA in functioneel-beheerperspectief Een herbezinning op beheer Er wordt veel gepubliceerd over servicegeoriënteerde architecturen, vaker SOA genoemd (naar de Engelse term service-oriented architecture ). Het functioneel beheerperspectief ontbreekt meestal. De auteurs brengen dit vanuit een praktijksituatie in kaart. De belangrijkste les is dat de introductie van SOA dwingt tot een herbezinning op beheer. Richard Feringa, Norbert Huijzer en Hans Tönissen De belofte Via een ambitieus veranderprogramma wordt SOA geïntroduceerd in een organisatie. De beloftes van het programma zijn niet mis: samenwerking tussen bestaande en nieuwe applicaties, hergebruik van functionaliteit waarbij SOA als koppelmethode dient, een procesmatige benadering voor de bedrijfsvoering waarbij SOA als overkoepelend (diensten)model fungeert, de ICT-infrastructuur wordt in dienst gesteld van de processen en het beheer en onderhoud van bedrijfsprocessen en ICT kan snel worden uitgevoerd met minimale inspanningen en verstoringen. Het grote vertrouwen van het programma in de maakbaarheid van business en techniek blijkt echter te vroeg te komen. De business is nog niet gereed voor procesmatig werken (laat staan servicegeoriënteerd), ketenpartners hebben hun samenwerking niet juridisch geborgd, te koppelen systemen en gegevens blijken niet zo herbruikbaar, SOA-integratiecomponenten zoals het business process management-systeem en het workflowsysteem werken niet vlekkeloos samen, consultants van leveranciers blijken eigenlijk verkopers, de ICT-infrastructuur is toch niet zo toepasbaar voor een op open standaarden gebaseerde SOA en de beheerorganisaties komen niet uit het vraagstuk wie nu eigenaar van wat is. Het veranderprogramma heeft te veel hooi op zijn vork genomen. Behalve voor klassieke projectrisico s zoals werken met aannames over haalbaarheid en maakbaarheid en het voorbijgaan aan irrationele zaken (mensen), pretendeerde het programma een oplossing te bieden voor zowel het business-, technologie- als beheerperspectief. Op het laatste, het functioneel beheerperspectief, gaan we hier nader in. SOA in vogelvlucht Veel bedrijven adopteren de servicegeoriënteerde architectuurstijl met het idee meer flexibiliteit in de bedrijfsprocessen en de bijbehorende informatieverwerking te realiseren. Van SOA doen veel definities de ronde, die allemaal op ongeveer hetzelfde neerkomen: SOA is een architectuur 36
Samenvatting Bij SOA verschuift de focus van interne bedrijfsprocessen naar processen die zich over de afdelings-, organisatie- en systeemgrenzen heen strekken. Vooral de serviceprovider zal een belangrijke rol spelen. Functioneel beheer, als serviceprovider van business- en functionele services, zal moeten bepalen welke processen, processtappen en services hij wil onderhouden en beheren. Deze keuze, en ook de te verwerken hoeveelheden, bepaalt de interne structuur van functioneel beheer. organisatie afdeling werkproces bedrijfsservice logisch informatiesysteem applicatieservice Figuur 1. Relatie tussen architectuurcomponenten bedrijfsfunctie bedrijfsproces het flexibel inrichten van uitwisselingsprotocollen zodat organisaties zelf controle houden over de inrichting van hun eigen processen; uitbreidbare en aanpasbare functionaliteit van de dienstverlening via het toevoegen van additionele services; schaalbare technologie zodat de capaciteit van de infrastructuur snel en eenvoudig uitbreidbaar is. SOA is in eerste instantie een architectuurstijl. Het is een middel en geen doel. Om allerlei redenen proberen we de softwareleveranciers voorop er iets tastbaars van te maken. Maar SOA gaat over ontwerpen, over standaarden, over de relatie tussen aanbieder en leverancier, en dan pas over infrastructuur. die nuttige bedrijfscomponenten hergebruikt, zowel binnen als buiten de context van applicaties, afdelingen of organisaties. Aangezien een SOA afdelings- of zelfs organisatieoverschrijdend is, zal er rekening mee moeten worden gehouden dat bedrijfsfuncties en systemen van allerlei oorsprong aanzienlijke impact hebben. Figuur 1 geeft de relatie aan tussen een aantal architectuurcomponenten. Het is belangrijk dat de uitvoering van een bedrijfsservice, in veel gevallen een werkproces, volledig valt binnen een bedrijfsfunctie. Een logisch informatiesysteem loopt in het ideale geval een op een met een bedrijfsfunctie. Een bedrijfsproces loopt van klant tot klant en zal in het algemeen meerdere werkprocessen bevatten. SOA wordt in eerste instantie vaak gemodelleerd op de gegevensuitwisseling tussen organisatieonderdelen. Vanuit het perspectief van inrichten en beheer en het aansluiten van nieuwe ketens is het verstandig al rekening te houden met: het toepassen van open standaarden; het kunnen beschikken over managementinformatie; SOA in soorten en maten Dé SOA bestaat niet, er lijkt eerder sprake te zijn van een aantal scenario s. We onderscheiden er een vijftal, die helpen om het beheer van een SOA te plaatsen. De boodschap is: pas wanneer de basisgedachten achter een SOA zijn ingevuld, heeft het zin naar de hogere niveaus te streven. Let op: het is slechts een hulpmiddel, het betreft geen standaardtypologie, en ook zijn in de praktijk de grenzen niet zo scherp te leggen. Basis-SOA Een basis-soa kenmerken we als een softwarearchitectuur waarbij middelen in een netwerk als zelfstandige services beschikbaar zijn gesteld. Zo n service is te gebruiken zonder kennis van het platform waarop de service is geïmplementeerd (black-box services). Bij een basis-soa is een servicecatalogus beschikbaar. Voor functioneel beheer is het van belang om afspraken en standaarden overeen te komen om functionaliteit en gegevens uit onderliggende systemen via services beschikbaar te stellen en afhankelijkheden (tussen services) te beheersen. 37
evaluatie SOA t Open-standaarden-SOA Een open-standaarden-soa heeft als extra kenmerk dat services niet alleen binnen het eigen domein beschikbaar zijn, maar ook voor andere afdelingen of organisaties. De services zijn bij voorkeur generiek van aard, zodat ze kunnen worden toegepast voor verschillende informatiestromen. Doordat de services losse onderdelen vormen waaruit de processen zijn opgebouwd (er wordt ook wel gesproken van loosely coupled services ), is het mogelijk services te vervangen zonder dat de gebruikers daar al te veel hinder van ondervinden en zonder dat de processen wezenlijk veranderen. Dankzij dit kenmerk kunnen bestaande systemen worden ingezet, met als voorwaarde dat deze zich gedragen als services. Het is dan wel noodzakelijk dat partijen die gegevens met elkaar uitwisselen, dezelfde betekenis aan dezelfde gegevens toekennen. De serviceleverancier(s) en de servicegebruiker hebben ook vaak andere eigenaren. Hierdoor is het van belang om naast de functionele beheerorganisaties (voor ongedeelde voorzieningen zoals gegevensdefinitie en het procesverloop) een gemeenschappelijke beheerorganisatie in te richten en in stand te houden voor gedeelde voorzieningen zoals de procesinfrastructuur, de services en de technische infrastructuur. Voor functioneel beheer is het vooral van belang om afspraken en standaarden overeen te komen om processen in de vorm van flows te beschrijven en bedrijfsprocessen te beschrijven die services gebruiken. De beschikbare services dienen in een administratie te worden opgenomen. Publieke SOA Bij een publieke SOA wordt het open karakter verder versterkt: nu zijn ook portalen (naast systeemsysteemkoppelingen) en discovery (de gebruiker hoeft niet te weten door wie of waar een service geleverd wordt) belangrijk. De open standaarden (BPEL, SOAP, (EB)XML) zijn nu echt noodzakelijk. Het publiceren en beheren van services is nodig om kenbaar te maken wie welke services aanbiedt. Drie beheer- en juridische aspecten zijn hierbij van belang: 1. Wet- en regelgeving stelt in veel gevallen eisen aan de wijze waarop informatie-uitwisseling plaatsvindt. Voorbeelden van wetgeving zijn bescherming persoonsgegevens en elektronisch bestuurlijk verkeer. 2. Afhankelijk van de informatie en de keten waarbinnen de informatie wordt uitgewisseld, kan er sprake zijn van specifieke wetten, bijvoorbeeld de wet op de rijksbelastingen. 3. De juridische relatie tussen de gebruikers en de beheerorganisaties dient zorgvuldig te worden ingericht. De inrichtingskeuzes die worden gemaakt, kunnen onder meer van invloed zijn op eventuele aansprakelijkheden die uit de informatie-uitwisseling voortvloeien. Voor functioneel beheer is het vooral van belang dat de bovengenoemde aspecten geregeld zijn. Samengestelde SOA Bij de samengestelde of composite SOA kunnen services of bestaande applicaties samengesteld worden tot complexere services. Dit scenario lijkt op dit moment de norm te worden. De bedoeling is om top-down te werk te gaan: bedrijfsprocessen worden in componenten onderverdeeld, waarbij op het hoogste niveau business-services worden gedefinieerd die zijn opgebouwd uit steeds lagere services, die door basissystemen beschikbaar worden gesteld. Samengestelde services worden hierbij vanuit een business process management (BPM)-omgeving gedefinieerd en georkestreerd. Aan procesmodellering en functioneel beheer wordt dan de eis gesteld om hogere en lagere services te ontwerpen en te onderhouden. Om de processen in de SOA te beleggen beschikt de SOA dan over functionaliteit op het gebied van procesmodellering. De processen zijn opgebouwd uit meerdere processtappen die worden uitgevoerd door verschillende services. Wanneer nieuwe of gewijzigde processen worden belegd, kan systeemontwikkeling beperkt blijven tot het vaststellen van de procesgang en de wijze waarop de (herbruikbare) services moeten worden samengesteld en aangeroepen. 38
De ideale SOA Komt nu alleen nog voor in verkoopbrochures (en in projectplannen, zie de introductie). De ideale SOA biedt allerlei integrale beheer- en onderhoudsfaciliteiten die er met name op gericht zijn de betrouwbare werking en de productiviteit te verhogen. Denk aan inregelprocessen voor onderhoud/vernieuwing (zonder te programmeren), geautomatiseerde foutafhandeling, logging & auditing, business activity en web-sla-monitoring, end-to-end beveiliging en deployment. Deze faciliteiten zelf worden ook weer als service beschikbaar gesteld. Voor functioneel beheer is het vooral van belang dat hierbij de juiste tooling wordt ingezet. Overeenkomsten en verschillen tussen traditioneel en SOA functioneel beheer Bij de SOA zien we andere accenten ontstaan: uniformiteit in de architectuur en processen, zodat hiermee services kunnen worden opgezet die faciliterend zijn voor de verschillende partijen in de keten. Levert dit nu overeenkomsten en verschillen op in de wijze waarop functioneel beheer opereert? We zetten de zaken op een rijtje. Overeenkomsten De overeenkomsten zijn in de eerste plaats te vinden bij de te onderhouden objecten, zoals business- en functioneel ontwerp, business rules, (meta)datamodel en diensten- en productportfolio s. Daarnaast zijn de overeenkomsten te vinden in het modellenbos van kwaliteits- en procesmodellen. De volgende modellen zijn onder meer van toepassing bij functioneel beheer: Capability Maturity Model (CMM), Kennismanagement (KM), Kerncompetenties, Strategisch Alignment Model, Test Management Approach (TMAP), Control Objectives for Information and related Technology (CobiT), Instituut Nederlandse Kwaliteit (INK) en Business Information Services Library (BISL). En ten derde zijn er overeenkomsten in de operationele ondersteuning: meekijken met de uitvoering en ingrijpen en corrigeren wanneer dat nodig is. Een traditionele functioneel-beheerafdeling zou bijna zeggen: Kom maar op met SOA, we hebben vaker rubbish overgedragen gekregen vanuit een project, dat zijn we inmiddels wel gewend en we hebben het uiteindelijk toch altijd wel aan de praat gekregen. Lees toch maar even verder. Verschillen Wat zijn nu de bepalende verschillen tussen het functioneel beheer van een SOA en een traditionele omgeving? In figuur 2 zijn de meest kenmerkende verschillen in kaart gebracht. Herbezinning op functioneel beheer? Traditioneel wordt een beheerorganisatie opgezet op basis van de volgende bouwstenen: eigenaarschap, te beheren objecten./te leveren diensten, beheerprocessen, TVB (taken, verantwoordelijkheden en bevoegdheden)/rollen en kwaliteitsniveaus. Wat betekent SOA voor deze bouwstenen? We zetten de belangrijkste zaken even op een rijtje en proberen daarna de vraag te beantwoorden of SOA leidt tot een herbezinning van functioneel beheer. In het kader staan enkele tips uit de praktijk om het leven van de functioneel beheerder aangenamer te maken. Eigenaarschap Afspraken staan bij SOA voorop, daarna volgt pas eigenaarschap over de uitvoering ofwel de processen. Er kunnen afspraken worden gemaakt tussen externe partijen of tussen afdelingen onderling, dit heten dan business-services ( valideer kredietwaardigheid, registreer claim, geef informatie klantorder, accepteer polis ). In plaats van over afspraken tussen afdelingen praten we liever over afspraken tussen bedrijfsfuncties (inkoop, relatiemanagement, acceptatie, fraudebestrijding, claimbehandeling enzovoort). Afdelingen zijn dan minder relevant; deze zijn vaak regionaal of om andere redenen anders ingericht (in ieder geval vaak nog niet bedrijfsfunctiegericht). Business-services Tips Vanuit een praktijksituatie geven we de volgende tips mee voordat je als functioneel beheerder een SOA in beheer gaat nemen. Zorg voor: traceerbaarheid van de (business en non-functionele) requi- rements; traceerbaarheid van services (onderscheid in business-, applicatie- en technische services); transparantie in exploitatie, sturing en controle van de servi- ces door middel van een serviceadministratie; transparantie in de doorbelasting van kosten; transparantie van de rechten en plichten voor de gebruiker; opleiding in SOA basics; maar maak je niet druk of het SOA-framework wel klopt; dat is voer voor architecten. 39
evaluatie SOA t Traditioneel functioneel beheer SOA functioneel beheer T De inrichting van de informatievoorziening is volledig afhankelijk van de omgeving waarbinnen informatie wordt uitgewisseld. De inrichting van de informatievoorziening is deels afhankelijk van de keten waarbinnen informatie wordt uitgewisseld. Dit is voornamelijk het geval bij gegevensdefinities en het verloop van de processen. Daarnaast zijn er aandachtsgebieden die generiek van aard zijn en dus kunnen worden ingericht onafhankelijk van de keten waarbinnen de informatievoorziening plaatsvindt (procesinfrastructuur, services en technische infrastructuur). S k B D g Strikte scheiding tussen administratieve organisatie (AO) en internal control (IC) en systeembeheer. Uitgangspunt is het productiehandboek. Transparantie (traceerbaarheid) van de exploitatie, sturing en controle; de servicesarchitectuur geeft gecontroleerde toegang tot de processen en de resultaten die het gevolg zijn van de uitvoering van deze processen. Uitgangspunt is de servicesadministratie (discovery, lifecycle, beheer). D ra A v a Beheerder is qua productie vooral proactief bezig: plannen en klaarzetten. Functioneel beheerder is qua productie meer reactief bezig, want processen en services gaan uit van zelfsturing of gedragen zich als black boxes. Verder meer aandacht voor het bewaken van processen, gezond houden van de omgeving en oplossen van fouten. R L Beheerder heeft te maken met functional stovepipes : relatief grote zelfstandige verticale applicaties met hun eigen wereld. Functioneel beheerder heeft te maken met relatief kleine zelfstandige functionele eenheden (services) die draaien in een heterogene omgeving met applicaties voor processturing, middleware en andere integratiesoftware. F g Beheerder hoeft slechts kennis te hebben van één omgeving om volledig te kunnen functioneren. De planningen van systeemontwikkelingsprojecten dienen nauwkeurig op elkaar te worden afgestemd omdat de gegevensdiensten die het ene informatiesysteem van het andere nodig heeft, pas worden afgesproken, ontworpen en gebouwd nadat deze noodzaak is gebleken. Functioneel beheerder zal algemene kennis moeten hebben van de volledige heterogene omgeving met vervolgens een specialisatie. De planningen van systeemontwikkelingsprojecten zijn redelijk onafhankelijk van elkaar, omdat de gegevensdiensten die het ene informatiesysteem van het andere nodig heeft, door het andere systeem op voorraad beschikbaar worden gesteld. T Autorisatiecontroles zijn voornamelijk gebaseerd op de aard van de uit te voeren handeling en slechts bij hoge uitzondering op beperkingen ten aanzien van de deelpopulatie van gevallen waarop de handeling wordt uitgevoerd. Informatievoorziening is een gesloten bolwerk. Ook tussen de ketens intern zijn er hoge muren tussen verschillende delen. De neiging van systeemeigenaren om hun gegevens te optimaliseren en te beschermen voor eigen gebruik en overige belangen te verwaarlozen, wordt bestreden door het eigendomsidee af te zwakken. Koppelingen tussen verschillende delen van de informatievoorziening worden op bestelling en als point-to-pointoplossingen gebouwd. Daarbij dient de ene partij kennis te hebben van een of meer van de volgende delen van de andere partij: de interne gegevensrepresentatie, gebruikte technologie, toegepast transactiemanagement en verwerkingstempo. Autorisatiecontroles zijn gebaseerd zowel op de aard van de uit te voeren handeling als op beperkingen ten aanzien van de deelpopulatie van gevallen waarop de handeling wordt uitgevoerd. In het geval van klanten en leveranciers is de toegang zelfs beperkt tot een zeer kleine deelpopulatie, namelijk de gegevens die op henzelf betrekking hebben. Ketens hebben toegang tot hun gegevens en documenten. In een SOA bevinden zich vele, onderling afhankelijke, services in verschillende stadia/versies van gebruik en zijn er meerdere beheerpartijen, exploitanten en gebruikers(organisaties) actief. Het is daarom ondoenlijk een SOA te beheren zonder goede integrale managementgereedschappen (business activity monitoring, services-administratie). Interfaces naar andere delen van de informatievoorziening worden op voorhand en generiek beschikbaar gesteld. Deze interfaces zijn onafhankelijk van de aan weerszijden toegepaste interne gegevensrepresentatie, gebruikte technologie, toegepast transactiemanagement en verwerkingstempo. Alle uitwisseling geschiedt via gestandaardiseerde gegevenselementen. Ju ti G O g 40
Traditioneel functioneel beheer Systemen zijn beschikbaar voor interactief gebruik tijdens kantooruren. Batchverwerking vindt in batchvensters plaats. De transactionele en documentaire informatievoorzieningen zijn gescheiden werelden. De procesgang (inclusief routering, werkverdeling en rappellering) is ingebakken in de verwerkingsapplicaties. Als er een nieuwe afnemer is van een mutatie uit een verwerkingsapplicatie, dient deze applicatie te worden aangepast. Rollen conform industriestandaarden zoals ITIL, ASL, BiSL, Looijen e.d. Functionele foutafhandeling is vaak een taak voor gebruikers. Testen volgens industriestandaarden, zoals TMAP. Juridisch kader vooral van toepassing bij uitbestedingsrelaties; de aansprakelijkheid ligt vaak bij één eigenaar. Geen bijzondere noodzaak tot standaardisatie. Ontwerp, uitvoering en bewaking van processen vinden gescheiden plaats. SOA functioneel beheer Systemen zijn beschikbaar voor interactief gebruik tijdens alle werkbare uren. Batchverwerking kan te allen tijde worden uitgevoerd, zonder verstorend te werken op het interactieve gebruik. De gebruiker werkt vanuit een omgeving waarin zowel transactionele als documentgerichte taken in samenhang aan hem ter beschikking worden gesteld. De procesgang wordt geregistreerd en aangestuurd door workflowmanagement en juist niet in de verwerkingsapplicaties. Dit geldt zowel binnen als tussen verwerkingsapplicaties. De procesgang is zichtbaar en traceerbaar. Applicaties melden standaard en ongevraagd hun mutaties af bij het workflowmanagement, dat vervolgens bepaalt welke verdere verwerking naar aanleiding van deze mutaties dient plaats te vinden. Deze verdere verwerking is niet zichtbaar voor de oorspronkelijke applicatie. Nieuwe rollen (zie Taken, verantwoordelijkheden en bevoegdheden ) Op basis van de procesbeschrijvingen wordt nagegaan welke fouten er kunnen voorkomen. De business stelt vast op hoe deze moeten worden afgehandeld door de procesinfrastructuur. De procesinfrastructuur zorgt voor afhandeling van fouten. Hierdoor worden gebruikers niet belast met het afhandelen van uitzonderingssituaties in de procesgang. Het testen van SOA-componenten is een stuk technischer van aard dan het testen van een traditioneel systeem (denk aan interne en externe XML-standaarden, quality-of-service metrics, security, communicatieprotocollen etc.). Services dienen volledig getest te zijn omdat de afnemer van een service moet kunnen bouwen op kwalitatief goede services. Je kunt bij SOA vanwege het grote aantal regressietesten niet zonder geautomatiseerd testen en valideren. De juridische relatie tussen de gebruikers van de SOA-infrastructuur en de beheerorganisatie dient zorgvuldig te worden ingericht. De inrichtingskeuzes die worden gemaakt, kunnen onder meer van invloed zijn op eventuele aansprakelijkheden die uit de informatie-uitwisseling voortvloeien. De partijen die informatie uitwisselen, moeten de afspraken over de betekenis en samenhang van begrippen en gegevens expliciet vastleggen (met standaarden zoals XML en een gegevensmodel). Doordat het ontwerp, de uitvoering en de bewaking van de werkprocessen grotendeels in de SOA-procesinfrastructuur zijn belegd, hoeven gebruikers niet op de hoogte te zijn van het procesverloop. In feite verdwijnt de term business & IT, want IT wordt gewoon business, als een leverancier van informatieservices. Figuur 2. Verschillen tussen traditioneel en SOA functioneel beheer 41
evaluatie SOA t maak je in principe eenmalig en zijn herbruikbaar. Het is belangrijk dat de uitvoering van een business-service, in veel gevallen een werkproces, volledig valt binnen een bedrijfsfunctie. Een logisch informatiesysteem loopt in het ideale geval een op een met een bedrijfsfunctie. Een bedrijfsproces loopt van klant tot klant en zal in het algemeen meerdere werkprocessen bevatten.»functioneel beheerders kunnen niet meer alleen in functional stovepipes denken«beheerobjecten en te leveren diensten De inrichting van het beheer is deels afhankelijk van het domein waarbinnen informatie wordt gebruikt. Dit is voornamelijk het geval bij de domeinspecifieke beheerobjecten: gegevensdefinities en het verloop van de werkprocessen. Te leveren (business- c.q. functionele) diensten door de functioneel beheerder zijn beveiliging & audit, interactie, procesbeheersing, (meta)datamanagement en automatische verwerking. Daarnaast is er een aantal aandachtsgebieden dat generiek van aard is en dus kan worden ingericht onafhankelijk van het domein waarbinnen de informatieuitwisseling plaatsvindt. Dat heeft tot gevolg dat deze generieke inrichting in meerdere domeinen kan worden toegepast (of in SOA-termen: herbruikbaar is). De belangrijkste beheerobjecten zijn hier de procesinfrastructuur (met name BPM en workflow management) die de processen uitvoert en bewaakt, de services, de referentieprocessen en de technische infrastructuur inclusief koppelvlakken. Te leveren diensten zijn generieke functies zoals infrastructuurbeheer en gegevensbeheer. Beheerprocessen De standaard op het gebied van functioneel beheer is BiSL. Hierbij is de volgende vraag relevant: is BiSL toepasbaar voor SOA? Het antwoord is: niet helemaal. Zo ontbreken bijvoorbeeld het configuratieproces en versiebeheer; ook voor SOAbeheer zijn dat belangrijke basisprocessen. BiSL is gericht op monolithische processen (de stovepipe) en als gevolg hiervan is het aspect governance beperkt uitgewerkt. De governance van CobiT kan hierbij mogelijk een oplossing bieden. Verder lijkt het erop dat SOA nog voor een richtingenstrijd in het modellenbos kan zorgen: het beheer van services, zo belangrijk in SOA, zal door zowel BiSL als ASL geclaimd kunnen worden (is een service nu de applicatie, of is een service de functionaliteit?). Taken, verantwoordelijkheden en bevoegdheden De verdeling van taken, verantwoordelijkheden en bevoegdheden is onlosmakelijk verbonden met de inrichting van de SOA-componenten en komt tot uiting in de processen (werk- en beheerprocessen). In deze processen wordt beschreven wie wanneer bevoegd is welke processtap uit te voeren. SOA zorgt verder voor een aantal nieuwe rollen binnen functioneel beheer: serviceprovider: beheert een serviceportfolio binnen de SOA-infrastructuur; beheerder/architect: zorgt voor de vaststelling van standaarden en voor een juiste communicatie inzake wijzigingen; competence authority: instantie/organisatie die partijen van normen en een kwaliteitskeurmerk voorziet. De basishouding die ten grondslag ligt aan deze rollen, zal meer gericht zijn op het conformeren aan de open standaarden, servicegericht zijn, samenwerken en het oprecht delen van kennis. Alleen al het conformeren aan standaarden zal voor diverse ICT ers een significante verandering zijn. De noodzakelijke veranderingen zullen niet alleen ingezet worden vanuit de medewerkers, maar ook geborgd moeten worden in de gehele organisatie. 42
Control Door het monitoren van de uitvoering van de processen en services ontstaat inzicht in hoe de verschillende processtappen in de praktijk verlopen en kan zichtbaar worden gemaakt waar eventueel sprake is van bottlenecks (business activity monitoring). Dit biedt de functioneel beheerder aanknopingspunten voor het aanpassen van bestaande processen of het ontwerpen van nieuwe processen. Het probleem is echter dat door de continue interactie en grote aantallen transacties het handmatig beheren van deze proces- en servicelevels ontzettend veel tijd kost. Dit probleem kan worden opgelost door geautomatiseerde specificatie en observatie van de servicelevels toe te passen. Veelbelovende, maar grotendeels nog onbeproefde oplossingen hiervoor zijn het Service Level Agreement Framework (WSLA) van IBM, de Web Service Management Language (WSML) van HP en de Web Services Offering Language (WSOL) van de Carleton University in Canada. Bij deze oplossingen zouden de CobiT-controls, SLA s, QoS en KPI s kunnen worden geoperationaliseerd. Literatuur ASL BiSL Foundation (2006). Een monoliet is zo gek nog niet. Baars, C. (2007). Domotica voor organisaties, Automatisering Gids, 12 oktober.. Best, B. de (2007). Beheren onder architectuur. IT Beheer 5 (juni). CFI (2006). Klantgerichte innovatie onder architectuur. NK Architectuur 2006. Greefhorst, D. (2006). Service Oriented Enterprise Architecture, Landelijk Architectuur Congres 2006. Have, S. ten e.a. (1999). Het managementmodellenboek. Berenschot. Kenniscentrum (2007). NORA 2.0, Nederlandse Overheid Referentie Architectuur. Pols, R. van der, R. Donatz & F. van Outvorst (2005). BiSL, een framework. Zaltbommel: Van Haren. Schekkerman, J. (2007). SOA in het perspectief van Enterprise Architectuur. Via Nova Architectura, januari. Wieringa, R. (2006). Wat ICT-architecten moeten weten. Automatisering Gids, 6 januari. Richard Feringa is managementconsultant bij Logica. E-mail: richard.feringa@logica.com. Norbert Huijzer is veranderkundig consultant. E-mail: norbert@huijzerconsultancy.com. Hans Tönissen is managing consultant bij Van de Geijn Partners. E-mail: h.tonissen@vdgp.nl. Conclusie De focus die voorheen lag op de interne informatievoorziening is bij SOA aan het verschuiven en verbreden naar bedrijfsprocessen die zich niet alleen intern afspelen, maar ook over de afdelingsen organisatie- en systeemgrenzen heen strekken. Het zal duidelijk zijn: functioneel beheerders kunnen niet meer alleen in functional stovepipes denken. De functioneel beheerder die alleen verstand heeft van het CRM of het financiële systeem, zal dus uitsterven. Processen lopen over alle systemen en organisaties heen. Het is vooral de serviceprovider die een belangrijke rol zal spelen binnen de SOA. Functioneel beheer, als serviceprovider van business- en functionele services, zal moeten bepalen welke processen, processtappen en services (delen van het proces zijn immers uit te besteden) hij wil onderhouden en beheren. Deze keuze, en ook de te verwerken hoeveelheden, bepaalt de interne structuur van functioneel beheer. Wel zal van functioneel beheer verwacht worden dat ze aan kwaliteitseisen voldoen om in de keten serviceprovider te mogen zijn. 43