Verwarring heerst in de IT-discipline, waar juist duidelijkheid vereist is. De grenzen van het oude paradigma zijn bereikt, zo betoogt P. Laagland. Sleutelbegrippen voor een nieuw, werkzaam paradigma zijn ontkoppelpunten, werken met ‘zwarte dozen’ in het ontwerpproces, verschillende ontwerpdisciplines en meerdere kleine ontwerpteams. De IT-organisatie moet daarnaast een aantal van haar traditionele taken onderbrengen in gespecialiseerde ‘softwarefabrieken’ en zich transformeren tot een ‘architectenbureau’.
Voor de uitdagingen van deze tijd blijkt het paradigma dat vijfentwintig jaar lang de basis vormde voor het inrichten van automatiseringsprojecten niet meer te werken. Dit paradigma is in Nederland verankerd in Ardi en SDM. Het gaat ervan uit dat ieder informatiesysteem uniek is en dat alle software ervan projectmatig geconstrueerd moet worden. Bovendien is er een impliciete veronderstelling dat deze software wordt uitgevoerd op een mainframe of eventueel een krachtige minicomputer.
Er is momenteel sprake van een voortdurend toenemende complexiteit van de IT-dienstverlening, zowel aan de vraag- als aan de aanbodzijde. Aan de vraagzijde neemt IT een steeds grotere plaats in in het produktieproces. Dit geldt niet alleen voor de aantallen transacties, maar ook voor het soort diensten dat met behulp van IT wordt geleverd. De time-to-market van nieuwe diensten wordt steeds korter. De IT-organisatie moet daarom sneller de benodigde produktiemiddelen kunnen opleveren. Aan de aanbodzijde is sprake van een steeds breder spectrum van technologische mogelijkheden, waarvan velen de overtuiging hebben dat deze in de behoeften kunnen voorzien.
Veel grote IT-organisaties volgen die ontwikkelingen op de voet en hebben relevante kennis en vaardigheden opgebouwd, maar zijn desondanks niet in staat om de technologie op een effectieve manier te gebruiken in informatiesystemen. Een paradigma-verschuiving is noodzakelijk. De te hanteren concepten en werkwijzen en de visie op de discipline van de IT-professional moeten wezenlijk veranderen. Deze wijziging gaat plaatsvinden in de gehele IT-industrie. Voorbeelden van grotere IT-organisaties die deze verandering al hebben doorgemaakt zijn er nog niet.
Sleutelbegrippen van het nieuwe paradigma zijn: ontkoppelpunten creëren; werken met ‘zwarte dozen’ in het ontwerpproces; verschillende ontwerpdisciplines identificeren, en werken in kleine ontwerpteams. Bovendien moet de IT-organisatie een aantal taken die ze traditioneel uitvoert onderbrengen in gespecialiseerde ondernemingen (softwarefabrieken) en zal ze zich moeten transformeren tot een architectenbureau.
Magische grens
Het huidige paradigma voor systeemontwikkeling gaat uit van een splitsing tussen functioneel en technisch ontwerp. Zolang het informatiesysteem wordt gerealiseerd met een homogene technologie, bijvoorbeeld met Cobol en IMS op een IBM-mainframe, is dit een werkzaam uitgangspunt. Deze veronderstelling geldt echter niet meer. Net als in iedere andere engineering-discipline heeft ontwerpen te maken met het overbruggen van het spanningsveld tussen de mogelijkheden van de beschikbare technologie en de wensen en eisen (de functionaliteit van het systeem). De technologie moet daarbij niet worden gezien als een beperking: de ontwerper heeft de taak te weten wat beschikbaar is, om dat ten dienste te stellen van het ontwerp.
Er is een grens aan de omvang van een informatiesysteem. Aanvankelijk werden systemen ontwikkeld met een beperkte reikwijdte. Het ontwerp was met een klein aantal mensen te overzien. Naarmate de IT-organisatie meer ervaring kreeg met het ontwikkelen van systemen en de vraag om geïntegreerde functionaliteit van de gebruiker toenam, groeide de omvang van de te realiseren systemen. Daarbij is echter een magische grens gepasseerd, waarachter onverwachte en onbeheersbare verschijnselen optreden. Waar deze magische grens precies ligt, is niet duidelijk, maar het heeft te maken met de menselijke maat: mensen moeten het ontwerp kunnen bevatten. Professionals kunnen wel meer complexiteit overzien dan leken, maar die magische grens zal er altijd zijn.
De oplossing voor dit probleem is bij veel andere engineering-disciplines bekend: het principe van de zwarte doos. In het ontwerp zitten bouwstenen, componenten, waarvan de functionaliteit goed bekend is, maar waarvan de interne structuur en werking niet wordt overzien. Als zodanig is het ontwerp sluitend en in alle details uitgewerkt. Het projectteam voert het ontwerp en de bouw van die componenten echter niet uit. De componenten worden ingekocht bij een externe leverancier of door een ander projectteam gerealiseerd.
Een moderne aanpak
De klassieke aanpak bij het ontwikkelen van informatiesystemen onderscheidt een groot aantal activiteiten. Projectmedewerkers worden belast met het uitvoeren daarvan. De projectleider moet ervoor zorgen dat die activiteiten in de juiste volgorde worden uitgevoerd en dat – waar nodig – afstemming plaatsvindt.
Bij niet al te grote projecten valt de coördinatie-inspanning die hieruit voortvloeit te overzien. Die inspanning neemt echter exponentieel toe naarmate het project groter wordt. Een opsplitsing in deelprojecten, één voor ieder deelsysteem, is niet echt een oplossing. De deelsystemen voldoen zelden aan het criterium dat ze zich gedragen als zwarte dozen. De onderlinge afhankelijkheid van activiteiten tussen de deelprojecten blijft dus bestaan en komt vaak pas (te) laat boven water.
Een moderne aanpak gaat uit van ontwerpteams die integraal verantwoordelijk zijn voor het ontwerp van een informatiesysteem. Dit team wordt pas ontbonden als het systeem is opgeleverd. Naast de systeemontwerper is in dit team een materiedeskundige opgenomen. Deze is bevoegd aan te geven aan welke eisen het systeem moet voldoen. Hij heeft in het team de rol van ‘probleemhebber’. Verder maken aspectspecialisten deel uit van het team: één voor ieder type technologie dat bij het ontwerp wordt ingezet. Ten slotte zit in het team een projectleider. Hij heeft tot taak ervoor te zorgen dat het ontwerpproces op een goede manier verloopt.
Aspectspecialisten
De eisen die de materiedeskundige inbrengt in het systeemontwerpteam vloeien voort uit een ander probleem: het (her)ontwerp van de bedrijfsprocessen. Ook hier is een ontwerpteam actief. De materiedeskundige vervult daarin de rol van ontwerper (de bedrijfsontwerper). Zijn probleemhebber is de lijnmanager van een bedrijfsonderdeel die meent dat de inrichting van zijn bedrijfsprocessen (organisatiestructuur, produktiefaciliteiten, informatiesystemen) beter kan en daarvoor oplossingen zoekt.
De bedrijfsontwerper brengt de bedrijfsprocessen in kaart en herontwerpt deze waar nodig. Verder kijkt hij naar de vormgeving van die processen. Specialisten op het gebied van organisatiestructurering, produktietechnologie, informatiesystemen etcetera adviseren hem daarbij. De aspectspecialist informatiesystemen vervult in het systeemontwerpteam de rol van systeemontwerper.
Op dezelfde wijze kan iedere aspectspecialist in het systeemontwerpteam de rol van ontwerper vervullen in een ander team. De netwerkspecialist bijvoorbeeld zal bij het systeemontwerp adviseren over de haalbaarheid van de inzet van bepaalde technologie. Als deze inderdaad wordt toegepast, moet hij het netwerk ontwerpen. De systeemontwerper krijgt in dit netwerkontwerpteam de rol van probleemhebber. Daarnaast worden aspectspecialisten ingezet, bijvoorbeeld op het gebied van publieke communicatiefaciliteiten en om specifieke produktkennis in te brengen.
Onder controle
De beschreven aanpak reikt twee principes aan waarmee een project dat onbeheersbaar is gezien de omvang van het te realiseren informatiesysteem, onder controle te brengen valt.
Ten eerste worden de verschillende ontwerpproblemen onderscheiden en ondergebracht in ontwerpteams, ieder met een eigen verantwoordelijkheid. Daarbij valt te denken aan het ontwerp van: het bedrijf(sproces); het systeem; het netwerk; de database; de computerconfiguratie en softwarecomponenten.
Ten tweede moet ieder ontwerpteam bepalen hoe gedetailleerd het zijn ontwerp uitwerkt. Door het bewust toepassen van zwarte dozen blijft de ontwerptaak te overzien. De verantwoordelijkheid voor de specificatie van een zwarte doos, de uitbesteding aan een andere ontwerpgroep en vervolgens de acceptatie blijft berusten bij het ontwerpteam. Het werk van het team is pas klaar als alle in het ontwerp opgenomen zwarte dozen zijn opgeleverd.
Extern inkopen
De bedrijfsonderdelen zijn verantwoordelijk voor het bedrijfs(proces)ontwerp. De IT-organisatie zal systeemontwerpers inzetten voor het aspect informatiesystemen. Systeemontwerp is een kernactiviteit van de nieuwe IT-organisatie. De materiedeskundige werkt in het bedrijfsonderdeel en participeert in het systeemontwerpteam. De projectleider en de aspectspecialisten zullen werkzaam zijn in de IT-organisatie. Het systeemontwerpteam voert geen bouwactiviteiten meer uit; het fungeert als architectenbureau.
Een aantal andere ontwerpactiviteiten zal eveneens onder de verantwoordelijkheid van het architectenbureau worden uitgevoerd. Wel zal het in sommige gevallen externe aspectspecialisten inschakelen. Het netwerkontwerp bijvoorbeeld is een kerntaak van de nieuwe IT-organisatie, maar specifieke deskundigheid van het publieke netwerk wordt mogelijk extern ingehuurd.
Software-ontwerp, inclusief de bouw van programmatuur, vormt steeds minder een kerntaak van de IT-organisatie. Net als hardwarecomponenten zijn meer en meer softwarecomponenten, bestemd voor systeemontwerp, in te kopen bij gespecialiseerde IT-leveranciers. Bij de maatwerkcomponenten is in toenemende mate sprake van een grote diversiteit aan in te zetten constructietechnologieën. Een groeiend aantal aanbieders specialiseert zich in één constructietechnologie. Daardoor kunnen ze zeer efficiënt en met korte doorlooptijden produceren. Waar mogelijk moet de nieuwe IT-organisatie voor het realiseren van softwarecomponenten gebruik maken van dergelijke externe partners. Als dat niet kan, bijvoorbeeld omdat de te gebruiken technologie te specifiek is of omdat de organisatie uit concurrentie-overwegingen iets niet extern wil laten uitvoeren, moet die activiteit in een aparte eenheid binnen de IT-organisatie worden ondergebracht.
Een nieuw paradigma
Een paradigma is een stelsel van begrippen, beelden en uitgangspunten dat binnen een (wetenschappelijke) discipline als norm wordt geaccepteerd. Wetenschappers gebruiken hun paradigma om verschijnselen die ze onderzoeken te verklaren en om theorieën verder uit te diepen. In die zin kan een paradigma zeer produktief zijn voor een wetenschap.
Op een bepaald moment worden echter de grenzen van een paradigma bereikt en zijn bevindingen van wetenschappers daarbinnen niet meer goed te duiden. Op dat moment is de wetenschappelijke discipline in verwarring en vindt een ‘scholenstrijd’ plaats. Na verloop van tijd ontwikkelt zich een nieuw paradigma dat produktiever blijkt en dat veel onderzoekers accepteren als uitgangspunt voor verder onderzoek.
De IT-discipline van vandaag is in verwarring. De grenzen van het oude paradigma zijn bereikt; een nieuw paradigma is nodig. Dat komt tot stand door theorievorming en, vooral, door toetsing van nieuwe ideeën in de praktijk door een groot aantal IT-professionals. Experimenten zijn daarbij onvermijdelijk. De vraag is niet zozeer of de concepten uit dit artikel beter werken dan de oude werkwijze; de vraag luidt eerder ‘hoe de ontwikkeling van een nieuwe werkwijze en nieuwe organisatievormen aan te pakken’.
P. Laagland, directeur Ises International