Veranderbaarheid van applicaties en TESLA’ s (een softwarefabriek is geen automobiel fabriek)
Hoe breng je in een organisatie wijzigingen aan, rekening houdend met de complexiteit aan deelprocessen, componenten, richtlijnen, procedures, normen en mensen? Bijna elke wijziging raakt het informatiesysteem. De mate van veranderbaarheid daarvan is dus essentieel.
Het beheer van applicaties en systemen, AO en normen en richtlijnen is vaak een hoog frequent gebeuren.. … Hoe stem je het een op het ander af. Hoe weet je dat als je iets wijzigt, dat er verderop niet iets misgaat?
Als je bijvoorbeeld een bepaald programma verandert, waar moet je dan opletten? Een programma verandert niet zomaar, daaraan gaat een change-request vooraf. Dat kan vanuit de gebruikersorganisatie komen. Maar ook van buiten de organisatie.
Stelt u zich eens een TESLA fabriek voor: Vanuit een klacht uit de markt moet het nieuwste Tesla model worden aangepast. Het raamportier werkt niet goed, de aandrijfmotor gaat te vaak kapot. Tesla analyseert het probleem, ontwerpt een nieuwe en bouwt hem. Als e.e.a. gereed is, wordt het in het volgende (!) model voortaan ingebouwd. Het hele proces is gebaseerd op de bouwtekeningen, de specificaties. Die allemaal volgens bepaalde normen zijn gemaakt en die keurig op papier (of in een systeem) toegankelijk zijn opgeslagen. Alles keurig met versienummers en bijzonder eenduidig in tekeningen gespecificeerd met maten, materiaalsoorten etc. Normaal gesproken niets aan de hand. Er is natuurlijk wel een zekere tijd voor nodig …
Nu kijken we naar een “change “ van een applicatie in een informatiesysteem. Hier geldt echter: elke applicatie is uniek en maakt deel uit van een veelal complex informatiesysteem.
Analoog aan de Tesla: We analyseren waar het probleem vandaan komt en analyseren waar “het probleem “ zich feitelijk voordoet in het functioneel ontwerp, technisch ontwerp, hoe e.e.a. gebruik maakt van de database, met welke andere programmatuur er verbanden zijn, welke testsets zijn betrokken, wie is eigenaar van de functionaliteit etc … We passen eerst het ontwerp aan. Maar een ontwerp vereist materiekennis en een grondige analyse van het bestaand ontwerp en ook grondige kennis van de implementatie van de onderhavige functionaliteit in het informatiesysteem en ook kennis van de koppelingen met andere functionaliteit binnen en buiten de organisatie. En natuurlijk is ook nog validatie door de toekomstige gebruiker vereist ….
Het grote verschil met de TESLA is, dat we als we naar de TESLA kijken we te maken hebben met zeer eenduidige blauwdrukken van het mechanische syteem en het electrische systeem. Waar in geval van TESLA zeer actuele en eenduidig interpreteerbare specificaties van zijn. (Denk maar eens aan alle ISO normen, NEN normen , kwaliteitssystemen die e.e.a. borgen e.d.) Ook met name de changes van deze blauwdrukken zijn op uniforme wijze gedocumenteerd en opvraagbaar.
Helaas is dat in de informatiesysteem-wereld allemaal minder geregeld.
Hoofdoorzaken van de verschillen met TESLA zijn:
- Wijze van specificeren (taal, “on-eenduidigheid“)
- Diversiteit van de tussenproducten (overdrachtsproblematiek, materiekennis)
- Diversiteit van de platformen (updates, releases van buiten opgedrongen MS, Oracle, IBM ..)
- Veranderingssnelheid van modificaties door wet- en regelgeving
- Ontbreken van uniformiteit en uitwisselbaarheid
- Ontbreken van traceerbaarheid
- Ontbreken van transparantie
Alsof dit nog niet genoeg is, is het nog niet gedaan met de verschillen met de TESLA fabriek.
Een informatiesysteem bestaat niet alleen maar uit applicaties en infrastructuur. Een applicatie is slechts een hulpmiddel voor mensen om een functie of taak uit te voeren.
Als de TESLA aan het eind van de fabriekshal van de lopende band afrolt, is het klaar. (ok , natuurlijk wat installatie gedoe bij de autodaler en nog wat nazorg )
Bij de oplevering van een applicatie wordt na de acceptatietest een en ander in gebruik gesteld. Dan pas maakt de applicatie deel uit van “ het informatiesysteem“ . De applicatie wordt geïmplementeerd in de organisatie met haar administratieve organisatie en al haar regeltjes en voorschriften. Hoe dient de applicatie gebruikt te worden? En niet mindere belangrijk: hoe gaan de medewerkers om met de output van de applicatie? Deze gebruiken de applicatie output om beslissingen te nemen voor, of over mensen uit de buitenwereld (… ook wel klanten of burgers genoemd …. ) … Notabene: dat zijn dus de mensen aan wie de organisatie en bedrijven (en de mensen die er werken), hun BESTAANSRECHT ontlenen …
Kern hiervan is, dat we ook hier te maken hebben met interpretatie-problematiek.
Hoe moet de functionaris zijn of haar taak uitvoeren enerzijds met de output van de applicatie in de hand en anderzijds met de procedurele beschrijvingen die gebaseerd zijn op wet- en regelgeving …… NB: De werkprocessen en de AO (administratieve organisatie met haar beschrijvingen, normen en richtlijnen) zijn net zoals de technische applicaties (en misschien nog wel mee !) onderhevig aan de vele wijzigingen door wet- en regelgeving.
Hoe snel en hoe goed je ICT en AO kunt aanpassen speelt derhalve een cruciale rol in de veranderbaarheid van organisaties.