ICT-Architectuur

Tekst groter

ICT-Architectuur

Het belang van architectuur

Architectuur in de context van informatievoorziening en ICT noemen wij digitale architectuur. Kort gezegd is architectuur een manier om inzicht te krijgen en structuur aan te brengen in de informatievoorziening en ICT binnen een organisatie, en een manier om die te kunnen besturen. Uiteindelijk gaat het erom te begrijpen waarom de informatievoorziening is opgebouwd zoals ze is opgebouwd, te beschrijven hoe de verschillende onderdelen zijn opgebouwd en met elkaar samenhangen, en te besturen hoe dat zich in de tijd gezien ontwikkelt.

Om uit te leggen wat we daar nu precies onder verstaan, gaan we eerst in op de concrete vraagstukken die er in organisaties spelen en de bijdrage die een architectuur aan de oplossing van deze vraagstukken levert. Een architectuur is immers geen doel op zich, maar een middel om problemen op te lossen.

De architectuur heeft ook een belangrijk relatie met de strategie van een organisatie. Hoewel ICT niet voor elke organisatie even strategisch is, is architectuur altijd een middel om de samenhang tussen de bedrijfsstrategie, informatievoorziening en ICT inzichtelijk te maken.

Hoe groter het belang van ICT is, hoe meer impact ze zal hebben op de inrichting van de organisatie, de bedrijfsprocessen of zelfs de producten en diensten van een organisatie.

Tekst groter

De term architectuur wordt in verschillende betekenissen gebruikt. Men spreekt bijvoorbeeld van architectuur als men de gehele organisatie bedoelt waar de ICTvoorzieningen een onderdeel van zijn, maar het kan ook gaan over de architectuur van één enkele applicatie. Of over een of meer deelaspecten, zoals bedrijfsprocessen,gegevens, applicaties of de technische opbouw van software. Twee dingen hebben al deze vormen van architectuur met elkaar gemeen: ze geven inzicht in de complexiteit, functies en samenhang van een organisatie en/of haar ICT. Én een architectuur is een blauwdruk, haar doel is richting te geven aan toekomstige ontwikkelingen.

Het gaat er in een architectuur steeds om, te begrijpen waarom de informatievoorziening is opgebouwd zoals hij is opgebouwd, te beschrijven hoe de verschillende onderdelen zijn opgebouwd en met elkaar samenhangen, en te besturen hoe dat zich in de tijd ontwikkelt.

Omdat het woord architectuur in relatie tot informatievoorziening in veel betekenissen wordt gebruikt kiezen we voor een driedeling in drie fundamenteel van elkaar verschillende typen architectuur.

  • Een enterprisearchitectuur richt zich op de samenhang tussen de bedrijfsprocessen, functionaliteit, applicaties en technische infrastructuur binnen de organisatie als geheel.
  • Een softwarearchitectuur richt zich juist op de afzonderlijke systemen en brengt van deze systemen de opbouw en structuur in beeld.
  • Zowel voor enterprisearchitectuur als voor softwarearchitectuur geldt dat de principes van een service-georiënteerde architectuur hierop van toepassing kunnen zijn.
Tekst groter

Welke problemen willen we oplossen?

We schetsen hier een aantal vraagstukken die in veel organisaties rond informatievoorziening en ICT spelen. Dit zijn vooral vraagstukken waarin de noodzaak tot verandering een rol speelt, en de samenhang tussen bedrijfsprocessen, informatiesystemen en technologie.

Eilandautomatisering

Vaak is in organisaties in de loop der jaren op vele plaatsen ICT ingezet om bedrijfsprocessen effectiever en efficiënter te ondersteunen. Deze ICT voorzieningen waren vooral gericht op de lokale ondersteuning van een of enkele bedrijfsprocessen. In eerste instantie zijn deze voorzieningen ingericht als losse ‘eilanden’ van automatisering. Met de steeds toenemende functionele en technische mogelijkheden van deze systemen ontstaan er in de loop der tijd gegevensuitwisselingen tussen de verschillende systemen en maken gebruikers steeds vaker gebruik van een combinatie van systemen.

De complexiteit van deze situatie neemt toe naarmate er meer koppelingen tussen deze, van oorsprong als eiland ingerichte, systemen worden gelegd. Dit wordt nog versterkt wanneer de bedrijfsprocessen anders worden ingericht waardoor processen door een combinatie van systemen worden ondersteund. Veel organisaties maken een ontwikkeling door waarbij ze van een productgerichte naar een dienstgerichte structuur gaan. Met thema’s als ‘de klant/patient/leerling/burger centraal’ worden bedrijfsprocessen als het ware gekanteld. Dit levert een enorme uitdaging op aan de kant van de ICT ondersteuning, want de systemen zijn daar niet op ingericht.

Beheersing van de kosten

In het verlengde van de hiervoor geschetste eilandautomatisering doet zich bij veel organisatie ook een probleem van kostenbeheersing voor. Een versnipperd applicatielandschap is zodanig complex dat kosten voor de instandhouding zeer hoog zijn. Wijzigingen kunnen met steeds meer moeite worden doorgevoerd, waardoor in de praktijk nagenoeg alle aandacht, tijd en geld wordt besteed aan beheer en slechts een beperkt deel aan verbeteringen en vernieuwing. Naarmate systemen langer in gebruik zijn neemt de complexiteit toe.

Waarborgen van de continuïteit

Wanneer een organisatie een langere tijd gebruik maakt van ICT voorzieningen is vaak ook de complexiteit van deze voorzieningen in de loop der jaren toegenomen. Door die complexiteit neemt het aantal storingen toe en ontstaan er risico’s voor de continuïteit.

Nog los daarvan kan de levensduur van systemen om verschillende redenen eindig zijn. Systemen kunnen zijn gebaseerd op technologie die niet meer gangbaar is in de markt, waardoor integratie met andere systemen of gebruik van modernere infrastructuur niet meer mogelijk is. Bij pakketoplossingen kan een leverancier om verschillende redenen besluiten het onderhoud te beëindigen.

Reageren op veranderingen in de markt Iedere organisatie moet zich aanpassen aan veranderingen in de markt. Dit is een continu strategisch proces. Het kan gaan om veranderende marktomstandigheden voor wat betreft concurrentie, wetgeving, kostenontwikkelingen, innovatie in de sector etc. Specifiek met betrekking tot ICT kunnen nieuwe ICT ontwikkelingen voor organisaties aanleiding zijn voor, soms zeer ingrijpende, strategische veranderingen.

Om op die veranderingen te kunnen inspelen zal een organisatie zijn bedrijfsprocessen, producten en diensten en organisatieinrichting willen aanpassen. Het is daarbij cruciaal, of de ICT voorzieningen met die verandering kunnen meebewegen en of de ICT voorziening zelfs een ‘enabler’ voor deze verandering kunnen zijn. Vaak doet zich het probleem voor dat de ICT voorzieningen een belemmering zijn voor de gewenste veranderingen doordat wijzigingen niet snel genoeg kunnen worden doorgevoerd of omdat de risico’s van zo’n verandering onvoldoende beheersd kunnen worden.

Samenwerkingen of fusies

Een hele andere uitdaging voor organisaties is de samenwerking of zelfs fusie met een organisatie waarvan de ICT voorzieningen zich onafhankelijk van elkaar hebben ontwikkeld. Net als bij een reactie op veranderende marktomstandigheden zal een samenwerking of fusie leiden tot aanpassingen van bedrijfsprocessen, producten en diensten, en organisatieinrichting. Daar komt alleen nog bij dat de twee verzamelingen van ICT voorzieningen in meer of mindere mate in elkaar geschoven moeten worden.

Het in elkaar schuiven van de ICT voorzieningen kan op allerlei manieren: door voor elke situatie de beste oplossing te selecteren, daar de omgeving van de ene organisatie te laten opgaan in de andere, Kennisbank | 9 maart 2015 | Pagina 33/59 of door te accepteren dat verschillende systemen naast elkaar blijven bestaan. De haalbaarheid en consequenties van deze opties is voor samenwerkende of fuserende organisatie erg ingewikkeld.

De hier geschetste vraagstukken zijn wat ons betreft exemplarisch voor de uitdagingen waarbij architectuur een belangrijke bijdrage in de oplossing kan leveren.

Tekst groter

Hoe draagt architectuur bij aan het oplossen van deze problemen?

Hiervoor is een aantal vraagstukken geschetst waarbij architectuur een belangrijke bijdrage in de oplossing kan leveren. De vraag is uiteraard: hoe dan? Wat is de toegevoegde waarde van architectuur bij dit soort vraagstukken?

Op hoofdlijnen kan de toegevoegde waarde van architectuur worden samengevat in vijf kernbegrippen:

  • Inzicht in samenhang
  • Creëren van flexibiliteit
  • Sturen op integratie en standaardisatie
  • Beheersing van risico’s
  • Beheersing van kosten.

Deze vijf aspecten worden hieronder toegelicht.

Samenhang

In de eerste plaats geeft een architectuur inzicht in de samenhang tussen allerlei aspecten van de informatievoorziening, zoals bedrijfsprocessen, functionaliteiten, applicaties en technische infrastructuur, maar ook bijvoor-beeld tussen de verschillende onderdelen van een concrete applicatie.

Daarom wordt in een architectuur inzichtelijk gemaakt uit welke componenten al die verschillende onderdelen van de informatievoorziening zijn opgebouwd, waarom die componenten er zijn, en welke uitgangspunten en spelregels er gelden voor de doorontwikkeling van die componenten.

Dit inzicht in samenhang stelt een organisatie in staat om te beoordelen hoe de ICT voorzieningen de bedrijfsprocessen ondersteunen, hoe de verschillende onderdelen van elkaar afhankelijk zijn en wat de impact van veranderingen is.

Flexibiliteit

Een tweede cruciaal aspect van architectuur is dat deze zodanig wordt opge-bouwd dat er voldoende flexibiliteit is om toekomstige veranderingen op te kunnen vangen. De informatievoorziening moet kunnen reageren op gewijzigde omstandigheden en nieuwe kansen in het primaire proces.

Het gaat dan bijvoorbeeld om de opbouw en ordening van bedrijfsprocessen, de ordening van functionaliteiten, de applicaties die die functionaliteiten leveren en de technische componenten waaruit die applicaties zijn opgebouwd. De mate waarin dit flexibel is, is bijvoorbeeld te beïnvloeden door ervoor te zorgen dat onderdelen kunnen worden hergebruikt en dat onderdelen niet te veel van elkaar afhankelijk zijn maar wel kunnen samenwerken.

Integratie en standaardisatie

Een effectieve informatievoorziening vertaalt zich in veel gevallen in de wens tot meer standaardisatie en integratie. Standaardisatie betekent dat bedrijfsprocessen over verschillende bedrijfsonderdelen heen worden gestandaardiseerd zodat ook de ICT ondersteuning daarvan kan worden. gestandaardiseerd. Deze gestandaardiseerde processen kunnen vervolgens ook snel gerepliceerd worden.

Integratie betekent dat gegevens en functies beschikbaar komen voor alle bedrijfsonderdelen, en in alle bedrijfsprocessen waar deze nodig zijn.

Het is voor veel organisatie een belangrijke strategische keuze in welke mate standaardisatie en integratie wordt nagestreefd. Als deze keuze gemaakt is helpt de architectuur om dit waar te maken. [Ross/Weill/Robertson, 2006]

Risicobeheersing

Bij beheersbaarheid gaat het er vooral om dat je weet wat je aan ICT voorzieningen hebt, en weet wat daarbij de eventuele risico’s zijn. Wanneer dat inzichtelijk is, is het mogelijk om maatregelen te nemen die deze risico’s beperken.

Kostenbeheersing

Tot slot is architectuur een belangrijk instrument dat ervoor zorgt dat gefundeerd keuzes kunnen worden gemaakt over investeringen en verandering van de ICT voorzieningen. Gefundeerd keuzes maken kan alleen als inzichtelijk is uit welke onderdelen de ICT voorzieningen zijn opgebouwd, hoe deze met elkaar samenhangen en wat de impact van wijzigingen is. Dit zorgt er ook voor dat een organisatie zelf de regie kan houden op wijzigingen van de ICT voorzieningen.

Tekst groter

Enterprise architectuur

Enterprisearchitectuur richt zich op de samenhang van het totaal aan softwareproducten binnen een organisatie en de bedrijfsprocessen die ze ondersteunen, met andere woorden op de samenhang tussen de bedrijfsprocessen, functionaliteit, applicaties en technische infrastructuur binnen een organisatie als geheel.

Een enterprisearchitectuur is een strategisch instrument om beslissingen over ICT in een organisatie weloverwogen en in samenhang te kunnen nemen (Ahlemannet al. (2012); Slot, 2010; Ross, Weill en Robertson, (2006); Boterenbrood, Hoek en Kurk, 2005; Schekkerman, 2005). Daarmee is enterprisearchitectuur ook een belangrijk instrument voor het realiseren van alignment tussen organisatie en ICT, het optimaliseren van de bijdrage van ICT aan de doelstellingen van de organisatie. De toegevoegde waarde voor een enterprisearchitectuur specifiek wordt hieronder kort samengevat.

Tekst groter

Wat is enterprisearchitectuur?

Onder enterprisearchitectuur wordt een architectuur verstaan die een gehele organisatie omvat. Een enterprisearchitectuur beperkt zich niet tot het technische of ICT-domein (functionaliteit, applicaties en infrastructuur), maar maakt juist verbinding met het organisatiedomein, met bedrijfsprocessen, organisatiestructuur, producten en diensten. De ervaring heeft geleerd dat er voor succesvolle toepassing van ICT in een organisatie meer nodig is dan alleen de implementatie van die technologie het gaat om verandering van de organisatie waar ICT deel van uitmaakt. Bovendien is ICT steeds meer een ‘enabler’ van die organisatieverandering en -vernieuwing. Een enterprisearchitectuur is daarom ook niet als een eendimensionale architectuur te beschrijven. Essentieel is dat dit wordt gezien als één consistente enterprisearchitectuur waar je vanuit verschillende invalshoeken naar kunt kijken.

Een enterprisearchitectuur heeft een dubbel doel. Enerzijds is het een communicatie-instrument om de samenhang tussen al deze aspecten inzichtelijk te maken. Daarom wordt in een enterprisearchitectuur vaak veel aandacht aan de vormgeving besteed; het is immers een communicatiemiddel om iets wat complex is inzichtelijk te maken. Anderzijds is een enterprisearchitectuur ook een sturingsinstrument. De modellen, principes en richtlijnen vormen kaders voor veranderingen die in de loop van de tijd in bedrijfsprocessen, functionaliteit, applicaties en infrastructuur worden doorgevoerd.

Als definitie van een enterprisearchitectuur gaan we uit van een variant op de definities in Lankhorst et al. (2005) en IEEE (2000):
een enterprisearchitectuur is een verzameling modellen, principes en richtlijnen waarin de structuur, processen, functionaliteit, applicaties en infrastructuur van een organisatie als geheel inzichtelijk worden gemaakt. Deze modellen, principes en richtlijnen brengen de fundamentele inrichting van organisatie en ICT in beeld en sturen de doorontwikkeling daarvan in de tijd.

Tekst groter

Deelarchitecturen

Enterprisearchitectuur richt zich op de gehele organisatie. Het gaat in een enterprisearchitectuur niet om de afzonderlijke systemen, maar juist om de samenhang tussen bedrijfsprocessen, producten en diensten, functionaliteit, applicaties en technische voorzieningen in een organisatie. Binnen de enterprisearchitectuur worden vaak verschillende deelarchitecturen onderkend. Wij onderscheiden de volgende vier:

  • Businessarchitectuur geeft inzicht in de inrichting van de bedrijfsprocessen en hun onderling relaties, en de relaties met de processen in de omgeving (keten) van de betreffende organisatie.
  • Informatiearchitectuur geeft inzicht in de samenhang tussen de functionaliteit (functionele gebieden), hun onderlinge afhankelijkheden en gegevensstromen.
  • Applicatiearchitectuur geeft inzicht in de concrete applicaties en hun onderlinge relaties.
  • Technische architectuur brengt de echt fysieke aspecten, de technische infrastructuur in beeld, zoals de hardware en netwerken.
Tekst groter

Software architectuur

Softwarearchitectuur heeft betrekking op de architectuur van een enkel systeem of een verzameling gerelateerde systemen. Softwarearchitectuur is sterk gerelateerd aan het vakgebied van software engineering, het ontwikkelen van complexe ICT-systemen. Het is dus letterlijk de architectuur van de software, de opbouw en samenhang van de verschillende onderdelen en aspecten van één softwareproduct.

Veelal is de softwarearchitectuur van een systeem opgebouwd uit lagen of componenten die de verschillende aspecten belichten, zoals het statische (structuur) en het dynamische aspect (gedrag). De softwarearchitectuur wordt ook wel gekenschetst als de blauwdruk voor het (meer gedetailleerde) ontwerp van het betreffende softwaresysteem.

De toegevoegde waarde voor een softwarearchitectuur specifiek wordt hieronder kort samengevat.

Tekst groter

Service georiënteerde architectuur

Een service-georiënteerde architectuur is eigenlijk geen concrete architectuur, maar een verzameling concepten waarop een concrete architectuur gebaseerd kan worden. Deze concepten kunnen worden toegepast in het ontwerp van een concrete applicatie, maar vormen ook een belangrijke basis voor de inrichting van de informatievoorziening en de bedrijfsprocessen in een organisatie als geheel. Daarom worden de concepten van een service-georiënteerde architectuur hier neergezet als de conceptuele basis voor zowel een enterprise- als softwarearchitectuur.

Een service-georiënteerde architectuur (afgekort als SGA of internationaal als SOA, Service Oriented Architecture) wordt nogal eens neergezet als de ultieme oplossing voor integratieproblemen, omdat ze systemen optimaal laat aansluiten op en meebewegen met de bedrijfsprocessen in een organisatie (Van den Berg, Bieberstein en Van Ommeren, 2007). In dit hoofdstuk willen we laten zien dat een service-georiënteerde architectuur vele aspecten kent die je niet zomaar even kunt implementeren – een service-georiënteerde architectuur kun je niet kopen (Josuttis, 2007). Bepaalde aspecten zijn een doorontwikkeling van concepten die al veel langer bestaan, andere aspecten zijn wat fundamenteler van aard. In dit hoofdstuk worden deze aspecten in samenhang toegelicht.

De toegevoegde waarde voor een service georiënteerde architectuur specifiek wordt hieronder kort samengevat.

Tekst groter

Service-georiënteerde architectuur is een breed concept, waar je vanuit verschillende invalshoeken naar kunt kijken. Wij kiezen ervoor om vooral het technische en organisatorische perspectief naast elkaar te zetten.

Vanuit een technisch perspectief is een service-georiënteerde architectuur een architectuur waarin functionaliteit in de vorm van services aan de gebruikers beschikbaar wordt gesteld. Die services zijn relatief zelfstandige stukken software die gestandaardiseerd kunnen worden gebruikt. De technologie van webservices is hierbij de meest gebruikte (maar niet de enig denkbare) technische implementatie.

Vanuit organisatorisch perspectief is het concept veel breder. Het vertrekpunt is dan de geïntegreerde ondersteuning van de bedrijfsprocessen. Die bedrijfsprocessen zijn opgebouwd uit diensten die door de verschillende afdelingen binnen de organisatie worden geleverd met als uiteindelijk doel het leveren van diensten aan klanten. De diensten waaruit de bedrijfsprocessen zijn opgebouwd, corresponderen met diensten die door informatiesystemen worden geleverd, waardoor de services in technische zin als het ware het spiegelbeeld zijn van de diensten waaruit de bedrijfsprocessen zijn opgebouwd.

Eigenlijk is dit organisatorische perspectief het werkelijk vernieuwende van het concept. Service-georiënteerde architectuur is een andere manier van inrichten van bedrijfsprocessen én de ICT-ondersteuning daarvan.

In een service-georiënteerde architectuur staat in ieder geval het concept service centraal. Een service is een zelfstandig stuk bedrijfsfunctionaliteit dat zowel een eenvoudige taak in het bedrijfsproces kan ondersteunen (zoals het registreren van een adreswijziging) als een compleet bedrijfsproces (zoals het verlenen van een subsidie). Een service moet een voor de gebruiker betekenisvolle dienst leveren. Daarnaast is het belangrijk dat een service zo zelfstandig mogelijk kan functioneren. Services maken uiteraard van andere services gebruik, maar zijn daarbij zo losjes mogelijk gekoppeld. Deze eigenschap zorgt ervoor dat bedrijfsprocessen flexibel uit beschikbare services samengesteld kunnen worden.

In technische zin is interoperabiliteit een kernbegrip in een service-georiënteerde architectuur. Services kunnen door een veelheid van systemen worden geleverd. Deze systemen zijn vaak technisch in verschillende talen en ontwikkelomgevingen gebouwd. Heterogeniteit is in een service-georiënteerde architectuur een gegeven. Al deze services moeten naadloos met elkaar kunnen samenwerken om geïntegreerde ondersteuning van bedrijfsprocessen mogelijk te maken.

Voor het technische perspectief wordt ook vaak de term Service-Oriented Computing (SOC) gebruikt. Met deze term wordt met name de technische realisatie van een service-georiënteerde architectuur bedoeld, bijvoorbeeld in de vorm van webservices. Voor het organisatorische perspectief wordt ook vaak de term Service-Oriented Enterprise (SOE) gebruikt (Khoshafian, 2006). Daarbij ligt de nadruk op het op een service-georiënteerde manier inrichten van bedrijfsprocessen en het creëren van een ICT-ondersteuning die met de veranderingen in de bedrijfsprocessen kan meebewegen. Wij kiezen ervoor om dit geheel aan te duiden met de term service-georiënteerde architectuur (Service Oriented Architecture, SOA)

Tekst groter

Scenario’s voor integratie

Een belangrijk thema bij de migratie van de bestaande naar de gewenste situatie is de integratie van processen, applicaties en infrastructuur. De bestaande situatie kenmerkt zich bij organisaties vaak door geïsoleerde oplossingen voor de ondersteuning van bepaalde (delen) van bedrijfsprocessen op een specifiek daarvoor ingerichte infrastructuur. De uitdaging is vooral deze geïsoleerde oplossingen te integreren. Het einddoel is een naadloze ondersteuning van de bedrijfsprocessen te realiseren, ongeacht het feit dat de benodigde functionaliteit door een (groot) aantal applicaties geleverd wordt.

De integratie kan op verschillende archetypische manieren worden aangepakt. Welke aanpak gekozen wordt, is een kwestie van strategie. Elke aanpak leidt immers weer tot veel andere keuzes. Wij onderscheiden er drie. Integratie gaat ook over de grenzen heen. Hier staan we in de laatste paragraaf bij stil.

Tekst groter

Applicatie rationalisatie

In deze strategie wordt integratie bereikt door

  • Saneren van het aantal applicaties
  • Saneren van de diversiteit in technologie / platformen
  • Handhaven strategie van 1:1 koppelingen

In deze strategie wordt per situatie bekeken of integratie noodzakelijk is. Als dat het geval is, wordt in principe op maat een koppeling gerealiseerd.

Tekst groter

Deze aanpak is alleen werkbaar als het aantal koppelingen relatief beperkt is en als bedrijfsprocessen veelal door één enkele applicatie ondersteund worden. Soms wordt er nog wel gekozen voor standaardisatie op een bepaald technisch platform of bepaalde databasetechnologie.

Tekst groter

Best-of-breed-strategie

In deze strategie wordt integratie bereikt door:

  • Standaardiseren van de infrastructuur voor integratie
  • SOA principes toepassen
  • Applicaties geleidelijk opnemen in SOA infrastructuur
  • Saneren van applicaties blijft noodzakelijk

Bij deze aanpak is het uitgangspunt dat voor elke gewenste functionaliteit de oplossing uit de markt wordt geselecteerd (of in maatwerk wordt gerealiseerd) die het best past bij de functionele vraag. Tegelijkertijd wordt gewerkt aan voorzieningen om de gekozen oplossingen te integreren: een portaal en een enterprise servicebus.

Tekst groter

De enige randvoorwaarde die aan de oplossingen wordt gesteld is dat ze inpasbaar moeten zijn in de integratievoorzieningen. Vaak zal dit inhouden dat de applicaties bepaalde open standaarden ondersteunen en kunnen worden geïntegreerd in de gekozen oplossingen voor de enterprise servicebus, het portaal en eventueel een voorziening voor procesbesturing.

De ontwikkelingen rondom de verschillende platformen zoals het Java- en .NETplatform, en de ontwikkeling van open standaarden maken een best-of-breedstrategie steeds realistischer. Een bijkomend voordeel van deze strategie is dat je onafhankelijkheid van de leverancier relatief groot is.

Tekst groter

ERP-aanpak (Enterprise Resource Planning)

In deze strategie wordt integratie bereikt door

  • Fundamentele keuze voor één ERP platform
  • Rigoreuze vervangingsstrategie van bestaande applicaties
  • Implementatie van beleid ‘ERP pakket tenzij...’
  • Integratie wordt gerealiseerd d.m.v. het ERP pakket

In deze aanpak wordt gekozen voor één geïntegreerde pakketoplossing, veelal een ERP-pakket, op basis waarvan een groot deel van de gewenste functionaliteit geleverd kan worden. Uiteraard moet er in de markt wel een ERP-pakket beschikbaar zijn, dat een groot deel van de gewenste functionaliteit afdekt.

Tekst groter

ERP-pakketten zijn vaak gebaseerd op best practices bij de inrichting van bedrijfsprocessen en de bijbehorende informatievoorziening. Het succes van een ERP-aanpak wordt een stuk groter als je bereid bent de business- en informatiearchitectuur af te stemmen op de best practices die in het ERP-pakket zijn opgenomen.

In deze benadering worden niet bij voorbaat integratievoorzieningen ingericht. De onderdelen van de ERP-oplossing zijn immers al in het pakket geïntegreerd. Sommige ERP-pakketten hebben ook integratievoorzieningen (een servicebus, een portaal of procesbesturing) waarop ook andere applicaties kunnen worden aangesloten.

Dit leidt vaak tot een ‘ERP tenzij’-strategie, waarbij de voorkeur uitgaat naar oplossingen die binnen de ERP-suite beschikbaar zijn. Als dat niet het geval is, moet een oplossing in de integratievoorzieningen van het ERP-pakket geïntegreerd kunnen worden.

Tekst groter

Keuze van integratiestrategie

De vraag welke van de hiervoor beschreven integratiestrategieën de beste is, is moeilijk te beantwoorden. Dit zal per organisatie verschillen, afhankelijk van de diversiteit aan systemen en de mate waarin die geïntegreerd moeten worden.

Het verschil tussen deze strategieën is vooral de mate waarin het mogelijk is om integratie te bereiken, en de mate waarin er leveranciersafhankelijkheid ontstaat.

Tekst groter

Als er wordt gekozen voor applicatierationalisatie, dan ontstaat er nauwelijks een grotere leveranciersafhankelijkheid omdat de diversiteit aan applicaties en dus aan leveranciers in stand wordt gehouden. Maar de mate waarin integratie mogelijk is, is in dit scenario ook beperkt.

Als er wordt gekozen voor een best-of-breed aanpak, dan kan een grote mate van integratie worden bereikt terwijl toch de diversiteit aan applicaties in stand blijft. Er ontstaat alleen een afhankelijkheid van de leverancier van de integratieoplossingen (de servicebus en het portaal), maar deze afhankelijkheid is relatief beperkt. De diversiteit aan applicaties en keuze voor leveranciers kan voor een groot deel gehandhaafd blijven.

Met een ERP-aanpak kan de best geïntegreerde omgeving worden gerealiseerd, maar tegelijkertijd wordt een grote leveranciersafhankelijkheid geïntroduceerd en legt een organisatie zich grote beperkingen op in de keuze van applicaties.

Hieronder wordt dit in een afwegingskader weergegeven.

Tekst groter

Outsourcingstrategie

Een outsourcingsstrategie geeft antwoord op enkele logisch samenhangende vragen.

Waarom?

Waarom wordt outsourcen overwegen en welke doelen worden daarmee nagestreefd? Deze doelen hebben vaak betrekking op het volgende.

  • Tijd en resources vrijmaken om te focussen op kernactiviteiten.,
  • Kostenflexibiliteit, zodat de kosten mee kunnen bewegen met het daadwerkelijke gebruik
  • Reductie van operationele risico’s, met name met betrekking tot kennis, capaciteit en continuïteit
  • Zakelijke transparantie in de levering van IT diensten
  • Kostenbesparingen, hoewel deze vaak pas op de langere termijn haalbaar zullen blijken
Wat?

Hoe wordt het ICT landschap ingedeeld in kavels die als één geheel kunnen worden uitbesteed. Hiervoor gebruiken we een verkavelingsmodel, waarin het ICT landschap wordt ingedeeld naar

  • De verschillende onderdelen van de infrastructuur
  • De verschillende typen applicaties

Op basis daarvan kunnen combinaties van infrastructuur en/of applicaties gemaakt worden die samen een kavel vormen.

Wie?

De vraag die daarmee samenhangt is welke leveranciers de bij deze kavels behorende services kunnen leveren. Het behandelt dus globaal de vraag; met wie en op welke manier (volgens welk servicemodel) kunnen we uitbesteden?

Hoe?

Hierna wordt de vraag beantwoord welke weg je moet volgen vanaf het maken van een outsourcingsstrategie. Het gaat dan om het uitwerken van de aanpak voor de leveranciersselectie, de transitie en het managen van het contract.

Kan het?

Vervolgens is er de vraag of de organisatie in staat is om te outsourcen? Kan de organisatie het aan, zijn de kavels ontvlechtbaar, hebben we de bijbehorende kosten in beeld?”

Wanneer?

Tenslotte is de vraag wanneer en in welke volgorde je gaat outsourcen. Het antwoord daarop betekent het maken van een roadmap waarin de verschillende kavels in de tijd zijn uitgezet, en eventuele onderlinge afhankelijkheden zijn benoemd.

Tekst groter

Servicemodellen

Voor uitbesteding zijn verschillende servicemodellen denkbaar. In elke servicemodel is de dienst de een externe leverancier levert anders. De belangrijkste servicemodellen zijn de volgende

Cloud

‘Computing resources’ – of dat nu een complete applicatie, een aantal services of hardwarecapaciteit is – wordt beschikbaar gesteld, zonder dat bekend hoeft te zijn hoe en waar die services precies geleverd worden. Ze zijn gewoon beschikbaar ‘in de cloud’. Bij een echte cloud-dienst, zoals bijvoorbeeld bij mobiele apps of Office 365, heb je als gebruiker geen invloed op de doorontwikkeling.

SaaS (Software As A Service)

Bij SaaS biedt de leverancier een applicatie aan, inclusief alle bijbehorende infrastructuur en het beheer daarop. De klant weet niet op welk platform de applicatie draait, of waar de infrastructuur draait

PaaS (Platform as a Service)

Bij PaaS beheer je zelf de applicaties waarvan het platform in de cloud staat. Het platform komt als het ware ‘uit de muur’, als een standaardnutsvoorziening.

IaaS (Infrastructure as a Service)

Bij IaaS beheer je zelf wel de applicaties en het platform, maar heb je alleen de infrastructuur, de fysieke hardware in de cloud staan.

Zelf doen

In dit servicemodel neem je geen dienst van een externe leverancier af, maar beheer je zelf de applicatie en bijbehorende infrastructuur.

Ieder servicemodel (outsourcingsaanpak) stelt zijn eigen eisen aan de interne organisatie. Onderstaand model geeft inzicht in de processen (en dus de achterliggende interne organisatie) die intern geregeld moeten worden.

Tekst groter

Verkavelingsmodel

Om een goed beeld te krijgen van de mogelijk uit te besteden onderdelen van het ICT-landschap, de kavels en de volgorde waarin dat kan gebeuren, kan het onderstaand verkavelingmodel worden gebruikt. Hierin kunnen de mogelijk uit te besteden kavels in kaart worden gebracht.

In onderstaand voorbeeld zijn vier categorieën van applicaties benoemd, die in een specifieke situatie ook wat specifieker benoemd zullen kunnen worden. 

Tekst groter

Voorbeeld verkavelingsmodel

Wij onderscheiden in dit voorbeeld een aantal verticale kavels (kavel 1, 2 en 3), waarin één of meerdere applicatie inclusief de bijbehorende infrastructuur als één geheel worden beheerd. Dat kan dan volgens verschillende beheermodellen: zelf doen, Software as a Service of als Clouddienst. Daarnaast kunnen er ook horizontale kavels worden onderkend, zoals in dit voorbeeld kavel 5, de randapparatuur en mobiele devices. Een horizontale kavel biedt een generieke infrastructurele dienst ten behoeve van alle applicaties. Tenslotte kan er ook een combinatie van een horizontale en verticale kavel worden gemaakt. In dit voorbeeld is dat kavel 4, Werkplekken. Hierin worden de fysieke werkplekken en alle netwerkvoorzieningen (horizontaal) gecombineerd met alle standaardtoepassingen op de werkplek (verticaal).

De laatste jaren is een ontwikkeling zichtbaar van horizontale naar verticale uitbesteding. Traditioneel bieden dienstverleners van het beheer van het rekencentrum aan, zonder verantwoordelijkheid voor de applicaties die daar draaien. Tegenwoordig bieden dienstverleners steeds vaker een totaaldienst aan, als combinatie van functionaliteit en bijbehorende infrastructuur

Tekst groter

Referentiearchitectuur als onderlegger voor de strategische dialoog over ICT

Onder referentiearchitectuur verstaan we het geheel van principes, richtlijnen en/of voorbeelden op basis waarvan een organisatie een architectuur kan maken. Belangrijkste is vaak om hergebruik te maken van reeds opgedane kennis binnen een branche. Meest toegpaste referentiearchitectuur is NORA (Nederlandse Overheid Referentie Architectuur), omdat aan dit raamwerk (op elk van de vlakken van dit raamwerk) een aantal modellen, principes en richtlijnen zijn gekoppeld die kaderstellend zijn voor alle Nederlandse overheidsorganisaties (ICTU, 2009). Onderdeel van de NORA familie is GEMMA (GEMeentelijke Model Architectuur), PETRA (Provinciale EnTerprise Referentie Architectuur), WILMA (Waterschaps Informatie- en Logisch Model Architectuur). Er zijn ook referentiearchitecturen voor de woningcooperaties (CORA, COrporatie Referentie Architectuur), voor ziekenhuizen (referentiedomeinenmodel van Nictiz, of ROSA ( Referentie Architectuur Onderwijs) voor onderwijs.

Wat deze referentiearchitecturen gemeen hebben is dat voor een groot deel gebruikt en gericht zijn op mensen binnen een ICT-organisatie. Wij gebruiken referntiearchitecturen om een strategische dialoog te voeren over welke investeringen te doen in ICT.

Daarmee zijn onze referentiearchitecturen meer geënt op de belevingswereld van de bestuurders. Zoals de referentiearchitectuur voor onderwijs:

onderwijsreferentie.jpg

Of de referentiearchitectuur voor ziekenhuizen:

ziekenhuisreferentie.jpg

Op deze referentiearchitecturen staan de benodigde functionaliteit afgebeeld. Hiermee kunnen de volgende strategische dialogen gevoerd worden:

  1. Definitie van scope van een ERP of EPD programma
  2. Sanering van het ICT landschap om kosten te besparen, continuïteit te verhogen en integratie te vergemakkelijken
  3. Migratiepad voor de komende jaren te visualiseren
  4. Het matchen van de systeemportfolio bij fusies of intensieve samenwerking.

 

Ad 1.

Op de referentiearchitectuur kan het huidige applicatielandschap geplot worden én wat het ERP of EPD in potentie kan afdekken. Hiermee is duidelijk te zien waar overlap is en zo niet met welke systemen koppelingen ontwikkeld moeten worden. Zaken waar een bestuurder anders moeilijk grip op krijgt.

Ad 2.

Als de huidige portfolio aan systemen geplot wordt op de referentiearchitectuur én de kwaliteit van de systemen gemarkeerd wordt met een kleur is te zien waar mogelijk een overlap is in systemen en waar potentieel gesaneerd kan worden. Met de kleuren kan gekeken worden welke systemen bij voorkeur gesaneerd moeten worden. Een door ons gebruikte methode om de kwaliteit van systemen vast te stellen is die van Bedell waarbij systemen worden beoordeeld worden naar kwaliteit (gebruik, beheer)  en belang (operationeel, strategisch).

Tekst groter
Ad 3.

Er kunnen verschillende foto’s gemaakt worden van de referentiearchitectuur in de tijd. Zo kunnen jaarplannen geprojecteerd worden: welke systemen gaan we wanneer vervangen en wat moeten we hiervoor doen. 

verschillendeFotos.jpg

Ad 4.

Op de referentiearchitectuur kunnen de systemen van beide partijen geplot worden. Er is dan snel te zien waar overlap in de gebruikte systemen zit. Afhankelijk van de strategische keuzes (best of breed, absorption, separate systems) kan dan al of niet een ingreep gedaan worden in de portfolio.

Tekst groter

Build 2 Last & Designed 2 change

In “The new normal: Esxplore the limits of the digital world” van Hinssen (2010) wordt gesuggereerd dat we nu op een breekpunt naar een nieuw tijdperk zijn aangeland. Digitaal is niets nieuws meer is de norm.

Dit heeft vele consequenties. Eén ding is zeker relevant in het kader van de architectuur: het is niet langer de ICT-afdeling die domineert als het gaat om nieuwe technologie. Hinssen stelt het zo: “ICTdepartments have turned from being ‘dispensers of cool stuff’ into the ‘dispensers of really old boring stuff’ in just a couple of years, When we used to hand out a computer and cell phone to a new employee on the first day of work, the employee would say ‘thank you’. Now when we hand out their laptop and phone, they look at us incredulously and think: ”You don’t think I’m going to be seen on the street carrying that around, do you?”

Dit gaat niet alleen over mobiele telefoons en laptops. Het gaat ook over  het even in elkaar zetten van een website door een amateur versus een ingewikkeld contentmanagement-systeem, een applicatie van Google apps gebruiken versus na een grootse en meeslepende pakketselectie een implementatietraject uitvoeren of het online boeken van een vliegticket versus het omslachtig inboeken van een order in een ERP-systeem.

Hinssen pleit er dan ook voor om de architectuur vanuit een ander perspectief te vullen. Wij zijn gewend om te werken aan een perfecte, duurzame langetermijnoplossing. Hij stelt dat dit met de snelle technologische ontwikkelingen niet meer te handhaven is. Er moet ruimte gemaakt worden om snel nieuwe ICT-oplossingen in te passen die ‘goed genoeg‘ zijn. In de architectuur maakt hij een splitsing in componenten die een langetermijnfundament moeten hebben (‘built 2 last’) en componenten met een wat vluchtiger karakter (‘designed 2 change’). In figuur 70 is te zien dat deze twee ’werelden‘ verbonden worden via middleware. Bijzonder in deze middleware is dat Hinssen hier CRM in plaatst. Zijn stelling is dat je altijd overal de laatst actuele klantinformatie nodig hebt welk medium of applicatie je ook gebruikt. CRM legt de verbinding tussen de nieuwe media en de duurzame backoffice-systemen.

Tekst groter

Management game: Decide-IT

Rondom samenwerking en teamvorming. De meeste beslissingen worden genomen in een team en elk team heeft haar eigen dynamiek. In een team spelen belangen en persoonlijkheden een rol en de vraag is hoe daarmee om te gaan.

decide.jpg

Als adviseurs van Twynstra Gudde komen we de worsteling rondom IT en besluitvorming regelmatig tegen. In samenwerking met TU-Delft hebben we een uniek bordspel ontwikkeld om IT-professionals, managers en bestuurders in teams te laten oefenen met het maken van keuzes over IT.

Het spel

De deelnemers aan het spel vormen samen een directieteam van een fabriek dat golfclubs produceert. Het directieteam kent vijf rollen, namelijk de baas (CEO), de boekhouder (CFO), de productiechef (COO), de verkoper (CMO) en de informatiemanager (CIO). Het directieteam is verantwoordelijk om het bedrijf te laten groeien tot nummer 1 in Europa. Belangrijk onderdeel bij het realiseren van deze ambitie is het inrichten van het IT-landschap, want zonder IT dreigt de fabriek ten onder te gaan aan de groeiende concurrentie. In verschillende rondes moeten de deelnemers als een team beslissingen nemen die leiden tot een grotere winstgevendheid en een groter marktaandeel.

Het spreekt voor zich dat alle leden van het directieteam een eigen belang hebben vanuit hun achtergrond. Zo wil de verkoper natuurlijk zo snel mogelijk IT-systemen aanschaffen voor het werven en behouden van klanten, de productiechef een systeem voor productiebesturing, de boekhouder systemen voor financiën, de baas stuurinformatie en de informatiemanager een gedegen IT-infrastructuur. Daarnaast kan het directieteam collectief besluiten om de productielijn uit te breiden, consultants in te huren en marketing campagnes te starten. Gezien het krappe budget zullen in het team prioriteiten gesteld moeten worden. Een extra complicerende factor in het spel is dat de aangeschafte IT-systemen geïntegreerd moeten worden.

Doel van het spel

Het unieke van Decide-IT is dat het zowel een inhoudelijke als een procesmatige component heeft. Inhoudelijk geeft het spel deelnemers inzicht in IT-architectuur, de wijze waarop IT-systemen gekoppeld kunnen worden en de gevolgen die beslissingen op het gebied van IT kunnen hebben op toekomstige beslissingen. Procesmatig biedt het spel inzicht in het functioneren van teams en biedt het een unieke mogelijkheid om te oefenen met besluitvormingsprocessen waarbij belangen en inhoud een rol spelen.

Voor wie is Decide-IT bedoeld?

De wijze waarop het spel wordt ingezet, is mede afhankelijk van het leerdoel dat de deelnemers hebben. Dat maakt het spel voor een grote doelgroep interessant. Het spel is relevanti voor:

Besluitvormers die weinig kennis en ervaring hebben met IT. Voor hen biedt het spel inzicht in IT-architectuur en de belangrijkste manieren waarop systemen gekoppeld kunnen worden. Professionals en managers binnen de IT-discipline. Voor hen biedt het spel inzicht en begrip ten aanzien van de complexiteit waarmee bestuurders te maken hebben. Verschillende managementteams. Voor hen biedt het spel de mogelijkheid te oefenen met de wijze waarop zij in een groep tot een besluit komen en inzicht te krijgen in de wijze waarop leamleden met elkaar omgaan.

Decide-IT is een bordspel. In het spel worden vijf rollen onderkend.. Er kunnen meerdere bordspellen parallel gespeeld worden

Uitvoering en voorbereiding

Om optimaal resultaat te boeken met het spel is voorbereiding essentieel. Spelen van het spel bestaat daarom uit vier contactmomenten:

Een intakegesprek van een uur met één van de spelers om gezamenlijk het doel van het spel te bepalen en inzicht te krijgen in de huidige problemen en/of uitdagingen.

Een gesprek van een uur met alle deelnemers van het spel. Dit moment ligt kort voordat het spel daadwerkelijk wordt gespeeld. Tijdens dit contactmoment wordt een korte toelichting gegeven op het spel en worden de deelnemers gecontracteerd. Het spel wordt gespeeld in een dagdeel. In dat dagdeel vindt ook een beknopte evaluatie plaats.

Een evaluatiemoment. Ongeveer een week nadat het spel is gespeeld, vindt een tweede en uitgebreidere evaluatie plaats. Dit moment kan met één van de spelers zijn, maar we kunnen ons ook voorstellen dat de evaluatie plaatsvindt met alle spelers. De evaluatie duurt maximaal 2 uur.