Het koppelen van software is een complex en lastig inschatbare klus. Het gevolg: budgetoverschrijding. Dit is de discussiestelling die Computable-lezers vandaag krijgen voorgelegd.
Projecten in de overheidsautomatisering zijn berucht om hun meervoudige uitloop. Ict-projecten lopen uit qua scope, qua complexiteit én qua budget. Naast politieke invloed die de vereisten kunnen veranderen, is software-integratie vaak een groot struikelblok. Het aan elkaar knopen van verschillende – al dan niet oudere – systemen middels tussenliggende software is een complex en vooraf niet goed in te schatten klus. Zie bijvoorbeeld de Amerikaanse ruimtevaartorganisatie Nasa die voor een softwareproject nu met een budgetoverschrijding van 77 procent zit.
Het al tien jaar lopende ontwikkeltraject is voor een systeem dat een raketlancering in al zijn aspecten moet overzien, controleren en eventueel afbreken. Dit omvat dan de mechanische systemen van de raketten, de brandstofniveaus en vele andere betrokken systemen en subsystemen. De Nasa heeft lang geleden gekozen voor integratie, ook om afhankelijkheid van een enkele leverancier te voorkomen. Daar moet wel een (forse) prijs voor worden betaald. Software-integratie is een struikelblok en budgetbom. Wat vind jij?
Het is geen struikelblok, maar een onderschat en ondergewaardeerd vakgebied.
Software integratie betekent dat er samengewerkt moet gaan worden tussen de diverse software teams, maar ook met andere disciplines. Je kunt niet meer als team bepalen wanneer JIJ iets wil gaan leveren, maar afhankelijkheden moeten afgestemd worden. Met name rollen als systeem-architect en system-integrator zijn onontbeerlijk in deze processen.
Een ander struikelblok wat ik tegengekomen ben afgelopen jaren is dat men alleen focust op de software. Echter, bij projecten zoals in het voorbeeld van de NASA, draait de software in een bepaalde context, vaak specifieke hardware. Dat software bij een ontwikkelteam lokaal draait, is dan ook geen garantie dat deze op de eindhardware, al dan niet in combinatie met de software van andere teams, wel goed draait.
De prijs van het niet of gedeeltlijk integreren van de primaire processen wordt (helaas) achteraf betaald…
Bezint eer gij begint. Maak eerst een proces ontwerp met een duidelijk onderscheid tussen het primaire proces en de afgeleide (administratieve, procedurele, financiële, etc.) processen.
ICTechnologie is, zoals iedere technologie, een hulpmiddel en geen doel op zich.
Onderschat en vaak te snel geïmplementeerd; Koppelingen die op het verkeerde nivo gemaakt worden om politieke redenen, met achteraf een gebrekkige interface, leiden vaak tot hogere bedrijfskosten en gebrekkige informatie(overdracht); Techniek is meestal niet het struikelblok. Bij de selectie van subsystemen wordt vaak te weinig nagedacht over de integratiemogelijkheden
Integratie hoeft geen struikelblok te zijn wanneer organisaties dit via een agile methode toepassen. Definieer je doel en hou rekening met groei door het project heen. De budgetbom begint af te tellen wanneer integratie is gebasseerd op consultancy. Iedere verandering moet doorgevoerd worden wat weer geld kost.
Toch gaat de bom pas echt af wanneer ook de kosten van de aanschaf van de software hoger liggen door langere implementatie periode wegens onvoorziene omstandigheden. Maak niet dezelfde stappen als Nasa neem contact met ons op Quant ICT Group, glenda@quant-ict.nl
@glenda: agile en integratie gaan vaak juist niet samen. Scaled Agile (SAFe) voorziet daar al een stuk beter in. Heb ik geen quant-ict voor nodig