In de loop van de tijd is de rol van ontwikkelaar behoorlijk in ontwikkeling geweest. In elk geval wanneer je het hebt over de verwachtingen en eisen die aan een ontwikkelaar werden gesteld. In de begintijd lag de regie over het te automatiseren deel van het bedrijfsproces bijna volledig bij de ict-afdeling. Door groei in volwassenheid is de regierol in de loop van de tijd door de business overgenomen en acteert ict steeds meer als leverancier. De rol van ontwikkelaar is met deze transitie ook veranderd.
Naast deze rolverschuiving hebben zich in de loop van de tijd ook technologische verschuivingen plaatsgevonden. Zo heeft internet zijn intrede gedaan, worden applicaties met behulp van middleware aan elkaar gekoppeld en is er een groot scala van nieuwe programmeeromgevingen ontstaan. Deze technologische injecties hebben er toe geleid dat applicatielandschappen van een groot aantal organisaties een veelkleurig geheel zijn geworden, maar daardoor ook erg complex.
Lastige en complexe koppelingen tussen systemen zijn eerder regel dan uitzondering. Inhoudelijke kennis van deze koppelingen, of in feite het ontbreken ervan, vormt een ware bedreiging voor de uivoering van bedrijfsprocessen, vooral het bij aanpassen ervan. Zowel voor de ict-organisaties als de ontwikkelaars individueel liggen op dit terrein een tal van uitdagingen.
Vakmanschap
Om deze uitdagingen het hoofd te kunnen bieden, doet binnen veel organisaties de Enterprise architectuur zijn intrede. Dit is een goede zaak en is een goed startpunt om de continuïteit van het bedrijfsproces te waarborgen. Echter, hier zitten wel een aantal impliciete consequenties aan verbonden. De verwachting ten aanzien van ict zijn niet veranderd: wijzigingen in het bedrijfsproces moeten door ict worden gerealiseerd binnen het applicatielandschap, op een verantwoorde manier, snel, effectief, efficiënt, risicoloos en vooral snel. Dit vraagt om vakbekwame, gepassioneerde en gedreven ontwikkelaars, oftewel: van ontwikkelaars wordt vakmanschap verwacht. Want hoe je het ook wendt of keert, softwareontwikkeling is en blijft maatwerk dat vraagt om gedegen vakmanschap.
Hoewel de verwachtingen ten aanzien van het resultaat van dit vakmanschap niet zijn gewijzigd, heeft een enterprise architectuur wel consequenties voor de invulling van het vakmanschap. Daar waar voorheen het vakmanschap vooral werd ingevuld door gedegen en diepgaande kennis van slechts één systeem, is in de huidige situatie kennis van meerdere systemen noodzakelijk om aan de gestelde verwachtingen te kunnen voldoen. Bedrijfsprocessen zijn immers niet meer te herleiden tot één geautomatiseerde toepassing, maar worden ondersteund door een aantal gekoppelde applicaties.
Bedreigingen
Deze open deur heeft er echter niet toe geleid dat organisaties hun ict-huishouding aanpassen. Nog heel vaak zijn development-afdelingen ingericht op basis van expertise, dus op basis van kennis van een applicatie en/of platform. De kennis van ontwikkelaars blijft zodoende beperkt tot slechts een klein deel van het totale bedrijfsproces. Relaties met andere onderdelen van het gehele landschap zijn niet helder. Verschillende ontwikkelteams werken aan diverse projecten die dezelfde onderdelen raken. De onderlinge afstemming tussen deze teams loopt vaak stroef en leidt tot spraakverwarring. Bovendien zien veel bedrijven zich geconfronteerd met single-point-of-failures, de onmisbare medewerker die als enige veel kennis heeft. Door ziekte, overlijden, pensioen of andere uitstroom, vloeit elementaire kennis de organisatie uit.
Alles met elkaar vormen deze knelpunten een bedreiging voor de beheersbaarheid, continuïteit en de toekomstvastheid van het applicatielandschap als geheel.
Investeren
Het oplossen van deze knelpunten vraagt om een investering in invulling van het vakmanschap van de ontwikkelaars. Een investering die gedaan moet worden door zowel de organisatie als de ontwikkelaar zelf. Er zijn hierbij drie deelgebieden te onderscheiden waarop investeringen noodzakelijk zijn:
1. Soft-skills Afstemming is één van de belangrijkste aspecten binnen softwareontwikkeling. Aangezien applicaties veel en complexe relaties hebben met andere applicaties, zijn ook steeds meer partijen betrokken. Hierdoor wordt afstemming steeds belangrijker en zal dat ook meer inspanning van de ontwikkelaar vragen. Vooral door toepassing van agile-ontwikkelmethodieken zie je steeds meer multidisciplinaire teams ontstaan, waarbij elke discipline zijn eigen belangen, aanpak en jargon kent.
Voor een gedegen afstemming of anticipatie in een multidisciplinair team, moeten ontwikkelaars beschikken over een gezonde dosis communicatieve vaardigheden.
Naast het kunnen samenwerken met andere partijen, zal van een ontwikkelaar ook steeds meer gevraagd worden ten aanzien van documenteren. Kennisbanken, wiki's, document-plaza's en dergelijke worden steeds meer in het leven geroepen om onderling informatie en kennis te delen. Investeren in schriftelijke vaardigheden stelt ontwikkelaars in staat de kwaliteit van deze kennisdocumentatie te verhogen.
2. Kennis Verbreden van kennis is het tweede gebied waarop investeringen noodzakelijk zijn om de genoemde bedreigingen te minimaliseren. Voorheen betekende kennis van een applicatie nagenoeg hetzelfde als kennis van het bedrijfsproces. Door de al beschreven complexiteit van het applicatielandschap is deze vanzelfsprekendheid komen te vervallen. Om bijvoorbeeld goed de consequenties van changes in kaart te kunnen brengen, moeten ontwikkelaars zich op functioneel niveau de structuur van het applicatielandschap eigen maken. Zo moet voor een ontwikkelaar bekend zijn op welk onderdeel van het gehele proces zijn of haar programmatuur betrekking heeft en welke rol deze heeft binnen het gehele proces. Dit maakt het eenvoudiger te beoordelen wat de raakvlakken met andere systemen zijn en kan de afstemming op een adequate manier plaatsvinden.
Naast de functionele kennisopbouw, is ook uitbreiding van de technische skills noodzakelijk. De grote verscheidenheid aan technieken als programmeeromgevingen, -talen en interface-implementaties noopt ontwikkelaars tot het opdoen van kennis van deze technieken. Alleen hierdoor is het mogelijk om gedegen impact analyses uit te kunnen voeren en garant te staan voor een kwalitatief goede oplevering van producten.
3. Tooling De complexiteit is vaak zo groot, dat je er niet aan ontkomt om hulpmiddelen in te zetten voor het technische aspect van softwareontwikkeling. Door het geautomatiseerd scannen van het applicatielandschap kan een volledige enterprise configuration repository aangelegd worden, waarmee onder andere het configuratiebeheer goed vormgegeven kan worden. Daarbij biedt deze repository een schat van informatie op aan de technische koppelingen die tussen de systemen bestaan en zijn de technische impact analyses over het gehele applicatielandschap heen compleet en volledig uit te voeren.
Organisaties die te maken hebben met verschillende ontwikkelteams, doen er goed aan te investeren in collaborationtools. Zaken als projectmanagement, versie- en configuratiebeheer, generieke builds en dergelijke zijn op deze manier gecontroleerd en beheerst in te richten.
Conclusie
Het beheren, onderhouden en uitbreiden van applicaties, is een complexe taak geworden. Het vraagt van ontwikkelaars vakmanschap om deze taak op een kwalitatief goede manier uit te kunnen voeren. Door de verschuiving van de rol van zowel ict als ontwikkelaars individueel, moeten er investeringen gedaan worden om dit vakmanschap in te blijven vullen. Dan is het mogelijk om ook in de toekomst de continuïteit van bedrijfsprocessen te waarborgen.
Het zou in dit kader goed zijn om eens stil te staan bij het begrip ‘ontwikkelaar’. ‘De ontwikkelaar’ bestaat namelijk niet, net zomin als ‘de bouwvakker’. Er is geen enkele bouwvakker te vinden die in zijn eentje over alle kennis en vaardigheden beschikt om een willekeurig gebouw te ontwerpen en te bouwen. Er bestaan geen universele bouwvakkers. Er bestaan wel metselaars, loodgieters, elektriciens, betonvlechters, enz. Er is in de bouw ook een duidelijk onderscheid tussen architect en bouwvakker: als de indeling van een woning onhandig blijkt dan geeft niemand de metselaar de schuld, hoewel dat wel degene is die die muren op zo’n onhandige plaats heeft neergezet. Ook zal niemand dan zeggen: nou die metselaar mag wel eens worden bijgeschoold.
Toch is dat laatste wel een beetje wat ik proef in het artikel, alsof de problemen van de hedendaagse IT opgelost worden door van de ontwikkelaars allround specialisten te maken. De lastige realiteit is dat we moeten onderkennen dat de universele vakman in de IT niet meer bestaat. Dat betekent dat de software-architect en projectleider de regie moeten nemen: zij moeten bepalen welke specialisten er nodig zijn en ervoor zorgen dat de juiste mensen de juiste werkzaamheden verrichten.
Alleen als ontwikkelaars weer echte specialisten mogen zijn dan kunnen het weer echte vakmensen worden.
“Vooral door toepassing van agile-ontwikkelmethodieken zie je steeds meer multidisciplinaire teams ontstaan, waarbij elke discipline zijn eigen belangen, aanpak en jargon kent.”
In mijn optiek is *het einde* van de eigen belangen, aanpak en jargon juist het begin van het succes van agile. Het gezamenlijk belang (waardevolle, werkende software opleveren voor de eindgebruiker) wordt gesteld boven het individuele of eigen-discipline belang. Dat kenmerkt een succesvol (al dan niet agile) project.
Ik begrijp het standpunt van Jos. W. Echter: het verschil met de bouwsector is, dat de huidige systeemlandschappen niet door één architect in één bouwproject gerealiseerd zijn. En er zijn -zeker in deze tijd- geen bedrijven die het hele systeemlandschap op de schop nemen. Wat werkt, wordt niet vervangen.
Gevolg is, dat het geheel aan ontwikkelaars (én testers, én beheerders) zich moeten redden in de ontstane complexe omgeving. Christiaan heeft een punt dat de rol van ontwikkelaar wel degelijk veranderd is en dat er van de ontwikkelaars verwacht wordt dat zij hun weg vinden in deze jungle. Juist in die jungle is het niet genoeg om op één punt specialist te zijn, tenzij teams zodanig samengesteld en gemanaged worden dat rekening gehouden wordt met de genoemde risico’s.