Berichten door Rolf Heijden

Digitalisering vereist een goed en adequaat veiligheidsniveau. Cybersecurity is dan ook een belangrijke randvoorwaarde voor digitale transformatie. Beveiliging begint met het inrichten en documenteren van de bedrijfsprocessen. ROUR helpt organisaties op elk niveau van hun veiligheidsinrichting en beheer, van bewustwording tot concrete oplossingen voor digitale beveiliging. ROUR helpt bij certificeringen, zoals ISO 27001, en biedt ook CISO as a Service aan.

Hoe bewaak ik de consistentie tussen uitgevaardigde wet of business rule en de implementatie daarvan in mijn organisatie 

Wetswijzigingen , wijzigingen in de dienstverlening of in producten leiden impliciet tot veranderingen in bedrijfsprocessen en hun IT systemen. 

Hoe gaan we daar mee om nu de veranderingssnelheid toe blijft nemen ? 

Met transparantie bedoelen we hier: inzicht in zowel de besluitvorming als de uitvoerende processen en tussenproducten en de kwaliteit daarvan. Hoe komen bij een project de besluiten tot stand. Welke besluiten zijn waar, door wie en waarom en wanneer genomen en op welke wijze zijn of worden genomen besluiten geïmplementeerd. En hoe is of wordt gecontroleerd of e.e.a. compliant (conform de voorschriften) is en of het doet waar het voor bedoeld is.

Hoe eerder verkeerde besluiten aan de orde komen hoe minder ICT-faalkosten. Hoe minder schade. 

Hoe maken we een en ander transparant? Door verslaglegging van bestuursbesluiten, vergadernotulen en besprekingsverslagen op gestructureerde wijze vast te leggen en toegankelijk te maken. Dit geldt ook voor de verslagen van de voortgangsvergaderingen van de operationele bedrijfsprocessen die duidelijk maken waarom bepaalde beslissingen zijn genomen en wat de doelen waren op het moment van besluitvorming.

 Dit kan eenvoudig met elk DMS (Document Management System) gerealiseerd worden, als dat al niet het geval is.

 Het wordt pas echt transparant als er ook functionaliteit wordt toegevoegd en gebruikt om de relaties te leggen tussen de verschillende documenten, die in de tijd een spoor vormen.

Dit kan op allerlei manieren en is vrij eenvoudig te implementeren. Dan zijn we een stapje verder. Gaan we nog een stapje verder dan leggen we ook de relatie van een aantal kwaliteitsdocumenten vast. De lokaal gehanteerde systeemontwikkelmethode is daarvoor de leidraad. Voorbeelden van kwaliteitsdocumenten zijn bijvoorbeeld: Het Plan van Aanpak, de Business Case, de Functionele Specificatie, een Change Request, een Change, de Testset, het Acceptatietestplan etc. Goed versiebeheer is hierbij een belangrijk issue.  Als wijzigingen chronologisch traceerbaar zijn, zijn we al een belangrijk stap verder.

Op deze wijze kun je het proces een stuk transparanter maken. Gaan we nog een stap verder dan koppelen we ook de opgeleverde, gebouwde deelproducten aan elkaar en aan de genoemde kwaliteitsdocumenten. Zodat de relaties tussen alle producten en hun specificaties zichtbaar zijn. Een stapje verder nog en we voegen functionaliteit toe om vanuit elk punt te zien wat de herkomst is en wat de gevolgen zijn geweest. Daarmee wordt dan een betere traceerbaarheid gecreëerd waarmee je ook voor toekomstige wijzigingen impactanalyses kunt uitvoeren. De kosten, benodigde inspanning, doorlooptijd en planning voor elke verandering zijn dan veel nauwkeuriger en veel eenvoudiger van tevoren vast te stellen.

Traceerbaarheid  is het enige wapen om in de toekomst sneller en beter en nauwkeuriger aan te geven wat er moet gebeuren en wat het kost en hoeveel tijd het kost om wijzigingen te implementeren. 

Als je dit niet implementeert, dan zal je in de toekomst geen enkele verbetering in kwaliteit en betrouwbaarheid en planbaarheid van informatiesystemen gaan zien. Net zoals we dat de afgelopen 20 jaar niet gezien hebben.  Een en ander is natuurlijk ook het gevolg van de steeds sneller veranderende digitale wereld. Traceerbaarheid invoeren of verbeteren is een van de sleutels om tot meer kwaliteit en geloofwaardigheid van de ICT te komen.  Hier geldt dat stapsgewijze verbetering plaats kan vinden, door te beginnen op de plaatsen waar het gebrek aan traceerbaarheid een belangrijke oorzaak is van knelpunten, vertragingen en kostenverhogingen.

Bij veranderingen aan bestaande applicaties is het bepalen van welke programma’s moeten veranderd worden soms een puzzel. Het is dus essentieel om te weten, welke functionaliteit precies waar in welke programma s zijn geprogrammeerd.

Hier komt het belang van de kwaliteit van de oorspronkelijke specificaties naar voren. Hoe gestructureerder en hoe eenduidiger de oorspronkelijke specificaties, des te eenvoudiger is vast te stellen wat er precies veranderd moet worden. Het helpt aanzienlijk als ook het wijzigingsvoorstel een eenduidige structuur heeft en liefst overal hetzelfde is. Traceerbaarheid aanbrengen begint voor wat het ICT-voor- traject betreft dus met structuur in je specificaties.

We pleiten niet om de boel op de kop te zetten, maar om in elk geval voor nieuwe analyses en ontwerpen gelijke structuren te gebruiken die traceerbaarheid vereenvoudigen.

Voor bestaande applicaties kun je bijvoorbeeld een eenduidige structuur aanbrengen in de oude specificaties en deze koppelen aan de bijbehorende verzameling wijzigingen die in de tijd hebben plaatsgevonden.  Het is evident dat dit interessanter is voor applicaties die vanuit hun aard hoogfrequent veranderen, dan voor applicaties die nooit of bijna nooit veranderingen te verwachten hebben vanuit wetgeving of andere externe invloeden.  Voor geheel verouderde applicaties die onderhevig zijn aan veel wijzigingen zou je in eerste instantie een vorm van re-engineering van alle specificaties kunnen overwegen… Of als dat niet helpt re-engineering van het geheel.

E.e.a. kan met beperkte aanpassingen van de informatiesysteem-ontwikkelmethode worden geïmplementeerd.

In het ideale plaatje van traceerbaarheid zijn documenten uit de business en business-analyse-fase te koppelen aan functionele specificaties en use-cases. Terwijl vanuit functionele specificaties en use-cases verbanden gelegd zijn met, database items, programmatuur, testsets, bevindingen, change requests en database changes.

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 in de buitenwereld raakt het informatiesysteem. De mate van veranderbaarheid van het informatiesysteem 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 indirect 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 meer !) 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. 

Gezocht voor overheid en semi-overheid

• Business analisten
• Interim managers voor operatie en infomatievoorziening
• QA specialisten
• Systeembeheerder management

Solim is onder meer Value Added Reseller van het Australische Sparx Systems. Dit betreft met name Enterprise Architect, het modeling tool van Sparx dat uitermate geschikt is voor Life-Cycle Software Design en Management. Dit omvat het modelleren, het managen en het tracen  van softwareproducten en processen over de gehele development cycle. Het biedt o.a. volledige traceerbaarheid van requirements,  requirements analyse en ontwerp artefacts, tot en met implementatie en uitrol.  Dit gecombineerd met ingebouwde taakstructuren en resource allocatie, biedt het project managers and QA teams het gereedschap en de informatie om hun projecten op schema te houden.

Met de impliciete requirements management mogelijkheden helpt  Enterprise Architect je; van high-level specificaties tot analyse, ontwerp, implementatie, test en onderhoud. Met gebruikmaking van  UML, SysML, BPMN en andere open standaards. Enterprise Architect is een multi-user, grafisch tool, ontwikkeld om ICT teams te helpen  om robuuste en onderhoudbare systemen te bouwen en gedurende de gehele lifecycle eenvoudig  te managen. Dit met kwalitatief hoogwaardige rapportages en documentatie.