Lines‎ > ‎

Het belang van technologie

posted Dec 19, 2013, 3:22 AM by Jerry Dawson

Translated for me by Esther de Lange

Het volgende document is een uittreksel van een uiteenzetting over de architecturale benadering voor een niet-technisch leidinggevend publiek.

               

De technologie met betrekking tot computers, computergebruik en computerisering werd op de werkplek jarenlang gezien als het domein van de verspreiders van mysterieuze kennis die totaal afgescheiden waren van de “businesswereld” waarin alle anderen zich ophielden. Deze scheiding tussen de businesskant en de IT-kant werd soms door beide kanten nog eens extra versterkt. De business gaf IT de schuld als dingen verkeerd gingen en IT gaf ‘de gebruikers’ de schuld, omdat ze maar wat deden en niet wisten waar ze mee bezig waren.

 

De laatste jaren is er echter aanzienlijk veel moeite gedaan om deze scheiding niet alleen te overbruggen, maar om deze zelfs geheel te laten verdwijnen. Dit vanwege de eenvoudige reden:  IT en ‘de business’ zijn één en dezelfde. Tijdens het werk van alledag heeft men te maken met enorm ingewikkelde technologie, of het nou gaat om een PC met standaard bureaubladsoftware, een smartphone die constant gebruikt wordt voor het internet of een medisch apparaat als een MRI-scanner.  Technologie is gewoon een verzameling werktuigen die een organisatie in staat stelt bepaalde activiteiten uit te voeren.

 

Er is een nieuwe generatie opgegroeid en toegetreden tot de beroepsbevolking die net zo bekend is met de grondbeginselen van de technologie als vorige generaties waren met pen en papier.  Ze begrijpen de taal van muis en pictogrammen, ze navigeren instinctief door websites en toepassingen, en het allerbelangrijkste, ze begrijpen dat verandering constant en onontkoombaar is.

 

Deze verandering in de gebruikerscultuur die de afgelopen tien jaar heeft plaatsgevonden wordt gemakkelijk over het hoofd gezien, omdat we gewend zijn geraakt aan deze snelle verandering en er gemakkelijk in meegaan. Een andere grote verandering die gemakkelijk over het hoofd wordt gezien betreft de technologie zelf. Ook al heeft er geen fundamentele revolutie zoals de PC of het internet plaatsgevonden, cultuurveranderende revoluties van decennia geleden, de technologie heeft op een ietwat subtielere manier wel gezorgd voor een uitbreiding van de mogelijkheden. De afgelopen tien jaar is de manier waarop mensen met technologie omgaan enorm veranderd. Dit heeft te maken met de toegenomen computerisering en de daarmee gepaard gaande toename van het computergebruik, de toename van computervermogen, van het gebruik van mobiele apparaten, het internetgebruik en van de computersnelheid.  Zelfs degenen die in de informatietechnologie werken zijn zich vaak niet bewust van de omvang van de verandering die heeft plaatsgevonden. Door deze verandering, zijn de verwachtingen die mensen van technologie hebben ook veranderd.  Directe toegang tot informatie en diensten is de feitelijke standaard, vooral onder de nieuwe generatie binnen de beroepsbevolking.

Deze veranderingen binnen de technologie en haar symbiotische relatie met de cultuur, vormen een uitdaging voor alle organisaties. Over het algemeen bestaat deze uitdaging uit:

·         Externe eisen – de uitdaging om de vraag naar dienstverlening van klanten buiten de organisatie tegemoet te komen.

·         Interne eisen–de uitdaging om werkmethodes aan te passen en nieuwe mogelijkheden te benutten.

 

Veel, of misschien wel de meeste, organisaties hebben aanzienlijk veel problemen gehad met het omgaan met de veranderingen. Ten eerste, omdat alleen al de omvang van de verandering soms moeilijk te bevatten is. Ten tweede, doordat de investering die nodig is om gebruik te maken van de nieuwe technologie wordt beperkt door een gebrek aan financiering. Het resultaat is vaak een “als-het-niet-stuk-is-hoef-je-het-ook-niet-te-makenbenadering”.

 

Maar deze benadering ziet een fundamenteel aspect van door technologie gedreven verandering over het hoofd. Geen enkele boer zou een door een paard getrokken ploeg blijven gebruiken in plaats van een tractor, omdat ze beide werken, dus waarom zou je iets veranderen? De voordelen in productiviteit zijn immers overduidelijk. Geen enkele consument blijft zwart- wittelevisie kijken, enkel en alleen omdat zijn toestel het nog goed doet. Technologie maakt verandering mogelijk en daardoor soms onvermijdelijk.

De architecturale benadering: Voordelen van het zien van het grote geheel

               

Er is nog steeds behoorlijk veel discussie en verwarring, zelfs binnen de IT, over wat een architecturale benadering inhoudt. Alsof ze willen bewijzen dat ze net zo immuun zijn voor verandering als iedereen, beschouwen veel IT-ers van de oude garde, architecten gewoon als senior developers met een vervelende houding. De meeste enterprise architecten, daarentegen, zouden zeggen dat hun werk maar voor een klein deel uit IT bestaat en dat veel van hun werk juist op het businessvlak ligt.  Ze moeten naar het grotere geheel kijken, naar de organisatie als een verzameling mensen, processen en systemen die met elkaar in verbinding staan en deze onderlinge verbondenheid betekent dat er geen op zichzelf staande oplossingen zijn.

Ontwerpen voor klanten, niet voor de IT

 

Dus wat betekent de architecturale benadering nu in de praktijk? We kunnen een vergelijking maken met de rol van een traditionele architect. De klant zegt: “Bouw een huis voor me met drie slaapkamers en een keuken.”  De rol van de architect is dan om te begrijpen wat de klant nu precies wil – hoe groot moeten de slaapkamers zijn? Voor wie zijn ze bedoeld? Moeten ze een eigen badkamer hebben? Moet de keuken een woonkeuken worden of heeft men liever een aparte eetkamer? Er zijn heel veel vereisten die uitgewerkt moeten worden, voordat de architect en de klant het eens kunnen worden over een ontwerp. Het ontwerp wordt vervolgens overhandigd aan een bouwbedrijf en de architect blijft bij het project betrokken als vertegenwoordiger van de behoeften van de klant.

               

Dit is dan ook de essentie van de architecturale benadering – om de scheiding tussen klant en bouwer te laten verdwijnen, tussen ‘business’ en IT.

 

Net zoals een traditionele architect werkt binnen een kader van technische kennis – de fysieke eigenschappen van verschillende materialen, het in acht nemen van veiligheidsvoorschriften, enz. – doet de enterprise architect dat ook.  Door de technologische mogelijkheden te begrijpen en uit te leggen aan de klant, biedt de architect de klant de mogelijkheid om betrokken te zijn bij het proces van ontwerp en ontwikkeling.

Oude en nieuwe modellen vergelijken

 

Wanneer nu een programma wordt gelanceerd over de gehele organisatie van een onderneming of over een groep organisaties, zullen er veel verschillende partijen zijn die allemaal verschillende dingen willen. Centraal binnen de benadering staat dan ook; begrijpen hoe men binnen één overkoepelende architectuur tegemoet kan komen aan de eisen van verschillende klanten. Dit is waar het begrip ‘hergebruik’ volledig tot zijn recht komt.  Verschillende onderdelen van een onderneming zullen altijd verschillende vereisten hebben, maar omdat ze allemaal passen binnen het grotere geheel van organisatorische activiteiten, zal er onvermijdelijk een overlapping zijn tussen vereisten voor verschillende projecten. De architectuur creëert bouwstenen door de onderdelen waaruit de verschillende projecten zijn opgebouwd van elkaar te scheiden. Dit zijn herbruikbare componenten waarmee opnieuw iets gebouwd kan worden.

 

Hier wordt duidelijk wat het grote voordeel is van de architecturale benadering ten opzichte van oudere methodes. Het traditionele IT-model was:  één oplossing voor één groep vereisten. Dus het plaatje zag er ongeveer zo uit:

·         Eén afdeling heeft een aantal vereisten. Hier wordt aan tegemoet gekomen met één op zichzelf staande oplossing.

·         Een tweede afdeling heeft een ander aantal vereisten.  Men komt met een andere op zichzelf staande oplossing.

·         Een derde afdeling heeft data nodig van de eerste twee afdelingen om te gebruiken voor weer een ander aantal vereisten. Weer wordt een op zichzelf staande oplossing geleverd en de benodigde data worden handmatig verkregen uit de eerste twee systemen.

 

Iedere keer als een afdeling met een nieuw stel vereisten kwam, werd er een nieuw systeem gebouwd met eigen ondersteuning en gebruikersgroepen.  Iedere keer als er data van het ene naar het andere systeem overgezet moesten worden of als er data uit twee verschillende systemen samengevoegd moesten worden, voerden handmatige processen en werkbladen hoogtij.

 

Iedere keer als er een verandering nodig was, hielden de makers van de verschillende systemen zich bezig met het bewerkstelligen van deze verandering en dit werd het businessmodel voor veel softwareproducenten. Ze maken ieder onderdeeltje van hun systeem specifiek voor iedere afzonderlijke locatie op maat en binden hun klanten aan zich met doorlopende ontwikkelings- en onderhoudscontracten, waarbij veel van de op maat gemaakte systemen continu worden aangepast. De softwarebedrijven kunnen de tarieven vervolgens zo hoog maken als ze willen, vanwege hun monopolie en omdat de klanten afhankelijk van hen zijn. Tarieven van zo’n 1700 euro per dag zijn niet ongewoon. Dit zeer voordelige businessmodel voor IT-verkopers betekent ook een hoge Total Cost of Ownership (TCO) voor hun klanten (zie hieronder).

 

En heel belangrijk, deze benadering betekent ook een zeer intensief gebruik van human resources. Degenen die het systeem bedienen en de IT-ondersteuning moeten apart worden opgeleid voor elk individueel systeem met elk zijn eigen hebbelijkheden.  Handmatige processen hebben meer mensen nodig voor het maken en bijhouden van werkbladen. En terwijl de kosten voor het upgraden of het vervangen van een onmisbaar systeem voor het bedrijf stijgen, raakt de op zichzelf staande oplossing steeds meer verouderd en kost het steeds meer moeite om deze in stand te houden.

 

De architecturale benadering daarentegen, legt de nadruk op standaardisering en hergebruik en ziet er ongeveer zo uit:

 

·         Eén afdeling heeft een aantal vereisten. De architect kijkt hoe deze vereisten passen binnen het gehele bedrijf. De geleverde oplossing is ontworpen met een gestandaardiseerde functionaliteit en klaar om geïntegreerd te worden met andere systemen.

·         Een tweede afdeling heeft een ander aantal vereisten.  De eerste oplossing kan worden uitgebreid om tegemoet te komen aan de nieuwe vereisten.

·         Een derde afdeling heeft data nodig van de eerste twee afdelingen om te gebruiken voor weer een ander aantal vereisten. Een nieuwe groep functionaliteiten wordt geleverd. Databeheer wordt toegevoegd om er zeker van te zijn dat er ‘één enkele bron van waarheid’ is.

 

Het uitgangspunt is om waar mogelijk uit te breiden en te hergebruiken.  Tegemoet komen aan de vereisten is een kwestie van het leveren van een dienst, en deze dienst kan worden aangepast en veranderd, wanneer de situatie verandert door nieuwe mensen aan het stuur. Daarom heet dit Service Oriented Architecture (SOA). Data worden van elkaar gescheiden en snel uitgewisseld tussen systemen, waarbij men altijd zeker is van een bron van master data die men kan handhaven als de enige bron van waarheid.

 

Veranderingen vinden dan plaats op één plek. Standaardisatie betekent dat ontwikkelingen op zo’n manier plaatsvinden, dat ze zowel door developers als gebruikers meteen worden begrepen. De strategie van Shared Information Services is om algemene technologieën te gebruiken, waardoor wordt gegarandeerd dat men voor ontwikkeling gebruik kan maken van vaardigheden die overal beschikbaar zijn; contractanten kunnen gemakkelijk worden gevonden en interne mankracht kan worden opgeleid. En, heel belangrijk, de afhankelijkheid van (vaak kleine) dure leveranciers verdwijnt.

 

De architecturale benadering vereist in eerste instantie dus wat meer tijd en inspanning, maar door naar het grote geheel te kijken wordt er uiteindelijk bespaard. Doordat de technologie standaard is en de toepassingen allemaal op dezelfde manier werken, kunnen mensen het systeem voor verschillende domeinen gebruiken en in stand houden. Zonder de handmatige inspanning om data tussen verschillende systemen uit te wisselen, is er minder mankracht nodig.

Het eindresultaat is dat de kosten om systemen te ontwikkelen, te leveren en te onderhouden veel minder worden. Een lagere Total Cost of Ownership compenseert ruimschoots de kapitaalinvesteringen die in eerste instantie moeten worden gedaan.  

 

 

Comments