‘Multitier’-architectuur biedt flexibiliteit

Het fundament van een goede informatie-architectuur is ontkoppeling. Hierbij wordt de informatievoorziening gerealiseerd met behulp van onafhankelijke softwarecomponenten. De multitier-architectuur onderscheidt ten minste drie typen: presentatie-, proces- en datacomponenten. Zij kent niet de problemen van de client/server-architectuur, aldus consultant P.J. Koning e.a.

Organisaties hebben nog altijd te kampen met hoge ontwikkel- en onderhoudskosten bij het gebruik van informatietechnologie. Het beschikbaar stellen van de juiste gegevens op de juiste tijd en plaats vergt een grote inspanning. De bestaande informatiesystemen belemmeren organisaties om snel nieuwe produkten en diensten in te voeren.
Ter illustratie dient het volgende voorbeeld. Bij een bepaald bedrijf slaagt men er waarschijnlijk niet in om in korte tijd een nieuwe vorm van facturering met allerlei kortingsregelingen door te voeren. Omdat een belangrijke concurrent van het bedrijf deze nieuwe vorm van facturering al aanbiedt, bestaat de kans dat klanten zullen overstappen naar deze concurrent. De twee typen produkten die het levert, worden in twee aparte mainframetoepassingen (leveringen A en B) geadministreerd. Beide systemen leveren periodiek gegevens aan het factureringsysteem dat op zijn beurt weer gegevens levert aan de debiteurenapplicatie. Daarnaast is een aparte applicatie ontwikkeld om de verkoop van produkttype B te vereenvoudigen. Deze applicatie levert periodiek gegevens aan systeem "Leveringen B".
Het aanpassen van het bestaande factureringsysteem brengt een aantal problemen met zich mee. Het grootste probleem betreft de koppelingen. Voor de nieuwe vorm van facturering zijn meer gegevens van de leveringssystemen nodig. Het debiteurensysteem moet echter van dezelfde gegevens voorzien blijven. Een aanzienlijk deel van de inspanning om de nieuwe vorm van facturering in te voeren is nodig om de koppelingen te onderhouden. Daarnaast geldt dat de aan te passen systemen oud zijn. Veel documentatie loopt achter bij het gepleegde onderhoud. Ook heeft slechts een beperkt aantal medewerkers diepgaande kennis over het systeem.
Een tweede voorbeeld betreft een ander bedrijf. Een onderzoek van een extern adviesbureau heeft uitgewezen dat de ondersteuning van klanten te wensen overlaat. Het inrichten van een call center leidde tot serieuze problemen in de informatiehuishouding van het bedrijf .
In het verleden is gekozen voor een client/server-architectuur. Een database-server die de bedrijfsgegevens bevat en de bijbehorende proceslogica voor zijn rekening neemt, staat centraal. Voor de verkoop- en marketingafdeling zijn aparte clients ontwikkeld. Nu voor het call center ook aparte clients zijn gebouwd en uitgerold, loopt men tegen de grenzen van de verwerkingscapaciteit van de database-server aan. De responsietijden zijn te hoog. Klanten hangen op. In winkels raakt men geïrriteerd.
Problemen zoals hierboven zijn gemeengoed. Wijzigingen in systemen vergen grote inspanningen en kosten veel geld. Organisaties worden in hun slagvaardigheid en flexibiliteit bedreigd.

Ontkoppeling

Het fundament van een goede informatie-architectuur is ontkoppeling. Dit houdt in dat de informatievoorziening wordt gerealiseerd met behulp van een stelsel van onafhankelijke softwarecomponenten. Iedere component biedt een aantal diensten aan door middel van een interface. Communicatie tussen componenten verloopt altijd via de interfaces. Wanneer een component gebruik maakt van de diensten van een andere component, wordt er tussen de componenten een contract afgesloten. Dit contract bevat afspraken over de beschikbaarheid van de dienst, de gegarandeerde responsietijd en andere operationele afspraken.
Sofwarecomponenten gaan verder dan de bekende softwaremodules. Bij softwaremodules blijft de ontkoppeling beperkt tot het programma of systeem waartoe de modules behoren. Bij softwarecomponenten gaat het om ontkoppeling op een hoger niveau. Systemen en programma’s bestaan niet meer. Iedere softwarecomponent neemt een specifiek deel van de totale functionaliteit voor zijn rekening. Applicaties ontstaan doordat componenten op een bepaalde manier met elkaar samenwerken.
Een samenstelsel van onafhankelijke componenten is de sleutel tot een flexibele, onderhoudbare informatievoorziening. Een belangrijke vraag is: op grond waarvan moeten componenten onderscheiden worden? Er is een visie nodig om tot een goede architectuur (een opdeling in componenten) te komen.

Client/server-architectuur

Een veel gebruikte visie op ontkoppeling is de client/server-architectuur waar twee soorten componenten worden onderscheiden: clients en servers. Een client vraagt een server om een bepaalde taak uit te voeren en het resultaat hiervan terug te geven.
Grofweg zijn er twee varianten in het client/server-model: de fat client-variant waarbij proceslogica in de clients is ondergebracht en de fat server-variant waarbij de proceslogica op de server draait. Een groot probleem van het ‘fat client’-model vormt de duplicatie van proceslogica bij iedere client en de hiermee gepaard gaande distributie- en consistentieproblemen. Een ander probleem is de belasting van het netwerk door de grote hoeveelheid gegevens die van de server naar de clients getransporteerd moet worden.
Het ‘fat server’-model kent het probleem dat de prestatie van de applicatie negatief wordt beïnvloed bij een toename van het aantal clients. De server krijgt dan zoveel taken uit te voeren dat deze het resultaat van de taak pas na lange tijd aan de client kan teruggeven. Daarnaast geldt dat migratie naar databases van andere leveranciers lastig is, omdat elke leverancier zijn eigen taal heeft waarin de proceslogica aan de server-kant wordt vastgelegd.
Door deze problemen van de client/server-architectuur bestaat er in toenemende mate belangstelling voor multitier-architecturen.

Multitier-architectuur

In een multitier-architectuur worden ten minste drie typen componenten onderkend: presentatie-, proces- en datacomponenten. Deze indeling is gebaseerd op de mate van stabiliteit. In volgorde van toenemende stabiliteit worden de componenten toegelicht.
Presentatiecomponenten ondersteunen gebruikers zodat zij hun taak optimaal kunnen uitvoeren. Presentatiecomponenten bevatten alleen functies die de presentatie en de interactie met de gebruikers omvatten. Voor ieder type gebruiker (bijvoorbeeld verkopers, back office-medewerkers en systeembeheerders) is er een presentatiecomponent. Presentatiecomponenten communiceren met procescomponenten en eventueel ook met datacomponenten.
Procescomponenten implementeren bedrijfsprocessen. Groepen van bij elkaar horende elementaire bedrijfsfuncties zijn opgenomen in een procescomponent. Voorbeelden van diensten van een procescomponent die het bedrijfsproces van leveringen ondersteunt zijn: ‘Toevoegen nieuwe klant’, ‘Opnemen levering’ en ‘Maken afspraak’. Procescomponenten maken gebruik van de diensten van andere procescomponenten en van datacomponenten.
Datacomponenten beheren bedrijfsgegevens. Dit zijn gegevens die door verschillende proces- en presentatiecomponenten gebruikt worden. De diensten van datacomponenten bestaan uit elementaire functies op gegevens en eventueel ook complexe queries. De datacomponent ‘Klant’ biedt bijvoorbeeld de diensten aan voor het creëren van een nieuwe klant, het verwijderen van een klant, het ophalen van de gegevens van een klant, het actualiseren van zijn gegevens, en het ophalen van alle klanten uit een bepaald marktsegment.
Stel dat de informatiebehoefte van het bedrijf uit het eerste voorbeeld volgens een multitier-architectuur gerealiseerd was. Men zou dan kunnen volstaan met het maken van een nieuwe dienst in de factureringscomponent. Er is geen overhead betreffende het onderhouden van koppelingen. De nieuwe vorm van facturering kan sneller en goedkoper worden gerealiseerd.
De ontwikkeling van een aparte presentatiecomponent voor het call center van het bedrijf uit het andere voorbeeld zal geen problemen opleveren wanneer het werk wordt uitgevoerd door een aantal proces- en datacomponenten in plaats van door één ‘fat server’. De componenten dragen bij aan een betere verdeling van de werklast.

Migratie

Een belangrijk vraagstuk betreft de overgang van de bestaande informatie-architectuur naar een multi-tier client/server- oplossing. Het simpelweg in één keer implementeren en in produktie nemen van alle nieuwe componenten brengt grote risico’s met zich mee en kost veel geld. Beter is het om in kleine stapjes naar de gewenste architectuur toe te migreren. Globaal gezien kunnen daarvoor twee strategieën worden gevolgd: database first en database last. Voor beide strategieën is het belangrijk om vooraf de gewenste eindarchitectuur te ontwerpen. Vervolgens wordt gekeken in hoeverre de bestaande systemen in deze blauwdruk passen. Per systeem wordt bepaald of deze de rol van een softwarecomponent gaat vervullen of dat deze wordt afgebouwd.
De ‘database first’-strategie houdt in dat men begint met het realiseren van de ontworpen datacomponenten. Met behulp van reverse gateways worden de bestaande systemen gekoppeld aan de nieuwe datacomponenten. Reverse gateways zijn complex, het aantal tools hiervoor is beperkt. Voor de ‘database last’-aanpak is meer ondersteuning. Bij ‘database last’ wordt begonnen met de bouw van presentatiecomponenten die met behulp van forward gateways aan de bestaande systemen worden gekoppeld. Een voorbeeld van een forward gateway is een screen scraper.
Na de presentatiecomponenten worden de procescomponenten gerealiseerd en ten slotte de databases.
Bestaande systemen die de rol van een softwarecomponent gaan vervullen, worden met behulp van adaptors in de architectuur gehangen. Een adaptor is een stuk software dat het interface van de softwarecomponent implementeert en aanroepen van diensten vertaalt naar aanroepen van routines in het bestaande systeem.

Infrastructuur

Om softwarecomponenten daadwerkelijk met elkaar te laten communiceren is een transportmedium nodig, een infrastructuur. Dit type software wordt ook wel aangeduid met de term middleware. De belangrijkste infrastructuurstandaards zijn Corba van de Object Management Group (OMG), Dcom van Microsoft en DCE van de Open Software Foundation (OSF). Een goede infrastructuur biedt voorzieningen voor onder andere gedistribueerde transacties, synchrone en asynchrone communicatie tussen componenten, unieke naamgeving van componenten binnen een domein en mechanismen voor autorisatie en authenticatie.
Middleware kan op verschillende paradigma’s gebaseerd zijn. De meeste varianten zijn gebaseerd op het aanroepen van functies op servers. Communicatie vindt plaats op het niveau van componenten. Dit betekent dat componenten van elkaar moeten weten dat ze bestaan. Bij geavanceerdere middleware kunnen de diensten van instanties van objecten op servers worden aangeroepen. De communicatie vindt hier op een hoger abstractieniveau plaats, namelijk op het niveau van objecten.
Ter illustratie van het laatste paradigma kijken we kort naar Corba. Die bestaat uit een object request broker (orb), object services, application objects en common facilities. Via de orb kunnen Corba- objecten tijdens de uitvoering vragen welke diensten beschikbaar zijn en daarvan vervolgens gebruikmaken. Een orb beschikt over voorzieningen voor beveiliging van het gebruik van diensten en dataverkeer. De ‘object services’ zijn verzamelingen elementaire diensten voor naamgeving, persistentie, concurrency (gelijktijdigheid) enzovoort. De ‘application objects’ zijn de objecten die de organisatie modelleren en die de gebruikers bij hun werkzaamheden ondersteunen. Deze objecten worden ook wel aangeduid met de term business objects.
Om de ontwikkeling van ‘application objects’ te vereenvoudigen kent Corba ‘common facilities’. Dit zijn voorgedefinieerde raamwerken van samenwerkende objecten die kant-en-klaar ingezet kunnen worden in specifieke situaties. Hierbij is onderscheid te maken in twee categorieën: een horizontale en een verticale. De horizontale biedt algemene, domeinonafhankelijke ondersteuning (gebruikersinterface-objecten, informatiemanagementobjecten en objecten ter ondersteuning van werkstroombesturing, e-mail en dergelijke). De verticale omvat objecten voor de ondersteuning van specifieke bedrijfstakken (banken, telecommunicatie, gezondheidszorg, procesindustrie, etcetera).

Ontwikkeltools

Er is een aantal tools beschikbaar die invulling geven aan zowel de multitier-architectuur als de infrastructuur. Deze tools bieden ondersteuning voor het bouwen van softwarecomponenten en hun deployment (installatie in een run-time omgeving). De belangrijke spelers op de markt zijn: Composer (Texas Instruments), Dynasty (Dynasty), Forté (Forté), Natstar (Natsystems), Prolifics (Prolifics), Sedona (Oracle), Supernova (Four Seasons), Usoft (Usoft), Visualgen (IBM).
De volgende vragen dient men te stellen bij de keuze van een ontwikkeltool:

• Welke visie op ontkoppeling hanteert het tool?
  
• Biedt het tool ondersteuning voor de ontwerpfase?
  
• Hoe wordt de overgang van ontwerp naar implementatie ondersteund?
  
• Hoe wordt het ontwikkelproces ondersteund?
  
• Wordt versiebeheer ondersteund?
  
• In hoeverre wordt het maken van operationele afspraken (contracten) tussen componenten ondersteund?
  
• Is het mogelijk om componenten vanaf één punt te distribueren?
  
• Is het mogelijk om de componenten centraal te beheren?
  
• Welke middleware wordt er door het ontwikkeltool gebruikt om de componenten met elkaar te laten communiceren?
  
• Voorziet het tool in load balancing waarmee componenten afhankelijk van de belasting verdeeld kunnen worden over de beschikbare servers?
  
• Welke mogelijkheden zijn er om bestaande systemen te koppelen?
  
• Welke ondersteuning is er voor de verschillende databasesystemen?
  
• Welke ondersteuning is er voor de verschillende TP monitors?
  
• In hoeverre is het tool platform-onafhankelijk?