Investeren in infrastructuur

De strijd voor en tegen het investeren in software om een bedrijfsbrede infrastructuur te ondersteunen woedt nu al jaren. Tegenstanders voeren aan dat het installeren en onderhouden van metadatabases veel te veel tijd en geld kost. Voorstanders menen dat bedrijfsbrede applicaties zo complex zijn, dat een gebrek aan ondersteuning alleen maar tot fouten kan leiden. De kosten zijn natuurlijk een sleutelfactor. Elk infra-product kost geld en tijd. De kosten zijn pijnlijk tastbaar, de opbrengsten kunnen moeilijk aantoonbaar worden gemaakt.

Ik ben van de oude stempel. Ik geloof dat investeren in tools voor beheersing, ontwerp en ontwikkeling een goede zaak is; ik geloof ook dat investeringen tot nu toe onder de maat zijn. De huidige IT-omgevingen zijn echter complexer dan ooit, en de noodzaak om snel op veranderingen in de markt te kunnen inspringen is van kritisch belang. Als gevolg hiervan is het investeren in tools voor de ondersteuning van de infrastructuur absoluut essentieel geworden. Bedrijven die hier niet aan meedoen, lopen het risico uit elkaar te vallen. In veel bedrijfstakken hangt de overlevingskans af van de mate waarin IT-systemen worden verbeterd, zodat sneller op de veranderende klantvraag kan worden ingespeeld.
De kwaliteit van de tools verschilt per applicatie en computersysteem. Mainframes kennen een breed scala aan operationele tools; hetzelfde geldt voor databases en communicatienetwerken. Tools voor het beheren van Unix-systemen (zoals 'batch schedulers') zijn minder ontwikkeld, en voor NT zelfs nog minder. Dit is een kwestie van vraag en aanbod; de 'third-party' producten voor mainframes hebben geleid tot een aantal grote specialistische softwarehuizen. Iedereen realiseert zich dat moderne bedrijven tegenwoordig beschikken over een breed scala aan systemen, waardoor ze hun producten zo aanpassen dat die de meest voorkomende platforms aankunnen. Archivering is bijvoorbeeld van belang voor elke database, en de bestaande ervaring met het beheren van mainframes moet ook op het gebied van Unix, NT en dergelijke, worden verzilverd.
Applicatieontwikkeling staat er veel slechter voor dan operationeel beheer. Er zijn wel ontwikkeltools op hoog niveau, maar die waren kort geleden nog dun gezaaid; veel applicaties zijn zonder duidelijk ontwerp in elkaar gecodeerd. Testen heeft te weinig aandacht gekregen, vooral bij gui-applicaties. Omdat er weinig ontwerptools zijn waarmee applicaties gepartitioneerd kunnen worden, zitten we nu met 'quick-and-dirty' rad-tools en dikke clients. Onderhoud is sinds jaar en dag een veel groter probleem dan software-ontwikkeling, en rad-tools hebben het er niet beter op gemaakt!
De meeste bedrijven hebben een mix van applicaties in Cobol, 4GL, C++, Visualbasic en nu ook Java. Elke programmeertaal heeft zijn kampioenen die niet met anderen willen samenwerken; het is moeilijk om een Visualbasic-fanaat te overtuigen van het feit dat hij een enorm onderhoudsprobleem creëert of dat C++ klassebibliotheken leiden tot rampzalige problemen op het gebied van versiebeheer tijdens 'runtime'.
De grote hoeveelheid incompatibele ontwikkelsystemen is waarschijnlijk het grootste struikelblok bij het opleveren van flexibele, aanpasbare systemen. Het antwoord ligt voor de hand: dunne client-applicaties met modulaire, herbruikbare componenten - gui-componenten, maar ook duurzame, kritische zakelijke servercomponenten. Het zal niet makkelijk zijn om zover te komen, gegeven de huidige massa aan producten en applicaties.
Het gebruik is veel te duur, omdat code wordt verspreid over desktop-PC's. Het beheer van desktops is een van de grootste problemen die bedrijven nu moeten oplossen. Het wordt snel ernstiger omdat Internet nieuwe applicaties stimuleert, die vanaf elke locatie gebruikt kunnen worden. Gelukkig kan de dynamische distributie die inherent is aan Java, dit probleem helpen beheersen, maar verdwijnen zal het nooit.
Bij het groeperen van infrastructuur-componenten zijn op operationeel vlak redelijk wat successen geboekt (tegen een zekere prijs). Producten als Tivoli, Unicenter en dergelijke, bloeien volop. Deze werken volgens het principe 'beheer van beheer': een centraal punt waaronder alle afzonderlijke netwerken, besturingssystemen, databases en dergelijke vallen.
'Computer aided software engineering' had hetzelfde voor software-ontwikkeling moeten betekenen: een integratie van verschillende producten voor ontwerp, generatie, testen en dergelijke. De mislukking van AD/Cycle en het ontbreken van algemene standaarden hebben geleid tot een wildgroei aan incompatibele producten. De nieuwe generatie ontwerptools is gebaseerd op de Universal Modelling Language (UML) en kan dus zo worden aangepast dat alle component-ontwikkeltools erbij passen - op den duur. De opkomst van gegevenspakhuizen heeft het gebrek aan tools des te schrijnender gemaakt. De applicatie gebruikt een of meer ontwerptools, het gegevenspakhuis weer andere tools en de analytische front-end (Olap) weer andere tools. Om deze tools gesychroniseerd te houden, zijn metagegevens nodig.
Voor mij is de conclusie duidelijk. Ondanks mislukkingen in het verleden moeten we bedrijfsbrede repositories hebben. Alleen met een centraal punt voor beheersing, definitie en eigendom kunnen tools voor ontwerp, gebruik en beheer samenkomen tot een beheerbaar, responsief systeem. Er is een standaard voor repositories nodig. Let daarom goed op het Platinum/Microsoft-product, IBM's aanbod (ondanks AD/Cycle) en de goede uitbreiding die is gebaseerd op XML. Een standaard-repository biedt voordelen voor de leveranciers én de gebruikers van tools!