Architect voorkomt luchtfietserij

Architect voorkomt luchtfietserij
Een enterprise-architectuur vergroot de kans dat een IT-project slaagt. Maar de architect is allesbepalend, hij voorkomt luchtfietserij.
Vijf kritische succesfactoren waarmee de architect te maken heeft, plus enkele praktijkcases.
Hidde Andriessen en Johan Noltes
De jaarlijkse kosten voor het mislukken van IT-projecten wordt wereldwijd geschat op 2500 miljard euro. Uit onderzoek blijkt wat de belangrijkste oorzaken zijn voor het mislukken van IT-projecten: slechte planning, onduidelijke requirements en niet voldoen aan de verwachtingen. Enterprise-architectuur helpt om projecten te behoeden voor foutieve en ineffectieve keuzes door het analyseren van de requirements in een bedrijfsbrede context en het bewaken van de resultaten en verwachtingen. Toch mislukken ook IT-projecten die een enterprise-architectuur hebben. Op basis van onze praktijkervaring zien wij vijf kritische succesfactoren die een architect minimaal moet toepassen bij zijn architectuurkeuzes om IT-projecten te laten slagen. Ook bespreken we welke cruciale rol de architect hierbij speelt.
Kenmerkende verschillen
We zien een verschil tussen hoe grote organisaties en kleinere organisaties omgaan met architectuurkeuzes. Veel grote organisaties hebben een formele architectuurfunctie ingericht. De valkuil bij een formele architectuurfunctie is dat de kritische succesfactoren (KSF) ergens in een proces geborgd zijn, maar onvoldoende effect hebben. Er wordt veel geanalyseerd in modellen en technische details, maar te weinig aandacht besteed aan het begrijpelijk en inzichtelijk maken van de consequenties voor het management (KSF4). Als de beslissers de consequenties niet goed kunnen meenemen in hun overweging, is het effect van de analyse nul. In kleinere organisaties is er minder vaak sprake van een architectuurfunctie en zien we dat er weinig besef is van wat er bij een architectuurkeuze allemaal komt kijken.
Het gevaar hier is dat snel gekeken wordt naar mogelijke oplossingen en vergeten wordt om te kijken of de eisen wel volledig (KSF1) en concreet (KSF2) genoeg zijn. Zo was bij een verzekeraar een eis niet concreter dan dat het nieuwe administratiesysteem ‘flexibel’ moest zijn. Pas nadat het systeem in productie was genomen, werd duidelijk dat een nieuw verzekeringsproduct net zo makkelijk toegevoegd moest kunnen worden als een nieuwe klant, dus zonder aanpassingen van de software. Het zijn zulke eisen die grote impact hebben op de architectuur en de kosten van een systeem, en die dus bepalend zijn voor het succes van het project.
Architect maakt het verschil
Los van een geformaliseerde architectuurfunctie of de grootte van de organisatie bepaalt de architect hoe effectief de architectuurkeuzes zijn. De architect maakt het verschil. Het is de architect die de opdrachtgever en stakeholders moet aansporen om eisen concreet (KSF2) te maken en
hen moet helpen om alle kwaliteitseisen (KSF1) helder te krijgen. De architect speelt een faciliterende maar cruciale rol. De architect moet bijvoorbeeld laten zien welke kwaliteitseisen elkaar beïnvloeden. Zo hebben beveiligingseisen over het algemeen negatief effect op gebruikersvriendelijkheid en hebben performance-eisen mogelijk een negatieve invloed op onderhoudbaarheid. Op basis van de eisen bepaalt de architect de oplossingsrichting van zijn architectuurkeuze. De volgende succesfactor is of de oplossingsrichting geschikt is binnen de bedrijfscontext (KSF3).
Hiervoor moet de architect zijn analytische skills laten zien. De architect beschikt over de kennis en kunde om de samenhang tussen de bedrijfsprocessen, bedrijfsfuncties, informatiebehoefte en technologie te bewaken en kijkt of de oplossingsrichting daarbinnen voldoende toekomstvast is. Voor deze analyse moet de architect modellen en principes toepassen. Vanuit dit architectuurperspectief zullen dan ook kaders worden bepaald waar de oplossing aan moet voldoen.
Vanuit analyse van de bedrijfscontext volgt ook het inzichtelijk maken van de consequenties (KSF4) van de architectuurkeuze. Hier hoort wederom de nodige analyse bij, maar belangrijker is de manier waarop de architect deze consequenties weet over te brengen bij de opdrachtgever en stakeholders. Dit kunnen risico’s, benodigde organisatorische veranderingen, beperkingen of juist mogelijkheden zijn. Het zijn zijn com
municatieve skills die ervoor moet zorgen dat complexe materie teruggebracht wordt tot de essentie, afgestemd op zijn publiek.
Tot slot dient de haalbaarheid (KSF5) van de architectuurkeuze getoetst te worden om luchtfietserij te voorkomen. De keuze moet beoordeeld worden door de verschillende stakeholders en de architect moet hierbij zelf concreet worden over hoe de architectuurkeuze in de praktijk moet werken. Voor risicovolle keuzes kan eerst een prototype of pilot gedaan worden.
Dat we de kritische succesfactoren stapsgewijs hebben besproken, betekent niet dat ze ook volgordelijke doorlopen moeten worden. In de praktijk is te verwachten dat alles gelijktijdig aan bod komt. Het gaat erom dat op het moment dat de keuze daadwerkelijk genomen moet worden alle succesfactoren aanwezig zijn. De skills die nodig zijn om dat voor elkaar te krijgen, laten zien dat architectuur echt een vak is, dat architectuur vraagt om vakmanschap.
 
KADERR: Vijf kritische succesfactoren (KSF)
KSF1 - Volledigheid van eisen.Kwaliteitseisen zijn het meest bepalend voor een oplossingsrichting, daarom is het essentieel om naast de functionele eisen ook de gewenste mate van onder andere onderhoudbaarheid en betrouwbaarheid in kaart te brengen.
KSF2 - Concreetheid van eisen. Eisen mogen niet voor meerdere uitleg vatbaar zijn. Het is hierbij belangrijk dat business- en IT-vertegenwoordigers elkaar goed begrijpen.
KSF3 - Geschiktheid binnen de bedrijfscontext. De eisen en oplossingsrichting moeten passen binnen het type organisatie, klanten en bedrijfsprocessen, aansluiten bij de bedrijfsstrategie en binnen deze context toekomstvast zijn.
KSF4 - Inzichtelijkheid van de consequenties. De consequenties die de voorgestelde architectuurkeuze met zich meebrengt, moeten inzichtelijk en begrijpbaar zijn gemaakt zodat de opdrachtgever en andere relevante stakeholders geïnformeerde beslissingen kunnen nemen.
KSF5 - Haalbaarheid. De voorgestelde oplossing moet realistisch zijn binnen de beschikbare middelen, tijdlijnen en skills. Dit kan getoetst worden door relevante stakeholders de voorgestelde oplossing te laten beoordelen. Indien nodig wordt voor een definitief besluit een prototype of pilot uitgevoerd om de oplossing in de praktijk te toetsen.
 
Vier praktijkcases
SaaS-leverancier
 
Businesscontext: Een SaaS-leverancier overweegt een grondige vernieuwing van de applicatie-architectuur van zijn product om te kunnen voldoen aan de groeidoelstellingen.

IT-context: Het ontwikkelteam overweegt een CQRS-architectuur om te kunnen voldoen aan de schaalbaarheidseisen voor deze groeidoelstelling. Een CQRS-architectuur is geschikt voor schaalbaarheid wanneer data met zeer veel gebruikers gedeeld worden, maar is tegelijkertijd een veel complexere architectuur en heeft specifieke consequenties voor de gebruikerservaring.

Analyse van de kritische succesfactoren: Vastgesteld werd dat er nog onvoldoende duidelijkheid was over de precieze schaalbaarheidseis (KSF2) en dat nog helemaal niet nagedacht was over andere kwaliteitseisen (KSF1). Daarbij was de bedrijfscontext niet in kaart gebracht (KSF3). Uit de bedrijfscontext bleek dat voor het type klant binnen deze branche data eigenlijk maar heel beperkt worden gedeeld tussen gebruikers en al helemaal niet tussen verschillende klanten. De schaalbaarheidsbehoefte zat veel meer in het snel kunnen toevoegen van nieuwe klanten en het kunnen opschalen van reken- en opslagcapaciteit. CQRS was in dit geval dan ook ongeschikt.

KSF1 Volledigheid – –
KSF2 Concreetheid –
KSF3 Geschiktheid – –
KSF4 Inzichtelijkheid 0
KSF5 Haalbaarheid + +

 
Overheid
 
Businesscontext: Een groot programma is opgezet voor het realiseren van een portaal- en contentmanagementoplossing. Er zijn veel leveranciers betrokken en meerdere architecten zijn betrokken om de architectuur te bewaken.
 
IT-context: Bij inbeheername blijkt de oplossing instabiel. Onderzoek leert dat architectuurbewaking ineffectief is geweest en dat een te complexe oplossing is ontstaan met workarounds en onnodig veel maatwerk.
 
Analyse van de kritische succesfactoren: De architecten hebben architectuurdeliverables opgesteld volgens het boekje. Eisen en principes worden in kaart gebracht (KSF1) (KSF2). Maar leveranciers hebben te veel vrijheid gekregen om deeloplossingen te bepalen. De architecten waren hier onvoldoende bij betrokken en hebben consequenties ervan (KSF4) niet overzien en inzichtelijk gemaakt voor de programmaleiding.
 
KSF1 Volledigheid + +
KSF2 Concreetheid +
KSF3 Geschiktheid 0
KSF4 Inzichtelijkheid – –
KSF5 Haalbaarheid 0
 
Retailer
 
Businesscontext: De holding van een retailer met verschillende autonome werkmaatschappijen heeft als strategisch uitgangspunt om waar mogelijk systemen te standaardiseren en centraal te hosten. Eén planningsysteem voor alle werkmaatschappijen wordt overwogen.
 
IT-context: De systeemleverancier stelt dat verschillende instanties van het systeem naast elkaar gehost kunnen worden, maar de centrale IT-afdeling stelt vast dat binnen één instantie van het systeem niet meerdere werkmaatschappijen kunnen werken.
 
Analyse van de kritische succesfactoren: Beide statements zijn waar, maar zinloos zolang niet de eis over het centraal hosten van het systeem verder wordt geconcretiseerd (KSF2). Pas dan kan in combinatie met andere kwaliteitseisen (KSF1) gekeken worden naar de geschiktheid van deze oplossing voor deze holdingstructuur (KSF3). De retailer was er in dit geval op tijd bij om deze stappen uit te voeren voordat een keuze werd gemaakt.
 
KSF1 Volledigheid +
KSF2 Concreetheid – –
KSF3 Geschiktheid – –
KSF4 Inzichtelijkheid 0
KSF5 Haalbaarheid 0
 
Verzekeraar
 
Businesscontext: Een verzekeraar is ontevreden over de snelheid waarmee wijzigingen in het zelfontwikkelde frontofficesysteem gerealiseerd worden. Bij de ontwikkeling van het frontofficesysteem was juist voor een Service Oriented Architecture (SOA) gekozen om sneller wijzigingen te kunnen realiseren.
 
IT-context: Na onderzoek blijkt dat de IT-afdeling deze eis heeft ingevuld door in de SOA gemakkelijk nieuwe frontends te kunnen toevoegen (multi-channeling) en om business rules voor de acceptatie van nieuwe aanvragen op één plek te kunnen onderhouden. De business ontwikkelt echter om de paar maanden nieuwe producten die in het frontofficesysteem opgenomen moeten worden.
 
Analyse van de kritische succesfactoren: Door de gekozen invulling van SOA leidt elk nieuw product tot wijzigingen op veel plekken in het systeem. Dit maakt de toevoeging van producten juist complex en tijdrovend. Het blijkt dat de bedrijfscontext (KSF3) voor deze kwaliteitseis (flexibiliteit) onvoldoende duidelijk (KSF2) was om deze technologiekeuze (SOA) te maken. Ook zijn de consequenties (KSF4) onvoldoende inzichtelijk gemaakt, anders was de mismatch al eerder aan het licht gekomen.
 
KSF1 Volledigheid +
KSF2 Concreetheid – –
KSF3 Geschiktheid – –
KSF4 Inzichtelijkheid – –
KSF5 Haalbaarheid 0
 
Hidde Andriessen is adviseur bij KPMG op het gebied van Architectuur. E-mail: andriessen.hidde@kpmg.nl
 
Johan Noltes is adviseur bij KPMG op het gebied van Architectuur. E-mail: noltes.johan@kpmg.nl

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag