www.it-inspiratie.nl (Homepage van de auteur)

Globalisering (en offshoring) van systeemontwikkeling stelt organisaties zwaar op de proef

 

De internationalisering van het ontwikkelen van ICT systemen roept veel vragen op. Wie is eindverantwoordelijk voor het gedistribueerde ontwikkelproces? Hoe worden kosten verdeeld? Wat gebeurt er met de boventallige medewerkers? Wat zijn de enablers van offshore development?

 

Auteur: Iwanjka Geerdink, Automatiseringsgids mei 2002

 

Er vindt een globalisering plaats van ICT-systeemontwikkelingsprocessen. Een grote Nederlandse bank laat halffabrikaten van applicaties in Pakistan bouwen en een andere grote financiële instelling is bezig de ontwikkeling van Java-componenten te outsourcen aan Nederlandse ICT-dienstverleners. Dezelfde trend zal ongetwijfeld bij andere multinationals waarneembaar zijn. De impact op deze organisaties is aanzienlijk: het werk van honderden ICT’ers verandert en hun bestaan wordt onzekerder. Het management vraagt zich af hoe systeemontwikkeling – en systeembeheer – nog georganiseerd kan worden. Landen als Pakistan, India, maar ook bijvoorbeeld Polen zien een gouden toekomst voor zich.

Van oudsher waren financiële instellingen zekere werkgevers die een baan voor het leven boden. De huidige outsourcingsmogelijkheden leiden ertoe dat het ICT-management een instrument in handen krijgt om bepaalde onderdelen uit het systeemontwikkelingsproces uit te besteden aan derden. Interne ontwikkelaars hebben in dergelijke gevallen het nakijken. Het systeemontwikkelingswerk verdwijnt naar een land als Polen of India, naar een Nederlandse ICT-dienstverlener of mogelijk zelfs naar een concurrent. Wat overblijft is vaak de integratie- en productieomgeving: de elders gefabriceerde onderdelen worden in Nederland geïntegreerd tot één geheel, en dit geheel moet draaiend gehouden worden in een productieomgeving.

Het product- en projectmanagement zijn ook activiteiten die minder snel ge-outsourced zullen worden. Maar analoog aan fabrieken van (bijvoorbeeld) Philips die her en der in Nederland de poorten gesloten hebben, zal dit ook gaan gebeuren voor systeemontwikkelingsafdelingen in Nederland. Dat de mogelijke implicaties voor medewerkers groot zijn, is evident. Naast de impact voor de individuele medewerker verandert er ook wat voor de Nederlandse ICT-servicebedrijven: zij moeten gaan concurreren met buitenlandse aanbieders.

 

Ontslagen

Ook het (project)management ontspringt de dans niet: hoe managet men een dergelijk gedistribueerd systeemontwikkelingsproces? Met welke externe partijen gaat men in zee? Wat wordt er gedaan met de boventallige medewerkers? Welke architectuur wordt gehanteerd en hoe sluit de ICT-ontwikkelstraat (zie kader) hierop aan? Dit zijn allemaal vraagstukken waar de conventionele manager, die met name interne systeemontwikkelingsprojecten heeft gemanaged, nog nauwelijks mee te maken heeft gehad. Om dergelijke processen te kunnen managen is bijvoorbeeld een gedegen inzicht in softwareontwikkeling en de (on)mogelijkheden van de gehanteerde architectuur essentieel.

En de boventallige medewerkers? Idealiter kunnen deze mensen omgeschoold worden tot de ‘achtergebleven’ functies. Populair is ook de inrichting van een aparte business unit die moet gaan concurreren met ‘externe’ leveranciers voor het maken van componenten en applicaties. De praktijk wijst echter uit dat de omscholing van een Cobol-batch-ontwikkelaar naar een Java-ontwikkelaar in servicegeoriënteerde architectuur een moeizame weg is. Bestuurders lijken dit nog al eens te vergeten: je kunt niet willekeurig met mensen schuiven en vervolgens verwachten dat je een professionele gekwalificeerde systeemontwikkelingsafdeling overhoudt, een dergelijk proces kost simpelweg veel tijd en energie. Als omscholing of herplaatsing niet mogelijk is, schuwt men tegenwoordig niet meer mensen te ontslaan.

Het aantal partijen dat betrokken is bij de ontwikkeling, het beheer en het operationeel houden van systemen neemt zienderogen toe. Zo heeft een grote Nederlandse bank een internetapplicatie waarvan het applicatiebeheer – in eerste instantie – door een leverancier in India wordt gedaan, de eerstelijns helpdesk is in Nederland gevestigd en de exploitatie van het mainframe wordt door verschillende afdelingen in de VS gedaan. Dit zijn slechts drie van de al gauw tientallen componenten en/of afdelingen die met behulp van service level agreements (SLA’s) moeten samenwerken.

Voorbeelden van punten die in deze overeenkomsten vastgelegd moeten worden, zijn: wie ‘overall’ verantwoordelijk zijn voor de afhandeling van incidentmeldingen van klanten, hoe prioriteiten worden gesteld, hoe wordt omgegaan met gemaakte kosten (billing) et cetera. Hierbij speelt bovendien dat voor nieuwe applicaties en/of componenten bestaande SLA’s vaak herzien moeten worden. Deze ontwikkeling leidt ertoe dat het definiëren (en beheren) van SLA’s een activiteit wordt die een significant gedeelte van het ICT-budget opslokt, en dat dit vakgebied zich kan verheugen in een toenemende populariteit.

 

Centralisatie

Wat zijn de oorzaken van deze globaliseringstendens? De volgende drie ontwikkelingen zijn de belangrijkste: ten eerste de opkomst van open standaards voor systeemontwikkeling, ten tweede de volwassenheid van ICT- architectuur en -ontwikkelstraten en ten derde de centralisatie van ICT- systemen.

Om te beginnen de open standaards. De laatste jaren is een aantal standaards ontwikkeld en succesvol in gebruik genomen. De belangrijkste hiervan zijn XML, UML en J2EE. XML is belangrijk omdat deze standaard het mogelijk maakt op eenduidige manier berichten tussen verschillende systemen te specificeren en te implementeren. UML maakt het mogelijk dat specificaties gemaakt door de ene partij (bijvoorbeeld een bedrijf in Nederland) begrepen wordt door een andere partij (bijvoorbeeld een systeemontwikkelingsbedrijf in Pakistan). Als laatste is J2EE belangrijk omdat met deze standaard het mogelijk wordt Java-componenten van verschillende leveranciers te assembleren tot één geheel. Dit laatste kan vergeleken worden met het feit dat, door het gebruik van hardwarestandaards, geheugenchips van verschillende fabrikanten op hetzelfde moederbord passen.

Ten tweede de volwassenheid van architectuur en systeemontwikkeling. Sinds een tiental jaren wordt er gewerkt onder architectuur. Door een architectuur wordt geregeld dat systeemontwikkeling van stabiele kaders wordt voorzien. Passend bij de architectuur zijn vaak ICT-ontwikkelstraten opgezet waarmee analoog aan een fabriek applicaties voor de betreffende architectuur gefabriceerd kunnen worden. Ook voor internetgebaseerde architecturen – denk aan de diverse e-business portals – zijn ontwikkelstraten gevormd. De fabrieksmatige aanpak van systeemontwikkeling zorgt ervoor dat bepaalde processtappen aan derden kunnen worden uitbesteed. Dit komt met name omdat deze processtappen stabiel en goed gedefinieerd zijn.

Ten derde de centralisatie van ICT- systemen. Deze ontwikkeling lijkt strijdig met de inhoud van dit artikel. Het gaat hier echter om de centralisatie van een systeem of ICT-functie, niet om de locatie van de systeemontwikkeling. Het begrip ‘shared service center’ is de laatste jaren in opkomst: centraliseer bijvoorbeeld alle functionaliteit en (ICT-)functies rondom hypotheken in één business unit, en er wordt een schaalvoordeel behaald. De ING Groep heeft bijvoorbeeld een grootschalig programma rondom shared service centers opgezet. De total cost of ownership van ICT wordt op deze manier lager voor de ING Groep.

Een tweede aanleiding voor de centralisatie bestaat uit het uiteenspatten van de internethype: aan het begin van deze hype werden enorme budgetten uitgetrokken voor een palet aan internetinitiatieven: verspreid over de hele organisatie werden internetapplicaties ontwikkeld, soms met een goed uitgedachte architectuur, maar vaak ook zonder. Men realiseert zich nu dat deze pluriformiteit tot onnodige kosten leidt. Gecombineerd met de huidige economische malaise zorgt dit ervoor dat gelijksoortige systemen (bijvoorbeeld meerdere portal-systemen) moeten consolideren tot één systeem. Door deze centralisatie wordt het interessanter om een fabrieksmatig softwareontwikkelingsproces op te zetten, omdat er meer productie gedraaid kan worden met dezelfde fabriek. En zoals boven beschreven, werkt dit indirect outsourcing in de hand.

De uiteindelijke beslissing om over te gaan tot outsourcing berust hoofdzakelijk op het feit dat men hiermee een lagere total cost of ownership en/of een kortere time to market voor ICT denkt te bereiken.

Kortom, er is weer een nieuwe fase aangebroken in systeemontwikkeling. Aan de ene kant zal softwareontwikkeling saaier worden: iedere medewerker binnen een systeemontwikkelingsafdeling heeft zich te voegen naar de regels van een – steeds grootschaligere – architectuur en ontwikkelstraat. Aan de andere kant ontstaat er een nieuwe dynamiek die op zich nieuwe disciplines en creativiteit vergt, bijvoorbeeld: hoe men bij fusies van grote bedrijven de systeemontwikkelingsafdelingen en bijbehorende architecturen en ontwikkelstraten moet integreren, of hoe men overzicht houdt op een infrastructuur waarvan diverse onderdelen buitenshuis zijn gemaakt.

De volgende twee observaties zijn de moeite waard genoemd te worden. Ten eerste: een bij-effect van outsourcing is dat er meer aandacht wordt besteed aan het netjes specificeren van het systeem. Dit komt de kwaliteit en efficiency van het ontwikkelingsproces ten goede. Ten tweede: indien overwogen wordt werk uit te besteden aan een land waar de arbeidskosten lager zijn, dan staan tegenover deze lagere kosten, hogere kosten voor management en afstemming.

De richting waar het in de toekomst heen gaat is moeilijk voorspelbaar. Wie weet speelt over twee jaar de tegengestelde tendens, waarbij men zoveel mogelijk zelf in eigen huis ontwikkelt. Mocht dit gebeuren, dan zal dit met name gebeuren omdat blijkt dat kosten van gedistribueerd ontwikkelen niet opwegen tegen de behaalde voordelen. Verder is het heel wel mogelijk dat webservices en SLA’s samen op zullen gaan, waardoor het mogelijk wordt op basis van SLA-brochures ICT in te kopen.

 

Kader 1 - Systeemontwikkeling

De historie van systeemontwikkeling kan in de volgende drie fasen worden ingedeeld.

1. De jaren tachtig: het merendeel van de systeemontwikkeling vond plaats op mainframes. Er werden specifiek voor mainframe-applicatieontwikkeling zogenaamde ‘ontwikkelstraten’ ingericht. Zo’n straat kan worden gezien als een fabriek voor applicaties, en bestond hoofdzakelijk uit tools voor bijvoorbeeld Cobol-programmering en database-design. Wereldwijde standaards voor analyse en design (bijvoorbeeld UML), OO (objectoriëntatie) en XML waren nog onbekende begrippen.

2. De jaren negentig: midden jaren negentig kwam de multi tier-architectuur in zwang waarbij een architectuur vaak een mix was van backend mainframe-systemen en frontend-systemen, gebaseerd op een variëteit aan ontwikkelingsplatformen en -talen (C++, Java, HTML et cetera). Ook voor dergelijke architecturen werd het concept ontwikkelstraat opnieuw uitgevonden: er werden binnen de organisatie afspraken gemaakt over de te hanteren architectuur en tools en toegestane frontend-ontwikkelingsplatformen. Een en ander werd gecompleteerd door ook voor het proces te standaardiseren op bijvoorbeeld DSDM of RUP en afspraken te maken over ontwerp- en programmeerconstructies (design and implementation patterns). Eigenlijk alleen UML en objectoriëntatie slaagden erin zich voor te sorteren als wereldwijde standaard. De standaard Corba werd gelanceerd door de OMG om systemen beter integreerbaar te maken. Corba kwam niet echt uit de startblokken, maar het vormde wel de basis voor de latere J2EE-standaard van Sun.

3. Het eerste decennium van deze eeuw: rond 2000 begon de periode van open standaards (J2EE, UML, XML). Veel organisaties hebben voldoende ervaring opgedaan met CBD om het in praktijk te brengen. Er ontstaat nu een situatie waarbij de voornoemde ontwikkelstraten zo worden opgezet dat onderdelen door verschillende partijen aangeleverd kunnen worden. Deze ontwikkeling wordt mogelijk gemaakt door de open standaards: door met UML een specificatie op te stellen snapt een ontwikkelaar in India precies wat er gebouwd moet worden, door gebruik te maken van XML ontstaan er veel minder interface-problemen. Door gebruik te maken van Java-componenten, ontwikkeld volgens J2EE, kan een Java-component in Pakistan ontwikkeld worden om vervolgens in Amsterdam in een J2EE- architectuur geïntegreerd te worden. De basis voor globalisering van ICT-ontwikkelingsprocessen is gelegd.

 

Softwarefabriek

Een ontwikkelstraat kan worden gezien als een fabriek voor software. Iets formeler gezegd: Een ontwikkelstraat is een procédé waarmee applicaties of software-componenten met een aantal gemeenschappelijke structuurkenmerken ontwikkeld kunnen worden, door toepassing van een vaste combinatie van processen, methoden en tools.

Om het gedachtegoed van de ICT-ontwikkelstraat duidelijk te maken kan men een parallel trekken met de productie van auto’s. Auto’s worden al sinds jaren niet meer per stuk met de hand gemaakt maar in een fabriek. De reden dat het concept ‘fabriek’ is ontstaan ligt in het feit dat op deze manier efficiency-voordelen behaald kunnen worden. Het maken van een dergelijk ‘generiek ontwikkelingsplatform’ heeft zin als: 1. veel exact dezelfde producten vervaardigd moeten worden (hetzelfde type) en

2. de variëteit tussen producten (typen) ‘voldoende gering’ is. Ten aanzien van het tweede punt: een Ford Focus Wagon verschilt bijvoorbeeld van een Ford Ka. Het verschil is echter dusdanig gering dat er genoeg gelijksoortige structuurkenmerken zijn (de manier van lassen, de manier van verzinken, gemeenschappelijke onderdelen et cetera) om beide auto’s in dezelfde fabriek te laten vervaardigen.

Dit voorbeeld is ook van toepassing op softwareontwikkeling: Binnen een bepaalde bank of verzekeraar worden veel applicaties gemaakt met dezelfde structuurkenmerken (het betreft hier bijvoorbeeld de gebruikte ontwikkelingstaal, software libraries, componenten, architectuur et cetera). Het is zelfs zo dat het wenselijk is om daar waar mogelijk de structuurkenmerken hetzelfde te kiezen. Hoe meer uniformiteit in de structuur van applicaties, des te beter is een systeemontwikkelingsorganisatie in staat efficiënt beheersbare applicaties te ontwikkelen.

Hoe ziet nu een dergelijke ontwikkelstraat er concreet uit? De eenvoudigste vorm is dat men binnen een systeemontwikkelingsorganisatie standaardiseert op een beperkte set aan – elkaar minimaal overlappende – methoden, technologieën en tools. Zo kan men bijvoorbeeld besluiten om als ontwikkelingstaal Java te nemen, als applicatieserver IBM WebSphere, als versiebeheertool CVS en als systeemontwikkelingsaanpak RUP (Rational Unified Process) met daarbij de Rational toolset voor OOAD-(Object Oriented Analysis and Design)-ondersteuning. Een meer complexe vorm is een ontwikkelstraat waarbij slechts het applicatie- en business- model wordt ingevoerd, en waarmee vervolgens met een druk op de knop de applicatie gegenereerd wordt naar een bepaald doelplatform (bijvoorbeeld Java, C++ of Cobol).

 

Afkortingen

UML – Unified Modeling Language

XML – Extensible Markup Language

Corba – Common Object Request Broker Architecture

DSDM - Dynamic Systems Development Method

RUP – Rational Unified Process

J2EE – Java 2 Enterprise Edition

CVS – Concurrent Versioning System

CBD – Component Based Development

Offshore – ‘Overzee’ ontwikkelen van  ICT, over het algemeen in lage lonen landen

 

Iwanjka Geerdink is werkzaam als senior consultant / projectleider bij Ordina