SOA in functioneel beheerperspectief

Transcriptie

1 SOA in functioneel beheerperspectief Een herbezinning Er wordt veel gepubliceerd over service georiënteerde architecturen, vaker SOA genoemd (naar de Engelse term Service Oriented Architecture). Het functioneel beheerperspectief ontbreekt meestal. Dit artikel brengt het functioneel beheerperspectief vanuit een praktijksituatie in kaart. De belangrijkste les is dat de introductie van SOA dwingt tot een herbezinning op beheer. 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 IT 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. Richard Feringa, Norbert Huijzer en Hans Tönissen Het grote vertrouwen van het programma in de maakbaarheid van business en techniek, blijkt echter nog niet terecht. Er is te vroeg gejuicht. De business is nog niet gereed voor procesmatig werken (laat staan service oriented), ketenpartners hebben hun samenwerking niet juridisch geborgd, te koppelen systemen en gegevens blijken niet zo herbruikbaar, SOA-integratiecomponenten, zoals het business process managementsysteem 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 4 mei ITB08-04_v3.indd :19:21

2 standaarden gebaseerde SOA en de beheerorganisaties komen niet uit het vraagstuk wie nu eigenaar van wat is. Organisatie Afdeling Bedrijfsproces Het veranderprogramma heeft te veel hooi op zijn vork genomen. Naast klassieke projectrisico s als 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 het beheerperspectief. Dit laatste perspectief, het functioneel beheerperspectief, wordt in dit artikel verder behandeld. SOA in vogelvlucht Veel bedrijven adopteren de service georiënteerde architectuurstijl met het idee meer flexibiliteit in de bedrijfsprocessen en de bijbehorende informatieverwerking te realiseren. Over SOA doen vele definities de ronde, die allemaal op ongeveer hetzelfde neerkomen: SOA is een architectuur die nuttige bedrijfscomponenten hergebruikt, zowel binnen als buiten de context van applicaties, afdelingen of organisaties. Aangezien een SOA afdelings- of zelfs organisatie-overschrijdend 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 één-opéén 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 Logische informatie systeem Bedrijfsfunctie Bedrijfsservice Applicatieservice Figuur 1 Relatie tussen architectuurcomponenten ketens is het verstandig al rekening te houden met: Het toepassen van open standaarden; Het kunnen beschikken over managementinformatie; 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 eerst over ontwerpen, over standaarden, over de relatie tussen aanbieder en leverancier en dan pas over infrastructuur. SOA in soorten en maten De SOA bestaat niet, er lijkt eerder sprake te zijn van een aantal scenario s. We onderscheiden er een vijftal, dat helpt 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, ook zijn de grenzen in de praktijk niet zo scherp te leggen. Werkproces I. Basis-SOA Een basis-soa kenmerken we als een software architectuur waarbij middelen in een netwerk als zelfstandige services beschikbaar zijn gesteld. Het gebruiken van zo n service is mogelijk 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. II. Open standaarden-soa Een dergelijke 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 1 onderdelen vormen waaruit de processen zijn opgebouwd, is het mogelijk om services te vervangen zonder dat de gebruikers daar al te veel hinder van ondervinden en zonder dat de processen wezenlijk veranderen. Dit kenmerk maakt het mogelijk om bestaande systemen in te zetten, met als voorwaarde dat deze zich gedragen als services. Het is dan wel noodzakelijk dat partijen die gegevens met elkaar uitwisselen dezelfde beteke mei 2008 ITB08-04_v3.indd :19:22

3 nis 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 als 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. III. Publieke SOA Bij dit niveau wordt het open karakter verder versterkt, nu zijn ook portalen (naast systeem-systeemkoppelingen) 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 hoofdaspecten 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. IV. Samengestelde (composite) SOA Hierbij kunnen services of bestaande applicaties samengesteld worden tot complexere services. Dit scenario lijkt op dit moment de norm te worden. De bedoeling hierbij 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, dan kan systeemontwikkeling beperkt blijven tot het vaststellen van de procesgang en de wijze waarop de (herbruikbare) services moeten worden samengesteld en aangeroepen. V. 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 vooral op gericht zijn om 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-endbeveiliging 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 de 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. De overeenkomsten De overeenkomsten kunnen in eerste instantie worden gevonden bij de te onderhouden objecten, zoals business en functioneel ontwerp, business rules, (meta) datamodel en dienstenportfolio s. In tweede instantie 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). Bent u er nog? In derde instantie is dat 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 wel inmiddels wel gewend en we hebben het uiteindelijk toch altijd wel aan de praat gekregen. Lees toch maar even mee met het volgende deel. 4 mei ITB08-04_v3.indd :19:22

4 Traditioneel functioneel beheer De inrichting van de informatievoorziening is volledig afhankelijk van de omgeving waarbinnen informatie wordt uitgewisseld. Strikte scheiding tussen administratieve organisatie (AO) en interne control (IC) en Systeembeheer. Uitgangspunt is het productiehandboek. Beheerder is qua productie vooral pro-actief bezig: plannen en klaarzetten. Beheerder heeft te maken met functional stovepipes : relatief grote zelfstandige verticale applicaties met hun eigen wereld. Beheerder hoeft slechts kennis hebben van één omgeving om volledig te kunnen functioneren De planningen van systeemontwikkelings-projecten dienen nauwkeurig op elkaar te worden afgestemd omdat de gegevensdiensten die het ene Informatiesysteem van een ander nodig heeft, pas wordt afgesproken, ontworpen en gebouwd nadat deze noodzaak is gebleken. 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 moet de ene partij kennis hebben van een of meer van de volgende delen van de andere partij: de interne gegevensrepresentatie, gebruikte technologie, het toegepaste transactiemanagement en verwerkingstempo. Systemen zijn beschikbaar ten behoeve van interactieve 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, moet deze applicatie worden aangepast. Rollen conform industrie-standaarden, zoals ITIL, ASL, BiSL, Looijen en dergelijke. SOA functioneel beheer 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). Transparantie (traceerbaarheid) van de exploitatie, sturing en controle; de services architectuur geeft gecontroleerde toegang tot de processen en de resultaten die het gevolg zijn van de uitvoering van deze processen. Uitgangspunt is de services administratie (discovery, lifecycle, beheer). Functioneel Beheerder is qua productie meer reactief bezig, want processen en services gaan uit van zelfsturing of gedragen zich als blackboxes. Verder meer aandacht voor het bewaken van processen, gezond houden van omgeving en fouten oplossen. 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 integratie software. 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 een ander nodig heeft, door het andere systeem op voorraad beschikbaar wordt gesteld. Autorisatiecontroles zijn gebaseerd op zowel 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 hen zelf 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 management-gereedschappen (business activity monitoring, services administratie). Interfaces naar andere delen van de informatievoorziening worden op voorhand en op generieke wijze beschikbaar gesteld. Deze interfaces zijn onafhankelijk van de aan weerszijden toegepaste interne gegevensrepresentatie, gebruikte technologie, toegepaste transactiemanagement en verwerkingstempo. Alle uitwisseling geschiedt via gestandaardiseerde gegevenselementen. Systemen zijn beschikbaar ten behoeve van interactieve gebruik tijdens alle werkbare uren. Batchverwerking kan te allen tijde worden uitgevoerd, zonder op het interactieve gebruik verstorend te werken. 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 verwerkingapplicaties. 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 plaats moet vinden. Deze verdere verwerking is niet zichtbaar voor de oorspronkelijke applicatie. Nieuwe rollen (zie verder in het artikel) mei 2008 ITB08-04_v3.indd :19:23

5 Traditioneel functioneel beheer Functionele foutafhandeling is vaak een taak voor gebruikers. Testen volgens industrie-standaarden, zoals TMAP. Juridisch kader is vooral van toepassing bij uitbestedingrelaties; aansprakelijkheid ligt vaak bij één eigenaar. Geen bijzondere noodzaak tot standaardisatie. Ontwerp, uitvoering en bewaking processen vindt gescheiden plaats. SOA functioneel beheer Op basis van de procesbeschrijvingen wordt nagegaan welke fouten voor kunnen komen. De business stelt vast op welke wijze 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-ofservice metrics, security, communicatieprotocollen et cetera.). Services moeten volledig getest zijn omdat de afnemer van een service moet kunnen bouwen op kwalitatief goede services. Je kunt bij SOA niet zonder geautomatiseerd testen en valideren vanwege het grote aantal regressietesten. De juridische relatie tussen de gebruikers van de SOA-infrastructuur en de beheerorganisatie moet zorgvuldig 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 behulp van standaarden, zoals XML en een gegevensmodel.) Doordat het ontwerp, de uitvoering en de bewaking van de werkprocessen grotendeels in de SOA- procesinfrastructuur is 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 informatie-services De verschillen Wat zijn nu de bepalende verschillen tussen het functioneel beheer van een SOA en een traditionele omgeving? In nevenstaand schema 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/rollen (taken, verantwoordelijkheden en bevoegdheden) 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. We sluiten af met een aantal tips uit de praktijk om het leven van de functioneel beheerder aangenamer te maken. Eigenaarschap Afspraken staan bij SOA voorop, dan pas eigenaarschap over de uitvoering ofwel de processen. Afspraken kunnen gemaakt worden tussen externe partijen of tussen afdelingen onderling, dit heten dan business services (valideer kredietwaardigheid, registreer claim, geef informatie klantorder, accepteer polis). In plaats van 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 elk geval vaak nog niet bedrijfsfunctiegericht). Business services 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 één-op-één met een bedrijfsfunctie. Een bedrijfsproces loopt van klant tot klant en zal in het algemeen meerdere werkprocessen bevatten. Beheerobjecten en de 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)data management en automatische verwerking. Daarnaast is er een aantal aandachtsgebieden dat generiek van aard is en dus onafhankelijk van het domein waarbinnen de informatie-uitwisseling plaatsvindt, kan worden ingericht. 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 (vooral 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. Voorbeelden zijn dat het configuratieproces en versiebeheer ontbreken; voor SOA-beheer zijn dat belangrijke basisprocessen. Verder is het BISL-begrip portfolio bij SOA vooral van toepassing op de 4 mei ITB08-04_v3.indd :19:23

6 serviceadministratie. Lifecycle management is gekoppeld aan de business-processen. BISL is gericht op monolithische (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 veroorzaken; het beheer van services, zo belangrijk in de SOA, zal zowel door 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: Service provider: 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 te grondslag aan de boven genoemde rollen zal meer gericht zijn op het conformeren aan de open standaards, servicegericht, 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. Vanuit een praktijksituatie geven we de volgende tips mee voordat je als functioneel beheerder een SOA in beheer gaat nemen: traceerbaarheid van de (business en non-functionele) requirements; traceerbaarheid van services (onderscheid in business-, applicatie- en technische services); transparantie in de exploitatie, sturing en controle van de services door middel van een service administratie; 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-architecture framework wel klopt; dat is voer voor architecten. 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 service levels ontzettend veel tijd kost. Dit probleem kan worden opgelost door geautomatiseerde specificatie en observatie van de service levels toe te passen. Veelbelovende, maar grotendeels nog onbeproefde, oplossingen hiervoor zijn Web 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. 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 afdelings- en 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 service provider die een belangrijke rol zal spelen binnen de SOA. Functioneel beheer, als service provider 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 bepalen de interne structuur van functioneel beheer. Wel zal van functioneel beheer verwacht worden dat ze aan kwaliteitseisen voldoen om in de keten service provider te mogen zijn. Richard Feringa is managementconsultant bij Logica (Richard.Feringa@logica.com). Norbert Huijzer is ICT- en veranderdeskundige (Norbert@ HuijzerConsultancy.com). Hans Tönissen is managing consultant bij van de Geijn Partners. h.tonissen@vdgp.nl Bronnen Het managementmodellenboek, Berenschot, 1999 Pols, Donatz en van Outvorst, BISL, 2005 NORA 2.0, Nederlandse Overheid Referentie Architectuur, 2007 Jaap Schekkerman, SOA in het perspectief van Enterprise Architectuur, 2007 Roel Wieringa, Wat ICT architecten Moeten Weten, Automatisering Gids, 2006 Cor Baars, Domotica voor organisaties, Automatisering Gids, 2007 Bart de Best, Beheren onder Architectuur, IT Beheer Management, 2007 Danny Greefhorst, Service Oriented Enterprise Architecture, 2006 Een monoliet is zo gek nog niet, ASL foundation, 2006 CFI Klantgerichte innovatie onder architectuur, NK Architectuur, 2006 Noot 1 Er wordt ook wel gesproken over loosely coupledservices mei 2008 ITB08-04_v3.indd :19:23