Vision

De komst van client/server-architecturen en de verdere groei naar netwerken van toepassingen hebben ook grote gevolgen voor het ontwikkelen en beheren van de zakelijke toepassingen. De werkwijze moet aan andere en hogere eisen voldoen dan bij centrale systemen op mainframe.

4.8.1 Het ontwikkelen

Hieronder staan de belangrijkste eisen vermeld waaraan het ontwikkelen van toepassingen moet voldoen:

Sneller ontwikkelen
Het ontwikkelen van software kost nog steeds te veel tijd. Dit geldt niet alleen voor maatwerksoftware van zakelijke toepassingen. Ook softwareleveranciers hebben grote moeite hun produkten op het vooraf aangekondigde tijdstip te leveren. In vergelijking met conventionele toepassingen op een mainframe hebben client/server-toepassingen veel meer software nodig. Dit komt door de middleware die nodig is en door de toegenomen functionaliteit van het maatwerkgedeelte van de toepassingen.

Ontwikkelen in etappes
De huidige ontwikkelmethoden werken volgens het zogenaamde 'waterval'-principe. Hierbij komen alle toepassingen in de stappen voorstudie, analyse, ontwerp en realisatie als één geheel tot stand. Deze verzameling toepassingen is wat we op dit moment verstaan onder een informatiesysteem. Toekomstige toepassingssystemen zijn netwerken van toepassingen met een grotere functionaliteit, die veel meer bedrijfsprocessen ondersteunen. Deze toepassingssystemen worden zo omvangrijk, dat we ze niet meer in één keer kunnen bouwen. Nieuwe vormen van ontwikkeling zijn nodig waarbij we het toepassingssysteem in etappes kunnen bouwen en ook tegelijkertijd in staat zijn de bedrijfsvoering en de menselijke organisatie in etappes te wijzigen.

Eenvoudiger onderhoud
De huidige monolitische informatiesystemen zijn moeilijk te onderhouden. Wijzigingen in de bedrijfsvoering betekenen doorgaans dat op allerlei plaatsen wijzigingen moeten plaatsvinden. Vaak is moeilijk te vinden waar de wijzigingen moeten plaatsvinden en vast te stellen wat de gevolgen van de wijziging zijn voor de rest van het systeem. Het gevolg is dat het onderhoud van de toepassingen te veel tijd vergt en ten koste gaat van nieuwe te ontwikkelen toepassingen. Het onderhoud kan sterk vereenvoudigen wanneer we onderdelen van de toepassingen één op één kunnen relateren aan bepaalde onderdelen van de bedrijfsvoering, zoals bedrijfsprocessen en bedrijfsobjecten.

Samengevat betekent dit dat er sprake moet zijn van evolutionair ontwikkelen van zowel het bedrijf als zijn IT-toepassingen. De toepassingen moeten kunnen mee-evolueren met veranderingen in het bedrijf. Omgekeerd moet het bedrijf kunnen evolueren door nieuwe of betere toepassingen.

De volgende ontwikkelingen dragen bij tot het oplossen van de problemen met het ontwikkelen van toepassingen:

Gebruik van ontwikkeltools
Het ontwikkelproces kan aanzienlijk versneld worden door het gebruik van geautomatiseerde ontwikkeltools.

Client/server-architectuur
Een client/server architectuur en vooral de Collaborative Object Architecture vereenvoudigen het in etappes bouwen van toepassingen. Men kan bovendien de toepassingen en de componenten ervan relatief onafhankelijk van elkaar wijzigen bij onderhoud.

Objectparadigma
Realisatie van toepassingen volgens het objectparadigma maakt het eenvoudig veranderingen in de bedrijfsvoering te vertalen naar veranderingen in de toepassingen.

'Fabriek' voor softwarecomponenten
Objectoriëntatie legt ook de basis voor het fabrieksmatig produceren en leveren van softwarecomponenten, waaruit gebruikers hun toepassingen zelf kunnen samenstellen.

Deze wijze van werken is de beste methode om maatwerkoplossingen te bouwen voor zakelijke toepassingen die gebruik maken van multimediadocumenten en een grafische of multimedia-gebruikersinterface. Ontwikkelaars kunnen deze complexe toepassingen niet meer volledig gaan programmeren. Zij moeten de beschikking hebben over generieke software voor de standaardfuncties van de interface en de multimediadocumenten, zodat ze alleen die functies die echt bedrijfsspecifiek zijn nog moeten toevoegen.

Visuele tools
Met de opkomst van de GUI komen er ook steeds meer ontwikkeltools op de markt die het ontwerpen en programmeren visueel ondersteunen. De visuele werkwijze is aanzienlijk sneller dan het in instructies programmeren van de toepassing. Wanneer we overschakelen op het componeren van toepassingen uit softwarecomponenten dan helpen dit soort visuele tools de ontwikkelaar te zien uit welke objecten hij zijn toepassing samenstelt en om de werking van de toepassing te testen.

Iteratieve ontwikkelmethoden
Ook de ontwikkelmethoden moeten zich meer richten op gedistribueerde toepassingen, die in de loop van de tijd groeien en meer functionaliteit krijgen.

Op dit moment zijn methoden in ontwikkeling voor Iterative Application Development (IAD) die zich richten op het ontwerp van gedistribueerde systemen volgens client/server architecturen inclusief het gebruik van objectoriëntatie om te komen tot herbruikbare softwarecomponenten. Deze methoden gaan uit van een bestemmingsplan voor de realisatie van toepassingen op langere termijn en een stappenplan voor de realisatie van de toepassingen in kleine projecten. Zie het boek IAD: het evolutionair ontwikkelen van informatiesystemen.

4.8.2 Het beheren

De gedistribueerde architectuur van netwerksystemen stelt hoge eisen aan het beheer van zowel de hardware als de toepassingen. De eerste ervaringen met client/server-architecturen laten zien dat met name het gedistribueerde beheer en de beveiliging van zowel de software als de gegevens op dit moment de grootste bottle-neck vormen voor de verdere groei van netwerksystemen. Voor het gedistribueerde beheer van hardware en vooral van netwerken zijn op dit moment tools beschikbaar. Maar tools voor het gedistribueerde beheer van toepassingen en databases zijn nog in ontwikkeling. Het kan nog wel een aantal jaren duren voordat deze tools hetzelfde niveau van beheer en beveiliging bereiken als nu bijvoorbeeld geboden wordt door DBMS'en op centrale systemen.

Het beheer van gedistribueerde computersystemen heeft te maken met een aantal specifieke probleemgebieden waarvoor de beheertools oplossingen moeten bieden. Ook de overstap van alfanumerieke velden naar documenten brengt een aantal specifieke problemen met zich mee. Hieronder volgt een overzicht van de belangrijkste probleemgebieden.

Configuratiebeheer en versiebeheer
Het configuratiebeheer houdt zich bezig met het installeren, beheren en administreren van de configuraties van de volgende componenten:

• hardware, zoals computers en netwerken;
• middleware als brug tussen besturingssysteem en toepassingen;
• de databases met de definities van de gegevens die kunnen worden opgeslagen;
• de toepassingssoftware (zowel pakketten als maatwerk);
• bij het gebruik van objecten vervallen de twee vorige punten en beheren we de configuratie van typen objecten (classes) die de toepassingen in gebruik hebben.

Van al deze componenten moet worden bijgehouden waar, in welke combinaties en vooral in welke versies zij geïnstalleerd zijn. Het zal duidelijk zijn dat dit een zeer complexe zaak wordt, omdat we door de groei van de netwerken steeds grootschaliger configuraties krijgen, die uit steeds meer verschillende componenten zijn opgebouwd. Het beheer moet dan ook zo georganiseerd zijn dat de beheerders diverse aandachtsgebieden krijgen, waarbij we de totale configuratie in deelgebieden opsplitsen die zich redelijk onafhankelijk van elkaar laten beheren. Ondersteuning met geautomatiseerde beheertools is een noodzaak. Deze tools moeten in ieder geval ondersteuning geven aan de registratie van de configuraties en het licentiebeheer van pakketsoftware en aan het op afstand installeren van software en databases.

Configuraties en versies van documenten
Toepassingen gaan steeds meer gebruik maken van documenten die zijn samengesteld uit objecten zoals teksten, tekeningen, spreadsheets, video en geluid. Het probleem is het beheer van de configuraties van objecten in diverse documenten, waarbij bijvoorbeeld dezelfde tekening kan voorkomen in verschillende documenten. Hierbij kan er één originele versie van de tekening zijn, waarnaar door alle documenten wordt verwezen. Het is ook mogelijk tekeningen vast in documenten op te nemen. Dit levert een noodzaak op voor versiebeheer van zowel de objecten als de documenten, waarbij we bijhouden welke versie van een bepaald object in welke versie van bepaalde documenten in gebruik is via verwijzing en welke versies van objecten vast opgenomen zijn in documenten. Er zijn softwarepakketten die dit ondersteunen voor omgevingen waar diverse personen werken aan de samenstelling van publikaties die voortdurend wijzigen, zoals bijvoorbeeld vliegtuighandboeken, die voortdurend updates nodig hebben.

Wanneer we toepassingen gaan bouwen waarin we in plaats van de huidige alfanumerieke velden gebruik maken van documenten die zijn samengesteld uit objecten, dan zal configuratiebeheer en versiebeheer van de inhoud van deze documenten en objecten nodig zijn. Een voorbeeld hiervan is een langlopend verzekeringscontract met een klant, dat bestaat uit diverse subcontracten en clausules. Gedurende de looptijd ontstaan door wijzigingen opvolgende versies van het contract. Iedere versie heeft zijn een eigen configuratie die weer bestaat uit bepaalde versies van subcontracten en clausules.

Autorisatie en eigenaarschap
Een groot probleem in een gedistribueerde omgeving is het beheer van eigenaarschap en van de autorisaties. Dit geldt zowel voor het gebruik van objecten als voor het gebruik van functies van deze objecten. Nu zijn dit soort zaken nog voor programma's en gegevens afzonderlijk geregeld. Een gebruiker mag een bepaalde toepassing (dus programma) starten en krijgt toegang tot bepaalde gegevens. Het hangt vervolgens van het DBMS af welke bewerkingen hij op deze gegevens mag uitvoeren. Aangezien de meeste documenten niet in databases maar in losse bestanden zijn opgeslagen, is er nu weinig of geen beveiliging tegen het wijzigen of kopiëren van documenten door derden. In de toekomst moet ieder afzonderlijk document of object weten welke gebruiker zijn eigenaar is en welke gebruikers welke functies op hem mogen uitvoeren. Ook moeten de objecten bijhouden of zij het origineel zijn waarbij wijzigen is toegestaan of een kopie van een bepaalde datum die niet mag wijzigen. Licenties voor gebruik zullen in de toekomst geen betrekking meer hebben op complete programma's maar op het gebruik van afzonderlijke functies of gereedschappen voor bepaalde soorten objecten.

Gedistribueerde besturing en bewaking
De distributie van toepassingen over de hardware maakt het nodig dat operators met computerondersteuning de bewaking en de besturing van de processen in het gehele netwerk uitvoeren. Dit betekent dat het procesverloop van de toepassingen moet worden bewaakt en gepresenteerd aan de operators. De besturing betreft het geautomatiseerd bijsturen of handmatig ingrijpen van de operator bij bijvoorbeeld performance-problemen of storingen. Dit ingrijpen kan bestaan uit het tijdelijk laten draaien van toepassingen op een andere computer of het aanbieden van alternatieve routes in het netwerk. Ook kan men via het configuratiebeheer een permanente aanpassing van de distributie van de toepassingen uitvoeren. Bij permanente performance-problemen kan men besluiten om de hardwareconfiguratie uit te breiden.

4.8.3 Naar één platform voor alle toepassingen

De groei van netwerksystemen zowel binnen als tussen bedrijven zal ertoe leiden dat er in toenemende mate één IT-infrastructuur komt die als platform dient voor de toepassingen van alle bedrijven. Door het ontstaan van de elektronische snelweg zal dit platform zich ook uitstrekken tot de thuissystemen en toepassingen van particulieren.

Zo ontstaat eerst per bedrijf, maar in toenemende mate wereldwijd, een gemeenschappelijk toepassingsplatform dat gebruikers, beheerders en ontwikkelaars van toepassingen ondersteunt.

 

Afbeelding 4.10 Het toepassingsplatform.

Het platform bestaat van beneden naar boven uit:

• hardwarecomponenten zoals werkstations, servercomputers en netwerken;
• basissoftware en middleware die nodig zijn om de toepassingen te laten werken;
• een database voor de opslag van gegevens met een repository voor de definities en functies (software), op termijn te vervangen door een OBMS voor de objecten;

Het platform 'draagt' de actieve gebruikerstoepassingen, beheertools en ontwikkeltools waar respectievelijk gebruikers beheerders en ontwikkelaars mee werken. Op termijn zijn de toepassingen samengesteld uit interface-, proces- en domeinobjecten.

Het hier beschreven toepassingsplatform heeft een aantal belangrijke gevolgen voor de eigenschappen van toepassingen.

Naast specifiek veel meer generiek
De toepassingen zullen relatief steeds meer generiek en minder specifiek zijn. Dit komt doordat de middleware veel standaardfuncties uitvoert en door het feit dat men toepassingen steeds meer samenstelt uit standaard generieke objecten.

Flexibiliteit en hergebruik
Het opbouwen van toepassingen uit standaardcomponenten verhoogt de flexibiliteit. Een ontwikkelaar kan formeel voorgeschreven delen van een toepassing snel wijzigen door de samenstelling aan te passen. Veel toepassingen werken met flexibel samengestelde documenten waarbij de gebruiker zelf kan bepalen welke objecten hij in het document opneemt. Dit ondersteunt de informele kant van het werk, zoals het opnemen van commentaar, annotaties en gesprekken. Het samenstellen van toepassingen uit standaardcomponenten bevordert het hergebruik van software.

Verschuiving in de ontwikkelresultaten
Voor een computersysteem gaat gelden dat er meer infrastructuur en minder structuur is. Hardware en generieke software vormen een steeds groter deel van de toepassing. De toepassingen zelf ondersteunen naast het formele gestructureerde gedeelte van de bedrijfsprocessen ook steeds meer het informele en niet-gestructureerde deel.

Standaardisatie door zelforganisatie
De groei van het platform zal ook leiden tot meer standaardisatie van hardware, softwarecomponenten en toepassingen. Dit is nodig, omdat anders samenwerking tussen hardware en software van verschillende leveranciers en toepassingen van verschillende eigenaren niet mogelijk is. In tegenstelling tot min of meer opgelegde standaarden ontstaan deze standaarden door zelforganisatie. Gebruikers en leveranciers zullen zelf zaken gaan standaardiseren om onderling te kunnen samenwerken.

Het toepassingsplatform versterkt nog een trend. Er komt namelijk een duidelijker scheiding tussen organisaties die zich bezighouden met het inrichten en exploiteren van IT-faciliteiten en de gebruikersorganisaties.

De IT-facilitaire organisaties zijn de leveranciers van een IT-platform bestaande uit hardware, middleware en generieke en specifieke componenten voor toepassingen. De gebruikersorganisaties zijn de afnemers van dit IT-platform. De gebruikersorganisaties sluiten met de IT-facilitaire organisaties dienstverleningscontracten af (de zogenaamde service level agreements) waarin afspraken staan over het niveau van dienstverlening dat de IT-facilitaire organisaties in de vorm van produkten en diensten moeten leveren.