Het e-government bestek: een pleidooi voor integrale architecturen voor een prestatiegerichte overheid Arne Lasance Werken met integrale architectuurconcepten is een effectieve manier van beschouwen, analyseren en beschrijven van de totale organisatie. Architectuurdenken helpt je te vergelijken, te meten, routes uit te zetten, te modelleren, te ontwerpen en uiteindelijk om toekomstvast en kosteneffectief een efficiëntere overheid in te richten en onderhouden. Inleiding: meer met minder De overheid ziet zich in toenemende mate geconfronteerd met zowel teruglopende budgetten als een sterker wordende roep vanuit de samenleving om vergroting van effectiviteit en slagkracht en om meer controleerbare prestaties. Algemeen is de overtuiging, dat uitgekiende grootschalige inzet van moderne ICT, gekoppeld aan een effectieve (re)organisatie, één van de opties is om te kunnen komen tot een meer prestatiegerichte overheid. Verbetering van de publieke dienstverlening, vermindering van de administratieve lasten en verhoging van de productiviteit van de overheid zelf zijn de doelen die de overheid dezer dagen zegt met inzet van ict te willen realiseren. Dat moet leiden tot innovatie en verbeteringen in de taakdomeinen beleidsvorming, beleidsuitvoering en beleidshandhaving én in de interne bedrijfsvoering. In al deze domeinen zou met name internet-technologie de overheid (net als het bedrijfsleven) nieuwe mogelijkheden moeten kunnen bieden om informatiever, interactiever, consultatiever maar ook zorgzamer en effectiever de relatie met haar burgers te verbeteren. Beleidsvorming kan meer participatief ingericht worden, door het elektronisch ondersteunen van maatschappelijke discussies, het openbaar maken van informatie, het verschaffen van inzicht in mogelijke politieke keuzen en implicaties daarvan en zelfs het gebruik van moderne volksraadpleginginstrumenten. Beleidsuitvoering wordt verbeterd door het geïntegreerd en gecoördineerd leveren van overheidsproducten en –diensten, via meerdere kanalen maar minder loketten en met minder administratieve lasten voor burger en bedrijfsleven; ongeacht aantal en diversiteit van de daarbij betrokken back-office processen. Ook bij verbetering van beleidshandhaving kunnen moderne informatie- en communicatiemiddelen en –processen helpen, door politie, inspecties én burgers meer mogelijkheden te geven om beter gecoördineerd de openbare orde en veiligheid te bewaren en overtredingen van regels vast te stellen, te melden en tegen te gaan. Tenslotte bieden moderne technologieën de overheid, net als private organisaties, vele mogelijkheden om de interne en externe bedrijfsvoering slagvaardiger en efficiënter in te richten, processen te uniformeren en optimaliseren, en gegevens en systemen te delen. Zodra daarbij dan meerdere uitvoeringsorganisaties betrokken zijn, zoals bijv. bij een gecombineerde vraag om huursubsidie, bijstand, aanpassing aan woning en zorgdiensten bij plotseling opgetreden invaliditeit, blijkt het ineens noodzakelijk om - tot heden organisatorisch, juridisch en functioneel van elkaar gescheiden dienstleveringsketens niet alleen onderling qua gegevensuitwisseling te koppelen, maar ook om hen onder één eenduidige procesregie te plaatsen. Die regie is nodig om via één loket de vraag te ontvangen en te accepteren; zonder die regie is het ook niet mogelijk om de burger geïntegreerde statusinformatie te leveren over de voortgang van de behandeling van zijn verzoeken. En dat vereist samenwerking, herverdeling van bestaande en allocatie van nieuwe verantwoordelijkheden tussen - en eventueel boven- de betrokken ketenpartners,
1
organisaties en organisatieonderdelen. Waar dan formeel en effectief geen overkoepelende probleemeigenaar blijkt te bestaan, leidt dit niet zelden tot weerstanden en competentiestrijd. De digitalisering of informatisering van de Nederlandse overheid ontwikkelt zich gestaag maar langzaam. Op een aantal terreinen wordt voortgang geboekt; dat neemt niet weg, dat er een breed onbehagen blijft leven over de grip die de overheid heeft, neemt of kan krijgen op de (vooral informatiserings-)ontwikkelingen. Gegevens worden vaak situationeel en dus niet eenduidig vastgelegd en lang niet altijd elektronisch beschikbaar gesteld, zodat ze steeds opnieuw moeten worden gevraagd, ingevoerd en opgeslagen. Als gevolg daarvan worden ze ook verspreid over vele ‘autonome’ ambtelijke diensten geadministreerd, inclusief een wildgroei in ondersteunende hard- en maatwerksoftware, met alle communicatie- en consistentieproblemen van dien. Dat dit alles niet bevorderlijk werkt voor efficiency in uitvoering, voor daadkracht en voor optimale kennisbenutting binnen de overheid zelf, spreekt voor zich. Het is dan ook niet vreemd dat er voortdurend wordt gezocht naar middelen en methoden om tot een betere beheersing en sturing te komen. In dit verband is de laatste tijd het fenomeen (informatie)architectuur sterk opgekomen. Het ontwerpen van I-, e-, IV-, of ICT-architecturen en het ontwikkelen en bouwen “onder architectuur” worden dezer dagen veelvuldig in de literatuur aangeprezen. Maar naarmate er meer over deze architectuurconcepten gesproken en geschreven wordt als panacee voor de toekomst, of - bij het ontbreken ervan - als excuus voor falen in het verleden, neemt ook het aantal overheidsmanagers toe, dat deze concepten bestempelt als ‘modieus’, of als hoogstens academisch interessant. Het architectuurconcept wordt dezer dagen vooral gebruikt om de toekomstige samenhang der dingen te benadrukken. Maar reflecteert ook de huidige situatie niet een bepaalde – en blijkbaar niet altijd even effectieve - ‘architectuur’ van het overheidsapparaat? De vraag dringt zich dan ook op, hoe het “architectuur”concept effectiever kan worden ingebracht en aangewend, als instrument om tot een betere overheidsorganisatie en betere overheidsinformatisering te komen. Dit artikel wil daaraan een bijdrage leveren. Architectuurconcept als sturingsinstrument Er zijn vele definities en omschrijvingen van (informatie)architectuur in omloop. Een bekende zéér summiere luidt: “een informatiearchitectuur is een set rules en constraints die de informatiehuishouding be- en voorschrijven”. Een integrale organisatiearchitectuur is breder te definiëren als “een samenhangende visie van een organisatie op strategie, doelstellingen, op haar bestaande en gewenste afnemers en leveranciers, op producten en diensten, functies, inrichting, processen, informatie- en gegevenshuishouding en last but not least de technische infrastructuur”. Tot heden zijn sturing, vormgeving en inrichting van de organisatie als zodanig vooral het domein van het management, ondersteund door bestuurskundigen, organisatiekundigen en AO-specialisten. Daarentegen was de inrichting van de informatiehuishouding van een organisatie vooral de verantwoordelijkheid van de techniek, i.c. de I&A afdeling. Dit was een adequate taakverdeling, zolang die ICT ook ondersteunend ‘los’ stond van de feitelijke organisatie, haar functies en processen. De meeste nu in omloop zijnde ‘architectuur’-plaatjes beperken zich dan ook tot het technisch domein, tot infrastructuur en applicatieportfolio. Zeker in de overheid, als informatieverwerkende organisatie bij uitstek, is echter nauwelijks meer onderscheid te maken tussen strategie, visie op de taakuitoefening, functies, processen en de daarbij in te zetten techniek. Een integrale architectuurvisie kan alleen onder eenduidige regie tot stand komen, in een gezamenlijk proces van beeldvorming van, en onderhandeling tussen, alle betrokken belanghebbende partijen. Omdat zo’n architectuur, net als de te beschrijven organisatie, flexibel en toekomstvast moet zijn, is zij ook nooit ‘af’. 2
Architectuurontwikkeling is dan ook eerder een voortdurend dynamisch proces of programma, dan een concreet project met een statisch product of status quo als resultaat. En dat geldt zeker voor “de architectuur” van e-government, een samenhangende visie van en op de digitale overheid. De grote sturingsvraag die nu opkomt betreft dan ook vooral de wijze waarop de verbinding kan worden gelegd tussen de strategie en beleid van de organisatie, de uitvoering en de ICT-functies, de zgn. ‘alignment’. Strategie wordt vertaald in beleid, beleid wordt vormgegeven in een organisatiemodel of ‘bedrijfsarchitectuur’ en vertaald in een bijpassende ICT-architectuur. Zo vormt architectuur de verbindende schakel tussen strategie, beleid en functionele eisen enerzijds en de geboden ict-functionaliteiten of -diensten anderzijds. Architectuur levert vervolgens ook het kader voor governance, zoals hieronder is weergegeven:
architectuurprogrammamanagement
Bedrijfsarchitectuur
Toetsing
Afstemming
ICT architectuur
Toetsing projectmanagement
Functionele eisen
Afstemming
ICTportfolio
Figuur 1: ICT –governance framework
Een organisatie heeft naast project- en portfoliomanagement ook een architectuurprogramma (incl. de bijpassende governance principes1) nodig om bij ‘business process redesign’ de bijbehorende informatiseringsvraagstukken adequaat op te lossen. De bedrijfsarchitectuur vormt daarbij de informatische vraagzijde, de ICT-architectuur het informatische en technische aanbod van oplossingen. Belanghebbenden bij integrale overheidsarchitectuurontwikkeling Het moge duidelijk zijn dat bij het proces van alignment, bij het ontwikkelen en vervolgens toepassen van integrale architecturen altijd verschillende belanghebbenden op verschillende niveaus betrokken (moeten) zijn. Net als in het bestek voor een wijk en/of een fysiek gebouw moet een integrale architectuur beschreven worden in een groot aantal onderling samenhangende plannen, documenten en ‘tekeningen’ – alleen die van de metselaar en loodgieter zijn niet genoeg om een huis te bouwen. Erger is het als hun tekeningen niet passen bij de behoeften van de organisatie. Een adequate methode voor integrale architectuurbeschrijving houdt daar rekening mee en ‘dekt’ alle relevante aspecten of gezichtspunten, van gebruiksdoel (nu en in de toekomst!), streekplan, bestemmingsplan en nutsvoorzieningenkaart tot inrichting, logistieke werkstromen en technische infrastructuur. 1
Zie ook Lasance en Mulder, E-governance binnen de overheid, M&I 2003/3
3
De IEEE ( www.ieee.org) heeft een ‘standaard’ voor zo een adequate beschrijving van (systeem)architecturen geformuleerd in haar standaard 1471, Recommended practice for the architectural description of software intensive systems. Het noemen van ‘systems’ als onderwerp van de te beschrijven architectuur biedt ruimte voor een bredere of smallere ‘scope’ bij het hanteren van de definitie. Zo kan ‘system’ vervangen worden door ‘een computerprogramma’; maar ook door ‘een afdeling’ of ‘kernproces’, door ‘de organisatie’, ‘de keten’ of zelfs door de maatschappij als geheel; afhankelijk van de reikwijdte van de betreffende regiefunctie en architectuurbeschrijving. Die scope wordt in de praktijk ook bepaald door de ict-maturity van de organisatie in kwestie, zoals bijv. de bekende INK-ontwikkelingsfasen illustreren: Productgericht
Beleid
Procesgericht
Systeemgericht
Ketengericht
Maatschappij gericht
implementatie Stimuleren
Sturen
Sturen plus voorzieningen
Figuur 2: INK-fasen
Het gedachtengoed van de IEEE-standaard ïnspireerde ons2 tot het ontwikkelen van een model en methode om breder dan tot nog toe gebruikelijk het integrale bestek van digitale overheidsorganisaties (de ‘e-overheid’) of onderdelen daarvan te beschrijven. De kernboodschap is, dat – ongeacht de scope van het ‘system’ in kwestie - bij het inventariseren van de bestaande situatie, de IST-architectuur, én bij het ontwerpen van een adequaat en dus integraal architectonisch SOLL-bestek, alle belanghebbenden in elke situatie (ver-, aan- of nieuwbouw van de organisatie) een eigen inbreng zullen moeten expliciteren in de architectuurbeschrijvingen. Alleen dan kan sprake zijn van de noodzakelijke alignment, en kan met enig vertrouwen op succes begonnen worden aan detailontwerp en implementatie. Vanuit de idee van vraagsturing zijn de belangrijkste stakeholders bij e-government natuurlijk de klanten van de overheid. Daarbij gaat het zowel om klanten of relaties buiten de overheid (burgers, bedrijfsleven, leveranciers) als om ‘klanten’ bínnen de overheid (van individuele werknemer tot netwerk- en ketenpartners). ‘De klant’ staat dus in het voorgestelde earchitectuurmodel voor de gehele verzameling van informatie- en communicatierelaties van de overheid, steeds gezien in een bepaalde situationele context, van landelijk e-beleid tot en met het niveau van de ontwikkeling van een specifiek lokaal taaksysteem. 2
De auteur is dank verschuldigd aan drs R. Meijer en Mr P. de Kam (verbonden aan Het Expertise Centrum te Den Haag) en prof. Dr R. Wagenaar (TUDelft) voor hun commentaren op en inbreng in dit artikel. Een eerdere versie van dit betoog is in beperkte kring gepubliceerd als ‘research note’ (zie www.hec.nl).
4
Bij de groei naar e-government (als paraplu-term voor een innovatieve, beter toegankelijke en effectievere overheidsorganisatie) vervult vervolgens het politiek bestuur een cruciale rol. Het is allereerst de taak en verantwoordelijkheid van het bestuur, als regisseur en opdrachtgever van het management, om namens de klant én vanuit een brede maatschappelijke verantwoordelijkheid een integrale architectonische visie op doelstellingen, governance, inrichting, procesorganisatie én de daarbij te gebruiken middelen te bepalen. In die visie moeten uiteindelijk alle overige stakeholders kunnen delen, en elke partij moet daarin ook een actieve bijdrage leveren. Zonder eenduidige regie, zonder expliciete ‘top management support’ zal een integraal bestek niet of moeizaam tot stand kunnen komen. Stakeholders bij e-government ontwikkeling De belangrijkste stakeholders bij ontwikkeling en realisatie van e-government zijn dan minimaal de volgende partijen: 1. De informatie- en communicatierelaties: de ‘klant’ Dit is dus de brede groep relaties (gebruikers) van de organisatie – in elke situatie en op elk aggregatieniveau. Deze relaties zien de organisatie in wezen alleen in functie van de functionaliteiten, geboden via de communicatiekanalen, haar ‘Front Offices’ (van werkplek, intranet, extranet, tot internet site). Hen interesseert vooral de content, de functionaliteit die aangeboden wordt, en de mate van dienstverlening en gebruiksvriendelijkheid. De rest van de organisatie (de back offices) is voor hen een black box, en blijft dat liever ook. De klant kan de burger zijn, in zijn rol van afnemer van overheidsdiensten en -producten, maar ook als onderdaan met plichten, als kiezer, werknemer of leverancier. Maar ook de ketenpartner, met wie moet worden samengewerkt, met wie informatie wordt uitgewisseld of aan wie verantwoording moet worden afgelegd is een belangrijke (zo niet in de praktijk van alledag de belangrijkste!) overheidsklant. Klant is natuurlijk ook de politiek die in een dubbelrol het functioneren van de organisatie stuurt en beoordeelt, bijv. aan de hand van VBTB-principes. Gebaseerd als het model dat wij hier schetsen is op het primaat van vraag- en aanbodrelaties, is elke stakeholder steeds ook ‘klant’ van een of meerdere andere stakeholders. Zo zijn ook de organisatie die via een SLA diensten afneemt van een afdeling infrastructuurbeheer klant resp. leverancier! Hun belangen (‘gebruikerswensen’) worden gearticuleerd in een customer relationsarchitectuur, waarbinnen naast channel management beleid, informatie-, diensten- en productaanbod, dienstverleningsniveaus (SLA’s!), procedures rond klanttevredenheidsonderzoeken etc. ook verantwoordings- en beveiligingseisen en -procedures worden geformuleerd. 2. Het (politiek) bestuur Het bestuur vertegenwoordigt de communicatiepartners/klanten, in het gegeven dat zij hun vragen, eisen en opdrachten vertalen in een strategie, doelstellingen, kernactiviteiten en middelen van de organisatie als maatschappelijke waarde-toevoegende entiteit. Uiteindelijk zijn de bestuurders ook eindverantwoordelijk voor de regie en bepalen zij de governance architectuur en voor de organisatie-architectuur, het integrale functioneren van de organisatie. Een concies voorbeeld van articulatie van de architectonische regierol vanuit de bestuurlijke stakeholder geeft figuur 3 (met dank aan organisatie X!):
5
missie
Architectuurprincipes
Richtlijnen en standaards
afgestemde bedrijfsprocessen
procesmodel, X-criteria
kosten
eenmalige gegevens invoer
informatiebeveiliging
afspraken
afgestemde definities
ketenwoordenboek, X woordenboek
kwaliteit
kant-en-klare producten en diensten
standaardapplicaties
flexibiliteit
modulaire systemen
n-tier architectuur, basisregistraties.
uitwisselbare specificaties
XML, PDF, ... ,
Het X is een organisatie die met GEMEENSCHAPSGELD Gemeenschapsgeld conform de WET X DOELMATIG Doelmatig een publieke taak uitvoert, als onderdeel van KETEN Keten samenwerkende organisaties, die het beleid t.a.v. de KLANTEN Klanten humaan wil uitvoeren, waarbij gereageerd moet worden op wisselende Politieke POLITIEKE keuzes t.a.v. dit beleid.
Figuur 3 Arcitectonische alignment van missie, randvoorwaarden en architectuurprincipes
3. Het management van de overheidsorganisatie Het management is verantwoordelijk voor de inrichting van de organisatie, opdat zij de missie en afgesproken taken (inclusief het afleggen van verantwoording daarover) zo efficiënt en effectief mogelijk uit zal kunnen voeren. Het bestuurt de functies kaderstelling, taakuitvoering, ondersteuning, planning en control, en is dus primair verantwoordelijk voor de bedrijfsarchitectuur en de integratie/alignment daarvan met de onderliggende proces-, gegevens-, applicatie- en technische architecturen. 4. De proceseigenaren Dit zijn de professionals, die binnen de gestelde kaders gezamenlijk gedelegeerd verantwoordelijk zijn voor de uitvoering. Via integrale organisation engineering en procesanalyse ontwikkelen zij de integrale procesarchitectuur. Zij voeren de hen opgelegde taken uit met optimale inzet van eigen professionaliteit en zijn vragende partij voor liefst optimale hulpmiddelen (gegevens en applicaties, technische infrastructuur, diensten) richting de aabiedende ondersteunende stakeholders. 5. De O&I of IV- functies Deze functies zijn verantwoordelijk voor de door de organisatie gebruikte gegevens en applicaties, en zo voor de gegevens- en applicatie-architecturen of informatievoorzieningsarchitectuur. 6. De technische functies De techniek tenslotte levert effectief en efficiënt een adequaat, flexibel en onderhoudbaar ict-instrumentarium en bijbehorende diensten. Zij formuleert mede de algemene kaders in termen van een technische architectuur, van beheer, beveiliging en dienstverlening (inclusief ITIL, ISO, SLA’s etc). Vraag en aanbod relaties tussen stakeholders: onderlinge services als basis De relaties tussen deze stakeholders (per situatie/context gegroepeerd, als burger vs overheid, als bestuur vs organisatie, ketenpartner vs ketenpartner, als I&A afdeling in de kwaliteit van opdrachtnemer van de rest van de organisatie enz.) zijn steeds te kenschetsen als een vraag- en aanbodrelatie: zowel in dienstverlening als in verantwoording. Daarmee wordt de basis voor dit model dus gevormd door het concept ‘klantvraagsturing’: elke vraag 6
wordt beantwoord met een dienstverlening. Waar de klant geen direct belang heeft bij het hoe, alleen van het wat van de dienstverlening, geeft de architectuur ook een structuur voor in- en outsourcing en service level agreements.
Geïntegreerde architectuur bestuur
management Organisatie architectuur proceseigenaren
I&C relaties applicatiebeheer IV architectuur gegevensbeheer
TI beheer
dienstverlening
ICT architectuur
verantwoording
Figuur 4: Integrale e-government architectuurbeschrijving: stakeholders en hun onderlinge relaties
Een ideale integrale informatiearchitectuur bestaat dus uit een coherent ‘bestek’, waarin alle stakeholders expliciet hun bijdrage leveren, via een eigen ‘view’ op de eigen plaats, rol, bijdrage aan en eisen binnen de totale architectuur. Een belangrijk aandachtspunt bij het ontwikkelen van architecturen is de aandacht voor de organisatiecultuur. Niet zelden ontstaat dezer dagen een mismatch tussen de klassiek bureaucratische organisatiearchitectuur en de meer op samenwerking gerichte ICTarchitectuur, zoals die met verve door leveranciers wordt gepromoot (autonome business units vs. concern- of enterprisemodel). ICT-architecten veronachtzamen, of verklaren zich onbevoegd om cultuuraspecten en het noodzakelijke change management in de andere stakeholder-niveaus te betrekken in de plannen voor nieuwe systemen. De verschillende stakeholders komen meestal uit heel verschillende culturen en spreken elkaars taal niet. Vaak wordt een al dan niet vermeend ‘gebrek aan top management support’ dan later aangevoerd als verklaring voor het falen van nieuwe technologie. In feite is dit argument overigens een testimonium paupertatis van de ict-ers: zelfs gebrek aan support kan en in voorkomende gevallen móet in een integrale architectuurontwikkeling als gegeven meegenomen worden! Beschrijven en integreren van de verschillende views en architecturen De noodzaak van koppeling en integratie van de verschillende views is hierboven als gegeven geacccepteerd. Architecten, werkzaam binnen één der stakeholdersdomeinen, spreken ook zelf vaak weer een eigen taal, met eigen vocabulair, syntax, grammatica, semantiek en pragmatiek. Zij hanteren ook elk eigen modelleertechnieken en methodes. Zo kennen we bijvoorbeeld de value chain van Porter voor beschrijving van de relaties van de organisatie en haar omgeving. Voor het opstellen van strategische portfolio-analyses is
7
een bekende methode de growth-share matrix van de Boston Consulting Group. Organisatiestructuren worden meestal weergegeven als organogrammen met de bekende ‘harkjes’. Voor procesbeschrijvingen zijn véle methoden en tools beschikbaar; van PetriNetten en DEMO (TU Delft, voortbouwend op NIAM) tot het sterk opkomend Testbed (Bizzdesign) of UML-business extensions. Vooral op de meer ic-technische niveaus is UML (unified modelling language(www.uml.org) van de Object Management Group sterk in opmars, als brede opvolger van DFD’s en ERD’s. Het expliciet beschouwen van de onderlinge stakeholderrelaties als vraag- en aanbod relaties dwingt in elk geval al elke specifieke relatie te beschrijven in één gemeenschappelijke taal, die vrager en aanbieder beide begrijpen. Een meta-methode om de verschillende views geïntegreerd in één bestek te beschrijven wordt bijvoorbeeld ontwikkeld in het Nederlandse Archimate-project (zie http://archimate.telin.nl ). Door de ontwikkeling van één architectuurtaal en visualisatietechnieken die de samenhang en relaties tussen de verschillende domeinen in kaarten brengen, wil ArchiMate de architect voorzien van eenduidige instrumenten ter ondersteuning en verbetering van het architectuurproces. Het sluit daarbij aan bij internationale standaarden als UML en het project werkt nauw samen met organisaties zoals het Nederlands Architectuur Forum (NAF), om inbedding en verspreiding van projectresultaten te borgen. Het ELO-referentiearchitectuurmodel De Nederlandse overheid voelde recent een dringende behoefte aan een referentiearchitectuur “… die als een invulling van het Elektronische Overheid (ELO) huis moet leiden tot een concrete samenhangende visie op de voor de ELO noodzakelijke technische architectuur.” 3 Een studie met deze (N.B. de beperking tot ‘technische’architectuur!) opdrachtformulering is in het najaar van 2002 uitgevoerd in opdracht van het Ministerie van BZK. De resulterende referentie-architectuur moet houvast bieden bij het beantwoorden van vragen als • hoe de communicatiekanalen tussen burger en bedrijf enerzijds en overheid anderzijds (en tussen overheden onderling!) moeten worden (her)ingericht; • of en welke (open) standaarden voorgeschreven moeten worden voor de koppelvlakken tussen de diverse onderdelen van de overheid, en • welke security voorzieningen daarbij nodig zijn. Ter beantwoording van deze vragen is het resulterende ELO-referentiemodel verder uitgewerkt in een “integratie-architectuur”. Daarbij wordt een onderscheid gemaakt tussen twee ‘grand design’ aanpakken, waaruit de overheid op weg naar ELO kan kiezen, te weten ‘koppelen’ of ‘kantelen’. Kantelen (overheidsbrede busines process redesign) wordt als op korte termijn te ambitieus gezien; men kiest dan ook voor eerst koppelen, om later en gradueel te (kunnen) kantelen4. Als leidraad voor verdere integratie is het uitgangspunt genomen, dat eerst gestreefd moet worden naar zoveel mogelijk gemeenschappelijke standaarden en voorzieningen binnen de te kiezen informatie- en technische architectuur. Alleen zo kan voldaan worden aan de eis van onderlinge ‘koppelbaarheid’ van gegevensstromen en benutting van schaalvoordelen bij het inrichten van gemeenschappelijke voorzieningen (‘integratiefuncties’) als message brokers en switches, bij voorkeur in te richten binnen ‘shared service centres’. De ELO-referentiearchitectuur is gebaseerd op het binnen de informatiekunde-discipline breed gedragen ‘3 lagenmodel’: 3
Architectuur elektronische overheid,samenhang en samenwerking, nov 2002, zie ook www.minbzk.nl/contents/pages/00017856/einddoc_architectuur.pdf. 4 Zie ook van der Harst, Eerst koppelen dan kantelen, in M&I 2003/3
8
• • •
de bedrijfsarchitectuur (die nauwelijks uitgewerkt wordt) de informatie-architectuur en de technische architectuur.
Naast de drie horizontale lagen worden hierin nog twee algemene dimensies (beveiliging en beheer) onderscheiden, alsmede een drietal verticale dimensies: • Actor (wie): afdelingen, applicaties, servers • Product (wat): producten, informatie, gegevens • Proces (waar en wanneer): bedrijfs- en communicatieprocessen, netwerk Er resulteert zo een matrix, als weergegeven in figuur 5. Daarin is ook aangegeven waar de integratie-architectuur zich als eerste op zou moeten concentreren.
B e v e i l i g i n g
Actor
Product
Proces
Afdelingen Klanten Leveranciers
Afdelingen Klanten Leveranciers
Afdelingen Klanten Leveranciers
Informatie architectuur
Content Architectuur
Communicatie Architectuur
Technische architectuur
Gegevens Architectuur
Netwerk Architectuur
Bedrijfs architectuur
B e h e e r
Figuur 5: Het ELO referentie-architectuurmodel met integratie-functies
Het ELO-model kan gezien worden als een specifieke invulling van de stakeholderviews Management, Proces, O&I en TI uit het hier voorgestelde integrale e-government architectuurbestek. In die zin kunnen de twee modellen als complementair worden gezien. Ervaringen met het werken met integrale architecturen Inmiddels is het integrale architectuurmodel zoals hierboven geschetst met succes in een aantal zeer verschillende contexten toegepast. E-government architectuurmodel als meet- en analyse-instrument Zodra een organisatie het architectuur-denken in principe accepteert als een normatief kader voor de organisatie-ontwikkelingsstrategie, wordt de beschrijvingsmethode onmiddellijk ook een meetinstrument: waar staat de organisatie nu? Op welke niveaus is al sprake van een bewuste architectuur, in hoeverre zijn de verschillende stakeholderlagen onderling afgestemd en gecoördineerd, in hoeverre is de volgende stap gepland en uitgewerkt?
9
Het model werd toegepast bij het wegen van risico’s rond ict-investeringsplannen van een grote overheidsorganisatie. Na een analyse van verschillende aldaar geformuleerde stakeholder-views werd geconstateerd, dat - het politiek bestuur in kwestie programmatisch maximale toegankelijkheid en klantgerichtheid nastreefde; en ook bereid was daarin te investeren, maar de organisatie niet wezenlijk wilde veranderen; - de concernstaf als leidend technologisch kader een hypermodern e-business architectuurmodel had laten ontwikkelen door een leverancier; - het management en de (integraal managende) proceseigenaren daaronder echter nog geenszins in staat of van zins waren om van hun autonome-business-units model over te stappen op een integraal concernmodel; - er dus voorshands geen sprake kon zijn van, noch reëel zicht op enige concernbrede gegevens- of applicatie-architectuur; - en de I&A-functie de handen zeer vol had aan een op knappen staande verouderde infrastructuur en (WP-based) KA. Deze overheidsorganisatie is ten sterkste aangeraden, om de investeringen voorshands te beperken tot de verbetering van technische infrastructuur en KA, en éérst een integraal programmatisch veranderkader voor de gehele organisatie te ontwikkelen alvorens een hypermodern instrumentarium aan te schaffen, dat de bestaande organisatie (nog) niet effectief zou kunnen gebruiken. Het architectuurmodel als communicatie- en vergelijkingsinstrument en als routeplanner Wanneer meerdere afdelingen, organisaties of ketenpartners dezelfde beschrijvingsmethode in hun onderlinge communicatie accepteren, en tegelijk dezelfde beschrijvingstaal gebruiken, wordt niet alleen het meten van wederzijdse posities mogelijk, maar kan er ook beter gecommuniceerd worden over gemeenschappelijke problemen en best practices. Het hier geschetste architectuurmodel werd oorspronkelijk ontwikkeld en toegepast in een onderzoek voor BZK rond de zgn. Superpilot gemeenten5 die geselecteerd waren voor de uitvoering van te subsidiëren ‘e-gemeente’ projecten. Gebleken was, dat de vier gemeenten elk in een eigen ‘taal’ en syntax hun plannen, inspanningen en de resultaten ervan beschreven, zodat onderlinge vergelijking en kennisdeling niet goed mogelijk was. Door de vier gemeenten op dezelfde wijze conform het model te beschrijven, werden de overeenkomsten, maar ook de verschillen in aanpak duidelijk. Zo bleken de gemeenten drie verschillende ambitieniveaus, ontwikkelstrategieën en systeemscope te hebben: - Eén gemeente koos voor een pure Front Office aanpak, waarbij zonder aan de Back Offices iets te veranderen toch op korte termijn dienstverlening (vooral in termen van informatiepresentatie) aan de burger mogelijk werd. - Twee gemeenten kozen voor een Mid Office aanpak, vooral gericht op het optimaliseren van de communicatie tussen FO en BO, waardoor de FO ook transactiefunctionaliteiten zou kunnen bieden. - Één gemeente tenslotte koos ambitieus voor een integrale Enterprise Application Integration (EAI) strategie, uitgaande van de idee dat als de BO eenmaal geoptimaliseerd zou zijn de FO-functies ‘automatisch’ geleverd zouden kunnen worden, en een apart MO niet eens nodig zou zijn. Daarnaast bleken tussen de gemeentes grote verschillen te bestaan in ambitie, in organisatiemodel, fysieke en procesinrichting, en algehele ict-maturity, die alle hun eigen repercussies hadden op de scope en vormgeving van projecten. De bovengeschetste benaderingen (die dus ook weer voornamelijk de onderste stakeholderslagen betroffen) bleken elk een fase in het bekende 4-fasen model van internetgebruik (presentatie, interactie, transactie, integratie) te representeren; maar schetsten zo wel een mogelijke ontwikkelingsroute die voor alle gemeenten relevant was. 5
zie www.superpilots.nl
10
Het model en de ontwikkeling van een nieuwe procesarchitectuur Voor een provincie werd vanuit het Egov-laboratorium ( www.egovlab.nl) een plan van aanpak gemaakt voor de invoering van één subsidieloket op internet. Na een inventarisatie van de IST-architectuur, de context en de inzichten en eisen van alle belanghebbende partijen op basis van het bestekmodel werden model en de achterliggende e-government-noties uitgelegd aan de betrokken stakeholders. Vervolgens werden in een interactieve sessie alle ideeën, wensen en constraints rond een gezamenlijk elektronisch subsidieloket geïnventariseerd. Daarbij was de klant-view en de repercussies daarvan voor de processen nadrukkelijk het uitgangspunt. Vervolgens is vanuit het bestaande subsidieproces een nieuwe generieke procesarchitectuur gemodelleerd – die voldoende stof aandroeg voor een functioneel ontwerp van een ‘shared’ ondersteunend systeem en de eisen die dit zal stellen aan de infrastructuur. Gedrag klant in de startfase behoefte aan info
schriftelijk
schriftelijk verzoek informatie
telefonisch
online zoeken naar informatie
Stap 1 en 2
telefonisch verzoek informatie
alle subsidies bekijken
selecteren subsidie
gedrag klant op subsidieloket zoeken van antwoorden op vragen (FAQ's)
bekijken hoeveel subsidie er nog is invullen met gegevens
voorbeeldprojecten en criteria bekijken lezen en/of printen van detailinformatie
opvragen (downloaden) subsidieformulier verzenden per post
behandelen schriftelijke aanvraag
behandelen online aanvraag
verzenden online
behandelen telefonische aanvraag
kernprocessen subsidieverlening vaststellen subsidiebudgetten en bekendmaking
verwerken aanvraag
verlenen
bewaken voortgang
afwikkelen subsidieprojecten
Figuur 7: Klantvraaggestuurd procesontwerp
Op basis daarvan is uiteindelijk een breed gedragen concept-plan van aanpak met ontwerpcriteria, nieuwe procesmodellen, de verwachte effecten, een begroting en planning van de onderscheiden deelprojecten opgeleverd, dat dezer dagen wordt geïmplementeerd. Toepassing van het model bij het ontwerp van generieke voorzieningen in een keten Om elektronische gegevensuitwisseling tussen de administratie van bedrijven en de administratie van de overheidsinstellingen mogelijk te maken moeten in de hele keten de daarvoor benodigde voorzieningen worden gecreëerd. Dit betreft enerzijds infrastructurele voorzieningen (ten behoeve van o.a. gegevenstransport, registratie en beveiliging); anderzijds de diensten zelf (berichtenservices) die door de ketenpartners via de infrastructuur geleverd en afgenomen zullen worden. Alleen als beide soorten voorzieningen tot stand worden gebracht, en in de gehele keten geaccepteerd en geïmplementeerd, wordt het voor betrokken partijen interessant om te investeren in de nieuwe shared services. Na inventarisastie van de IST-architectuur resulteerde eenvoorstel voor een communicatieinfrastructuur die bestaat uit de volgende voorzieningen:
11
-
-
het Bedrijvenloket: één virtueel loket waar de ondernemer, op een overzichtelijke en samenhangende manier, informatie en diensten van de overheid worden aangeboden; de OverheidsTransactiePoort (OTP): één adres waar de ondernemer zijn gegevens elektronisch naar kan verzenden. De OTP zorgt er vervolgens voor dat de benodigde informatie op een intelligente en veilige manier bij verschillende overheidsinstanties terecht komt; het BasisBedrijvenRegister: één register waar de identificerende kerngegevens van alle bedrijven in vastliggen.
Bij realisatie van deze infrastructuurarchitectuur weet de overheid zeker welk bedrijf zich meldt, kan informatie over en met dat bedrijf gemakkelijker worden uitgewisseld en wordt de ondernemer dus ook minder vaak lastig gevallen met vragen. Het woord 'infrastructuur' wekt licht de suggestie dat het hier alleen zou gaan om harde ‘techniek’. Het realiseren van deze infrastructurele voorzieningen als shared service betreft echter ook minder tastbare zaken als wederzijdse afspraken, standaarden, softwarefuncties, databases, en gestructureerde manieren om informatie te ontsluiten. De vergelijking met een weg of een kabel gaat wel op in de zin dat ook deze voorzieningen een collectief karakter hebben; ze hoeven maar één keer 'geproduceerd' (bedacht, ontwikkeld en gebouwd) te worden, en vervolgens kunnen alle overheidsorganisaties en andere ketenpartners er gebruik van maken. In onderstaande figuur is aangegeven hoe de beoogde voorzieningen samen een architectonisch geheel zullen vormen. Front-offices (portalen)
Bedrijven
Applicatie bedrijf X
loket
Transactie Toegangspoort: - authenticatie - beveiliging - berichtenservices
Overheidstransactiepoort (OTP)
Authentieke registratie Back offices instanties
Andere portalen
BBR
KvK
Belastingdienst
CBS
UWV
Andere organisaties
Figuur 8: Schets van de architectuur voor de communicatie bedrijven - overheid
Business case bepaalt invulling concrete architectuurmodel De kern van architectuurdenken is en blijft: samenwerken waar samenwerking in processen en delen van resources en systemen mogelijk, nodig en nuttig is. ‘Samenwerken’, en zeker (nood)gedwongen samenwerking, roept in overheidsland echter onmiddellijk beelden op van centralisatie versus decentralisatie, van standaardisatie versus diversificatie, van inperking van eigen beleidsvrijheden dus. Het is van belang te benadrukken, dat het voorgestelde integrale architectuurmodel géén dwangbuis is, die per se dwingt tot een bepaalde keuze voor één gedeelde architectuur, systeem, of leverancier. Men kan het model gebruiken voor het beschrijven van een taakgerichte, BU- of concernmodel-gebaseerde architectuur, men kan er een ERP of een webservices architectuur mee schetsen en definiëren, een Oracle, een DotNet of open source oplossing. En ook de bestaande situatie kan effectief beschreven en geanalyseerd worden.
12
Van belang is alleen dat bij het ontwikkelen en beschrijven de IST- én de SOLL-architectuur vanuit alle views en de onderlinge vraag- en aanbodrelaties geëxpliciteerd én geïntegreerd worden. Zelfs een bewuste keuze om voorlopig alleen de technische infrastructurele lagen/voorzieningen opnieuw te ontwerpen, bijvoorbeeld omdat de organisatie echt nog niet toe is aan de hogere niveaus/fasen, wordt op deze manier beter onderbouwd en resulteert in een flexibeler oplossing. Met andere woorden, de best haalbare business case in een bepaalde situatie bepaalt ook de best haalbare concrete invulling van de architectuur. Op basis van de twee dimensies centralisatie/decentralisatie en standaardisatie/ diversificatie, onderscheidt bijvoorbeeld van Venrooy6 in een onlangs verschenen proefschrift vier mogelijke ‘arrangementen’ voor de realisatie van e-government samenwerking: het autonomiemodel, het concentratiemodel, het franchisemodel en het uitwisselingsmodel. Het autonomiemodel gaat uit van een situatie waarin de betreffende problemen het beste decentraal en ‘gelokaliseerd’, zo dicht mogelijk bij de betrokkenen kunnen worden aangepakt. Wanneer het bijvoorbeeld puur gaat om 1-op-1 dienstverlening aan burgers en bedrijven, bij gemeenten of waterschappen, kan het beleid ook het beste lokaal ontwikkeld en uitgevoerd worden, zonder al te veel ‘medebewind’ van boven. De rol van een centrale autoriteit (bijv. departementen, provincies of de Unie van Waterschappen) kan in dit model beperkt blijven tot die van kaderstelling, stimulering en facilitering. Er hoeft dan nauwelijks sprake te zijn van standaardisatie; maar er is dan dus ook nauwelijks sprake van rationalisatie op nationale schaal. Het concentratiemodel vertegenwoordigt het andere uiterste op de twee dimensies. Lokalisatie, zeker van de back offices, maar eigenlijk ook van front offices (één-loket), is dan niet langer noodzakelijk; alle lokale relaties kunnen immers efficiënter en effectiever vanuit één of een beperkt aantal centrale back en/of front offices gefaciliteerd worden. Lokale front offices, zo ze er nog zijn, zijn niet meer dan dat: loketten met een voor het specifieke domein relevante geografische spreiding en dichtheid (denk aan de huursubsidie, of het uitreiken van rijbewijzen). Gegevens en processen zijn landelijk sterk gestandaardiseerd én gerationaliseerd. Het franchisemodel gaat niet uit van centralisatie, maar beperkt zich tot standaardisatie. Produkten, gegevens en processen zijn gestandaardiseerd, en gezamenlijk door franchisor en franchisees gerationaliseerd via gezamenlijk gefinancierde en ontwikkelde, maar lokaal geïmplementeerde en onderhouden systemen Als voorbeeld kan de huidige GBA gelden, of de Ict-Services Coöperatie van de politie. Een aanzet tot deze franchisegedachte kan de groeiende gegevensstandaardisatie in de watersector genoemd worden. In gemeenteland is onlangs het potentieel verder reikende ‘Egem’ initiatief ontstaan, dat ook als franchisor zou kunnen gaan optreden. Het uitwisselingsmodel tenslotte is het - minimale – koppelmodel van de ELOreferentiearchitectuur. Er is wel sprake van standaardisering, maar eigenlijk alleen van de communicatieprocedures, formats en protocollen (het ‘stekker’ concept). Het primaire doel is interconnectiviteit en interoperabiliteit tussen autonome systemen realiseren (zie bijv ook RINIS in het SOFI-domein7). Het moge duidelijk zijn, dat – bijvoorbeeld bij verschillende soorten taken in één organisatie belegd – niet zelden een combinatie van verschillende architectuurmodellen de meest 6
Nieuwe vormen van interorganisationele dienstverlening, A. van Venrooij , 2002 , isbn 90 5166 905. Vergelijk met gelijksoortige indeling in het BZK-referentiemodel! 7 RINIS faciliteert de gegevensuitwisseling tussen organisaties op het terrein van sociale verzekeringen, heeft daartoe communicatiestandaarden en protocollen vastgesteld en verzorgt conversie , technische uitwisselingsprotocollen, routeringsprocedures etc.
13
optimale oplossing zal zijn. Volledige centralisatie – zoals bij de huursubsidie, of door uiteindelijk alle waterschappen-back offices van Nederland te doen fuseren – zal geen recht kunnen doen aan lokale belangen, aan lokale informatie- en inspraakbehoeften. Voor optimale lokale interactie van overheden met ‘de klant’ komen het autonomie- of franchisemodel eerder naar voren. Maar voor integraal kwantitatief waterbeheer ligt dat weer anders, net als voor rampenbestrijding. Daar is een concentratie- of tenminste uitwisselingsmodel noodzakelijk. Bij het ontwikkelen van ‘e-government’ architecturen is het dus van belang te bepalen welke beste ‘’business cases’’ kunnen worden ontwikkeld. Per business case kan een ander architectuurmodel voor de optimale belegging van taken, processen en domeinen gekozen worden. Op basis daarvan kunnen vervolgens prioriteiten worden gesteld in het te ontwikkelen beleid8. Doordat, en juist doordat, moderne technologie een aantal beperkingen van tijd en plaats kan opheffen is het zo goed mogelijk vanuit één architectuurconcept zowel autonome, lokale overheidsorganisaties een relevante rol, plaats en functie te geven, als toch back office dan wel front office processen ( en gegevens, en systemen, en diensten) te standaardiseren en eventueel zelfs centraal te faciliteren. Daarbij is wel nodig, dat de verantwoordelijken gezamenlijk de hoofdzaken en bijzaken onderscheiden; bijvoorbeeld door te erkennen dat men op beleid moet concurreren, en niet op omvang, op techniek of beheer daarvan. Dat men bepaalde taken best zou kunnen afstoten c.q. overlaten aan netwerk- of keten-partners, die daarvoor bij uitstek geëquipeerd zijn. En ook dat bepaalde generieke activiteiten (zoals bijv. het opzetten en bijhouden van klantenregistraties, i.c. persoonsregistraties) niet op 600 plaatsen hoeven te worden ontwikkeld en onderhouden, laat staan ‘vernieuwd’ – daarvoor komt de ‘authentieke registratie’ meer in aanmerking9. Tot slot: de business case voor het werken met architecturen Zoals in het begin van dit artikel al werd opgemerkt, bestaat er vooral bij het management de nodige skepsis over nut en noodzaak van architectuur. Werken met architectuurconcepten biedt de organisatie vele voordelen, zo wil dit artikel aantonen. Denken in architecturen biedt een instrumentarium, dat in vele contexten met vrucht ingezet kan worden. Van groot belang is het besef, dat elke bestaande organisatie reeds een bepaalde architectuur heeft. Er is immers al een missie, een organisatiemodel, er zijn processen, gegevens, applicaties en een technische infrastructuur. Door deze allereerst te inventariseren en beschrijven blijkt meestal ook snel, dat en hoe een verbeterde architectuur een positieve bijdrage kan leveren aan de werkwijze en prestaties van de organisatie. Effectievere organisatieontwikkeling Het expliciteren van bestaande bedrijfs- en procesarchitecturen geeft vaak (onverwachte) inzichten in historisch gegroeide ‘onveranderbare’ situaties. Beschrijving van bestaande architecturen geeft een overtuigend inzicht in botsende dan wel overlappende verantwoordelijkheden en redundante processen, waar door samenwerking en consolidatie een forse vermindering van complexiteit én kostenreducties gerealiseerd zouden kunnen worden. Dit geldt voor explicitering van alle views, van die van de externe klant tot en met die van processen, gegevens, de hardware, middleware en applicaties.
8
zie ook: Lasance en Mulder, E-government kan verdere uitholling posities waterschappen voorkomen, B&G december 2002 9
zie het programma Stroomlijning BasisGegevens
14
Effectievere portfolio management, verstandig omgaan met legacy applicaties Door het expliciteren van het O&I deelbestek ‘applicaties’ wordt ook als het ware een landkaart van applicatiesystemen beschreven (zowel qua ist- als qua soll-situatie). Werken met architectuur zal zo ook actieve en effectieve ICT-portfoliomanagement ondersteunen. Een goede architectuurbeschrijving selecteert en definieert immers ook steeds ‘best practices’ en bouwt voort op inzichten die hun waarde hebben bewezen. Beter beredeneerde keuzes voorkomen verkeerde of dubbele investeringen, en door integratie, c.q. het voorkomen van redundanties worden besparingen gerealiseerd. In veel organisaties en ketens is de bestaande portfolio aan applicaties en infrastructurele voorzieningen dermate complex geworden dat onderhoud, aanpassingen en zeker vervanging ontzettend duur zijn geworen, heel veel tijd en moeite vergen, en de feitelijke mogelijkheden tot innovatie sterk beperken. Het reduceren van die complexiteit is inmiddels een key issue. Migreren naar een compleet nieuwe doelarchitectuur, zo wijst de praktijk uit, is vaak een zeer langdurig, kostbaar en risicovol traject. Met het architectuurconcept in de hand is het heel goed mogelijk na inventarisatie en beschrijving van de bestaande situatie redundante, niet gebruikte, of dure componenten geleidelijk op te ruimen of af te bouwen, c.q. effectiever in te zetten als generieke service. Een dergelijke architectonische benadering kan leiden tot complete legacy-ontmanteling, of kan door componentisering of wrapping soms zelfs de levensduur van systemen verlengd worden. Flexibelere en beter onderhoudbare ict-systemen en infrastructuren Binnen de geïntegreerde architectuur blijft de techniek haar kernrol vervullen. Adequate enterprise wide technology architecturen (EWTA’s) definiëren gemeenschappelijke en specifieke middelen inclusief rollen en verantwoordelijkheden daaromheen in een overkoepelende technische architectuur. Door een zorgvuldige balans tussen gemeenschappelijkheid en specificiteit worden de grenzen tussen opdrachtgever- en opdrachtnemerschap helder gemaakt, en wordt uiteindelijk ook het onderhoud van ictsystemen verbeterd. Een expliciet geregisseerde keuze voor beperkte sets technische (systeem)standaarden zal bovendien ook de opleidings- en inleertijd en de bijbehorende kosten verlagen. Betere bewaking van kosten en baten Een kosten- en batenmodel, waarin de financiële gevolgen van keuzen wordt aangegeven, is een wezenlijk onderdeel van elke (Ist en Soll) architectuurbeschrijving. Een effectief dynamisch en continu architectuur-managementprogramma maakt altijd de gevolgen van keuzen expliciet en inzichtelijk, zowel kwalitatief als kwantitatief. Daardoor wordt een betere afweging tussen kosten en baten mogelijk. Last but not least: samenwerken en excelleren De kern van architectuurdenken is samenwerking. Overheden, afdelingen of diensten moeten beseffen dat zij niet elk voor zich alle mogelijke loketten, taken, processen, gegevens en bijbehorende instrumentatie in stand hoeven te houden. In een modern overheidsnetwerk bepaalt men gezamenlijk wat generiek en wat specifiek is, en verdeelt men vervolgens de taken op basis van kerncompetenties. Samenwerken gaat niet vanzelf. Het is altijd ingewikkeld, en het lijkt vaak de autonomie aan te tasten. Maar samenwerken kan ook als resultaat hebben, dat je eindelijk kan focussen op en excelleren in je kerntaken, doordat je secundaire taken overlaat aan de daartoe meest geschikte netwerkpartner. Arne Lasance is zelfstandig adviseur.
Email:
[email protected]
15
