Is Uw ICT Architectuur te Complex...?

Aan iedere CIO, CTO en Softwarearchitect die graag een beter begrijpbare en beheersbare ICT architectuur en applicatieomgeving wil.

Lees mijn gratis rapport om te leren hoe u in een paar weken tijd uw organisatie en applicaties inzichtelijker maakt en daarmee uw resources efficiënter benut, terwijl de kwaliteit van uw ICT Architectuur toeneemt en u een grotere klanttevredenheid bereikt.

Sinds 1986 ben ik met veel plezier werkzaam in diverse takken van automatisering. Eerst in dienst van diverse softwarebedrijven, later als zelfstandig ondernemer. Ik heb mij in die tijd ontwikkeld van programmeur tot ICT architect. Bij mijn werk ben ik altijd op zoek naar pragmatische oplossingen die direct voordeel bieden aan mijn klant.

In de vele projecten waarin ik heb meegewerkt, kwam ik heel vaak de volgende problemen tegen:

• Er was geen of weinig overzicht over alle onderdelen van de ICT Architectuur
• Het ontwikkelteam was meer bezig om correcties aan te brengen dan nieuwe functionaliteit te ontwikkelen
• De planning die aan een klant werd afgegeven was vaak niet correct en leidde tot vertraging
• Als gevolg hiervan, was de klant vaak niet tevreden, en
• Was het team niet altijd gemotiveerd

Mijn overtuiging is dat deze problemen worden veroorzaakt door een gebrek aan inzicht in de ICT Architectuur.

Waardoor is het zo gekomen met de ICT Architectuur?

Vaak zie ik dat een ICT Architectuur organisch is gegroeid. Er waren verschillende systemen en er kwam behoefte om gegevens tussen die systemen uit te wisselen. Dus werd er een brug gebouwd. Meerdere systemen leverden meerdere bruggen en uiteindelijk ontstond een onoverzichtelijke, ingewikkelde wirwar.

Als er iets aan een van deze systemen gewijzigd moet worden, is totaal niet duidelijk wat de consequenties voor andere systemen zijn.
Gevolg:

• onduidelijke relatie tussen data-elementen, weergaves en rapportages 
• onvoorspelbare eindresultaten 
• torenhoge onderhoudskosten

In dit soort omgevingen wordt meer dan gemiddeld getest en veranderingen zijn intensief en hebben een lange doorlooptijd. Ondoordachte aanpassingen leiden tot grote problemen en een ontevreden interne of externe klant.

Maar zelfs als de ICT architectuur van te voren goed ontworpen is, dan zal na verloop van tijd de kwaliteit in termen van begrijpbaarheid, structuur en onderhoudbaarheid afnemen.

Inzicht in ICT Architectuur - een droom...?

Stelt u zich eens voor hoe het zou zijn als:

• u direct kan zien welke implicaties een voorgestelde wijziging heeft?
• u een concrete, haalbare planning kan afgeven aan uw klant (geen overwerk meer!)?
• uw team geen tijd kwijt is met onverwachte problemen?
• uw klant veel tevredener is met wat u aan hem levert?
• u met uw klant kunt nadenken over nieuwe functionaliteit?
• u en uw team meer plezier krijgen in het werk?

Wat zou dit voor u betekenen?

Ik heb mij dezelfde vragen gesteld als u. Mijn antwoord was:

• dat ik meer zelfvertrouwen zou hebben in mijn werk als ik wist wat een wijziging voor consequenties had.
• dat ik veel minder stress zou hebben, als ik wist dat mijn planning haalbaar was.
• dat mijn contact met mijn klant veel positiever zou worden, waardoor onze blik naar buiten zou gaan om te kijken naar de mogelijkheden.
• dat mijn team met meer plezier en inzet aan het werk zou zijn

Kortom: dat mijn plezier in mijn werk en daardoor mijn hele persoon erbij gebaad zou zijn.

Direct inzicht in ICT Architectuur is mogelijk!

Ruim 5 jaar geleden ben ik gestuit op de Dependency Structure Matrix methode. Deze methode geeft de afhankelijkheden tussen systeemonderdelen weer in de vorm van een matrix.

De methode is in de jaren zestig van de twintigste eeuw uitgedacht door Don Steward. Een heel sterk punt is dat de afhankelijkheden worden gevisualiseerd. Daardoor kan ook een relatieve leek direct inzicht verkrijgen.
Zo kan je snel antwoord krijgen op de vragen:

• Welke delen van de software zijn complex?
• Wat is de impact van een voorgestelde wijziging?
• Is de software die er nu ligt geschikt voor uitbreiding? Wat zou er moeten gebeuren om dit wel te realiseren?

Ik heb deze methode omarmd en heb inmiddels diverse bedrijven geholpen hun ICT Architectuur in kaart te brengen. In alle gevallen heeft dit geholpen om de structuur concreet in kaart te brengen en de discussie te openen binnen het ontwikkelteam.
Soms was dit voldoende; vaker nog was het de eerste stap in een migratieproject of naar nieuwe functionaliteit.

Graag laat ik u ook kennismaken met deze methode. Ik heb daarom een rapport geschreven hoe u in drie stappen op weg gaat naar een betere ICT Architectuur.
Geef nu uw naam en e-mailadres op, en vraag dit rapport direct aan.

De kracht van de Dependency Structure Matrix blijft mij keer op keer verwonderen. Hij helpt:

• om het inzicht in uw nieuwe of bestaande softwareapplicatie en ICT architectuur te vergroten 
• om uw onderhoudskosten op voorhand te verlagen en 
• om de innovatiekracht van uw applicatie te verbeteren. 

Want minder mensen aan onderhoud betekent meer mensen voor innovatie tegen dezelfde kosten! Iets wat mijn klanten kunnen beamen.