Een IT-omgeving ontstaat vaak door gebruik te maken van de beschikbare middelen. Er ligt geen ontwerp aan de IT-omgeving ten grondslag en door de tijd wordt er steeds iets toegevoegd (lapwerk). In het begin werkt zo'n omgeving "prima". Het voorziet immers in een behoefte. Maar op den duur lijkt de omgeving op een lappendeken. Er ontstaan barstjes in (de werking van) de IT-omgeving naarmate de organisatie groeit. De complexiteit neemt toe, de afstemming is niet meer voldoende en de beheersbaarheid neemt af.

Vaak worden de IT-taken naast de bestaande werkzaamheden ingevuld door één van de medewerkers. De benodigde documentatie is nog niet aan het papier toevertrouwd.

Het resultaat is vaak de noodzaak tot een doordacht (her)ontwerp van de IT-omgeving. Daarnaast groeit de noodzaak om IT-taken te verdelen of uit te besteden. Bovendien is er een noodzaak om de omgeving te documenteren.

Herkenbaar? Dit artikel heeft als doel om een kleine organisatie (of eenmanszaak) te helpen met het opzetten van een goede IT-omgeving.

Ontwerp IT-omgeving

Het doel van het ontwerp van een IT-omgeving is om bepaalde bedrijfsdoelen te kunnen vervullen en om de organisatie te ondersteunen door de inzet van IT-oplossingen. Er moet een zekere samenhang zijn tussen hoe de IT-omgeving wordt (of is) opgebouwd en wat de samenhang is tussen de processen en de in te zetten IT-oplossingen. Hierbij moet een duidelijk begrip zijn van de vraag (of de wensen). Het is om die reden van belang dat de IT-medewerker(s) (of IT-afdeling; of IT-architect) zich verdiept in de organisatie. Bij het inzetten van oplossingen moet (tot op zeker hoogte) rekening gehouden worden met de mensen (wensen) binnen de organisatie. Er is een zeker afstemming noodzakelijk; en aan de andere kant is een goede introductie van oplossingen onontbeerlijk.

Vakjargon en gezond verstand

Alhoewel IT doorspekt is met vakjargon, is het proces om tot een goede IT inrichting te komen niet ingewikkeld (maar wel intensief). Het gaat hierbij om het invullen van een aantal basisvragen. Hierbij kunnen de basisvragen uit de journalistiek toegepast worden: wie, wat waar, wanneer, waarom en hoe. Deze basisvragen kunnen gebruikt worden bij het vastleggen van het doel en de middelen om vervolgens te komen tot een concrete invulling.

Een aandachtspunt voor IT-medewerkers is om vakjargon te vermijden (waar mogelijk). De organisatie begrijpt technische taal niet altijd waardoor onbegrip kan ontstaan. Albert Einstein zei het als volgt: "Als je het niet simpel uit kan leggen, begrijp je het zelf niet goed genoeg."

De basisvragen kunnen als volgt gesteld worden.

1. Doel - waarom / waarvoor?
   Wat willen we bereiken (of: welk probleem moet er opgelost worden)?
   U kunt daarnaast ook invullen: "voor wie?"

2. Mogelijkheden en middelen - wat / welke?
   Welke mogelijkheden en middelen zullen worden ingezet?

3. Concrete invulling - hoe?
   Hoe passen we de mogelijkheden en middelen concreet toe?

Bij het invullen van de bovenstaande vragen is het van belang om goed te letten op de samenhang. Door iets te bouwen (wat/welke) zonder samenhang (hoe) en zonder goed op het doel (waarom/waarvoor) te letten en zonder voldoende rekening te houden met de mensen (voor wie), zal betekenen dat de IT-omgeving minder goed zal functioneren. Het kan bijvoorbeeld betekenen dat de oplossing niet goed werkt (niet goed is afgestemd), medewerkers ontevreden zijn of dat de inrichting compleet mislukt.

Invalshoeken en reikwijdte

Het is belangrijk om meerdere invalshoeken te bekijken. Vaak wordt door een IT-dienstverlener vooral de nadruk gelegd op de techniek die ingezet wordt. Dit is het "hoe" waarbij voorbijgegaan wordt aan "waarom/waarvoor" en "waarmee".

1. Bedrijfsarchitectuur (waarom/waarvoor):
   organisatiestructuur en bedrijfsprocessen

2. Informatiesystemenarchitectuur (waarmee):
   informatie- en applicatiesystemen (ter ondersteuning van de bedrijfsprocessen) en data uitwisseling

3. Technologie-architectuur (hoe):
   inzet techniek (ter ondersteuning van de informatie- en applicatiesystemen)

Hierbij kan op verschillende niveaus naar de invalshoeken gekeken worden. Het gaat om de reikwijdte ten opzichte van de gehele organisatie of een specifiek deel van de organisatie. Tot slot kan er gewerkt worden aan de hand van een model, alhoewel dit laatste binnen een kleine organisatie eigenlijk niet van toepassing is. Een model-architectuur komt eigenlijk alleen bij grote organisaties voor; alhoewel een samenwerkingsverband van kleine organisaties wel met een model-architectuur kan werken voor de specifieke beroepsgroep.

Samenhang

Samenhang (en afhankelijkheden) is een belangrijk onderwerp, wat niet altijd de vereiste aandacht krijgt. Kijken naar de samenhang van de de organisatie, de systemen en technologie is niet optioneel maar noodzakelijk (voor de IT-er - lees: essentieel).

1. Bedrijfsarchitectuur (waarom/waarvoor)

Weten wat een organisatie doet (ondernemingsplan, missie, visie) is van vitaal belang. Daarnaast moet duidelijk zijn of er veranderingen in de organisatiestructuur en bedrijfsprocessen op handen zijn; en of er bepaalde problemen of knelpunten zijn. De bedrijfsarchitectuur moet in kaart zijn gebracht voordat er naar de informatiesystemenstructuur gekeken kan worden. Deze informatie biedt de benodigde broninformatie voor de informatiesystemenstructuur en de technologie-architectuur.

2. Informatiesystemenstructuur (waarmee)

Het geheel van toepassingen binnen een organisatie moet bekend (lees: beschreven) zijn. Het gaat om kernapplicaties binnen de organisatie, uitwisseling van data en hoe de applicaties gebruikt worden. Vervolgens is van belang dat de beoogde applicatiestructuur beschreven wordt. Hierin moet minimaal verwerkt worden welke informatiesystemen ondersteund (zullen) worden (reikwijdte) en hoe de processen/verwerking (dan) verloopt inclusief het resultaat. Tot slot is het van belang om te weten wat het verschil is tussen de bestaande en de beoogde informatiesystemeninfrastructuur. Deze beschrijving geeft broninformatie voor de technologie-infrastructuur.

3. Technologie-architectuur (hoe)

Het kader voor de technologie-architectuur is de bedrijfsarchitectuur. De reikwijdte is de informatiesystemenarchitectuur. Technologie-architectuur gaat over de netwerk- en serverconfiguraties (inclusief virtuele servers en containers), NAS-apparaten, softwarelicenties, contracten, back-ups en dergelijke. Uit het overzicht moet duidelijk zijn wat beschikbaar is om het geheel van toepassingen te ondersteunen. Vervolgens moet blijken welke technologie nodig is voor de beoogde IT-omgeving. Het doel is om het geheel van de beoogde toepassingen te ondersteunen. Tot slot moet het verschil tussen de huidige en de beoogde technologie-infrastructuur duidelijk beschreven worden. Aandachtspunten en risico's moeten duidelijk zijn.

Concrete invulling

Het voorgaande is abstract. De vraag is hoe deze methode concreet gebruikt kan worden. De concrete invulling begint met het stellen van de bovenstaande vragen en het noteren van zowel de vragen als de antwoorden. Het is goed om dergelijke vragen vanuit de verschillende disciplines (en invalshoeken) te bekijken. De kans van slagen neemt toe door in groepsverband naar de inrichting van de IT-omgeving te kijken.

Dit laatste kan betekenen dat een uitvoerende IT-medewerker van een IT-leverancier en de eigenaar van een eenmanszaak met elkaar aan tafel zitten. Bij een wat grotere organisatie kan het betekenen dat de bedrijfsleider, de administratief medewerkster, de verkoopmedewerker en de IT-medewerker bij elkaar zitten.

Wat de samenstelling ook mag zijn: het is van belang dat de IT-medewerker begrijpt waar het om gaat. Wat is het eigenlijk voor organisatie waarvoor een IT-omgeving gebouwd moet worden? Wat is het doel van de organisatie? Wat is er op dit moment ingericht? Hoe verhoudt de huidige inrichting zich tot de processen? Waar wil de organisatie naartoe groeien? Met welke problemen worstelt de organisatie? Wat zijn de mogelijkheden? Wat is het budget? Hoe kan het inzetten van IT er voor zorgen dat de processen beter verlopen? Hoe kan er voor gezorgd worden dat de organisatie beter ondersteund wordt?

Voortschrijdend inzicht

Voortschrijdend inzicht betekent in de positieve uitleg dan men al doende leert - om vervolgens tot de conclusie te komen dat het anders had gemoeten.

Een voorbeeld van voortschrijdend inzicht uit de praktijk vind ik een organisatie waarbij niet gekeken werd naar hoe de werkzaamheden werden uitgevoerd. Er werd gekeken naar hoe een kantoormedewerker zijn of haar werkzaamheden deed. Er werd niet naar de samenhang - en de verschillen - tussen de verschillende afdeling gekeken. Er werd voorbij gegaan aan het volledig invullen van o.a. deze belangrijke vraag, waardoor er gekozen werd voor een inrichting op basis van een terminalserver model.

Bij een terminalserver model krijgen de gebruikers elk een virtueel bureaublad op de server. Vanaf de werkplek (lees: terminal) wordt er verbinding gemaakt met het virtuele bureaublad op de server. Dit betekent dat de gebruiker zelf niets kan installeren en ook geen randapparatuur of verwisselbare media (zoals CD-ROM's en USB-sticks) kan gebruiken. Tevens werd de keuze gemaakt om de werkplekken niet centraal te beheren. De redenering was dat het centrale beheer voldoende was afgedekt op de server. De werkstations werden gezien als domme terminals. De functionaliteit van de werkstations werd vervolgens beperkt, aangezien de enige functie het verbinden met het virtuele bureaublad op de server overbleef.

Het resultaat was een (grotendeels) ineffectieve en disfunctionele IT-omgeving, omdat de magazijnafdeling de vele CD-ROM's en USB-sticks niet kon gebruiken. Ook de applicaties op de CD-ROM's en USB-sticks konden niet meer gestart worden. Het bleek dat het zelfstandig kunnen installeren van de applicaties - die werden aangeleverd op CD-ROM's en USB-sticks belangrijk was. Maar het meest belangrijke wat naar voren kwam, was dat de CD-ROM's en USB-sticks van essentieel belang was voor het functioneren van de magazijnafdeling. Daarnaast bleek dat er tevens bon printers aangestuurd moeste kunnen worden vanuit de desbetreffende applicaties.

Als oplossing werd vervolgens bedacht dat de desbetreffende programma's op de gegevensdragers dan maar op de werkstations geïnstalleerd moesten worden - onder een lokale gebruiker. Dit laatste betekende dat er een wildgroei ontstond aan losse gebruikersaccounts - met uitgebreide rechten - op verschillende werkstations, waardoor de IT-omgeving onnodig complexer en minder beheersbaar werd. Bovendien moesten de werkstations zo aangepast worden, zodat de medewerkers beheerrechten kregen. Het resultaat was een minder veilig en minder goed functionerende magazijnafdeling , ontevredenheid bij de magazijnmedewerkers - en uiteindelijk ontevredenheid bij de directie.

Een les die uit het voorgaande geleerd kan worden is dat er goed gekeken moet worden naar hoe werkzaamheden (processen) uitgevoerd worden, door de verschillende afdelingen (wie) en om welke programmatuur en data het gaat. Daarbij moet gelet worden op de systeemvereisten van de verschillende applicaties, zoals bijvoorbeeld de benodigde beheerrechten. Indien de bijbehorende applicatie niet uitgevoerd kan worden, dan kan de informatie niet geraadpleegd (of verwerkt) worden. Dat betekent dat een taak niet uitgevoerd kan worden.

Gezien het gebruik van de applicaties op de werkstations van het magazijn, hadden de werkstations beter aangemeld kunnen worden op de serveromgeving. Was dat geregeld, dan hadden die systemen - en de desbetreffende gebruikersaccounts - centraal beheerd kunnen worden.

Omdat uitgebreide rechten op gebruikersaccounts een beveiligingsrisico inhoudt, had ook beter nagedacht moeten worden over de inrichting van het netwerk. Zo had de magazijnafdeling bijvoorbeeld beter in een apart geïsoleerd netwerk gepast, om de bijbehorende risico's te mitigeren. Op een geïsoleerd netwerk kunnen beperkingen opgelegd worden, zodat risico's door bijvoorbeeld een virusuitbraak beter in de kiem gesmoord kunnen worden.