Architectuur borgen kan net zo betrouwbaar zijn als een derdehands gehoord verhaal; iedereen die wel eens 'Ik hou van Holland' kijkt (soms is de afstandsbediening niet van mij) weet hoe betrouwbaar dat is!
Op software gebaseerde oplossingen worden bij voorkeur ontwikkeld onder architectuur. Architectuur is belangrijk, voornamelijk om aan non-functional requirements te kunnen voldoen. Om vanuit een enterprise architectuur (EA) een project onder architectuur te laten uitvoeren, is een PSA (project start architectuur) nodig. Een PSA wordt geschreven door een projectarchitect. Tot zover gaat alles op rolletjes.
Maar, hoe borg je de bedachte architectuur nu eigenlijk? Een projectarchitect is prima in staat om bijvoorbeeld een functioneel ontwerp (FO) te beoordelen op architectuuraspecten. Zo’n FO wordt geschreven door een functionele consultant die begrijpt hoe de business requirements en use cases omgezet kunnen worden in functionele eisen aan een systeem. Deze consultant moet dus in ieder geval de PSA gelezen hebben om zich te houden aan de architectuurrichtlijnen. Om de architectuur te borgen in het FO, moet dit FO dus ook altijd minimaal door een projectarchitect (formeel!) goedgekeurd worden, alvorens het vervolgtraject ingezet wordt. Dit zou dus ook allemaal prima moeten werken in de praktijk.
Moeilijker
Het wordt moeilijker naarmate we verder in het project terechtkomen. Na het FO volgt een technisch ontwerp (TO). Dit TO wordt veelal door een lead developer geschreven. De lead developer leest het FO, en hopelijk ook de PSA. Een lead developer is al veel meer een ’techneut’ dan de functionele consultant, en nog veel meer dan de architect. Het kan best zijn dat de PSA door hem zodanig wordt geïnterpreteerd dat er zaken in het TO terecht komen die al niet meer helemaal voldoen aan de principes opgesteld in de PSA. Althans, volgens de interpretatie van de lead developer kan het prima kloppen. Hier begint er al iets van een probleem te ontstaan.
Eigenlijk zou de projectarchitect dus ook het TO volledig moeten kunnen beoordelen. Alleen de architect is hiervoor negen van de tien keer niet ’techneut genoeg’. Hier wordt dus soms het principe van ‘we beginnen elk vanaf een andere kant te graven en hopen dat we elkaar in het midden tegenkomen’ toegepast. Verre van ideaal.
De volgende fase in het project maakt het nog lastiger. De code wordt door een developer geschreven op basis van het TO. De code wordt vaak door een heel team geschreven, elk teamlid verantwoordelijk voor bepaalde (deel)functionaliteiten bij voorkeur in de vorm van componenten. De gemiddelde developer is prima in staat om een TO te lezen en te interpreteren, is al wat minder goed in het begrijpen van FO’s en vind architectuur maar iets voor mensen met stropdassen in ivoren torens. Vaak bevat een TO ook niet volledig in detail alle informatie die nodig is om de oplossing te creëren. Daar komt het dus aan op de creativiteit van de developer. Dat is een gevaar. Verder ontwikkelt niemand meer oplossingen volledig zelf tot op de laatste regel code, maar wordt meestal gebruik gemaakt van één of meerdere frameworks zoals bijvoorbeeld het .Net Framework. En in een service oriented architecture (SOA) maakt men vaak gebruik van al bestaande services die eventueel zelfs niet eens in het eigen datacenter draaien.
Het is dus zaak dat de lead developer de code die geschreven is door de developers controleert. Altijd! Maar wie garandeert de lead developer dat bepaalde componenten uit een framework of de services geconsumeerd in de cloud wel voldoen aan de architectuurprincipes beschreven in de PSA? Soms is die informatie niet eens publiekelijk beschikbaar. Maar toch is dat wel relevant, want wat als dat éne component nu wel die rechtstreekse verbinding met een database maakt die volgens de architectuur ‘verboden’ is?
Mensenwerk
Architectuur kan waarschijnlijk redelijk geborgd worden in de meeste projecten, als het hele projectteam zijn best doet! We kunnen in een project zowel vanaf boven (vanuit de architect, functionele consultant en lead developer) als van onderaf (vanuit de functionele consultant, lead developer en developer) architectuur borgen. Vanaf boven kunnen controles op het geproduceerde FO, TO en de code worden gedaan. Van onderaf kan er tijdens het schrijven van FO, TO en code uitgegaan worden van de interpretatie op het desbetreffende niveau van de PSA. Maar, totdat architectuur in echte ‘rules’ kunnen worden geschreven die geautomatiseerd gecontroleerd kunnen worden op alle niveaus blijft het mensenwerk en vertrouwen op een goed samenwerkend team!
Borgen doe je in mijn optiek niet door te documenteren maar door de grote lijnen goed af te stemmen op management niveau (stuurgroep/architectuurteam). Vervolgens bij de implementatie de betrokkenen goed voorzien van (hoog niveau) guidelines en daar hard op toezien. Juist door het betrekken van de ‘onderlagen’ en hen te laten nadenken over de details van de implementatie zal de borging beter zijn. Iets wat je zelf hebt bedacht is immers meer waar(d).
Dus scheppen van kaders waarbinnen men (relatief) vrij mag opereren (lees fo, to uitwerken).
Vervolgens testen tegen de originele specificaties, maar daar zijn dan weer goede testmethodes voor die op vergelijkbare uitwaaiermanier tot tests moeten leiden. Testers en ontwerpers pakken dat natuurlijk samen op :-).
Gijs leuk onderwerp en logische opbouw, alleen hou je het op deze manier wel tradtioneel. Hier is wat ik denk:
Ten eerste: Zorg dat de architect bij het project betrokken blijft. Als is het maar een dag per week. Papier en plaatjes zijn in mijn ogen zelfs ondergeschikt aan de toelichting van de architect in levende lijve. Ook een architect kan zijn mening aanpassen op basis van feedback of foutjes herstellen die in het ontwerp geslopen zijn of die door een lead developer verkeerd begrepen of geïnterpreteerd worden. Kennis delen, kennis delen, kennis delen. Ook ben ik er een groot voorstander van dat de architect het papier niet aanraakt. Laat iemand anders het vastleggen, dan heb je al een eerste check of de boodschap begrepen wordt.
Een tweede ding is dat ik fan ben van een losjes gebruik van Domain Driven Design (DDD). DDD beschrijft het domein van de oplossing in een taal die iedereen begrijpt en dus geen IT vakjargon bevat, DDD dekt welliswaar niet de hele lading, je kunt het niet goed toepassen om een technische architectuur aan te duiden, maar deze is dan ook ondergeschikt. Belangrijkste is dat de architectuur begrepen wordt, ook door de niet IT mensen, in ieder geval als het gaat om een software product.
Om antwoord te geven op je vraag dien je eigenlijk een tegenvraag te stellen: waarom wordt er van de architectuur afgeweken?
Hierop zijn legio antwoorden mogelijk. Enkele veel gehoorde antwoorden:
– de architectuur is achterhaald
– met deze architectuur kan ik niet werken
– als ik de implementatie volgens de architectuur moet doen kost het me 4 weken, en als ik het op mijn manier doe is het in 2 dagen klaar
– voordat de architect eens een keertje tijd heeft om hiernaar te kijken is het project al afgelopen
– die architectuur is veel te conceptueel en abstract, daar kan ik niet mee uit de voeten
Enkele oorzaken die ik in de loop der jaren tegen gekomen ben:
– de architect komt van buiten, en zal wel eens even vertellen hoe e.e.a. moet werken (conceptueel uiteraard). Nadeel is dat dit type architect nooit met het product zelf te maken heeft gehad en het gebruik maar ten dele kent. Hierdoor kan hij de consequenties van zijn conteptuele keuzes maar voor een beperkt deel overzien.
– de architect staat te ver van de uitvoering af. Met name in het voorbeeld uit het artikel zie je dat mooi terug. De architectuur moet zoveel lagen door, waardoor je welhaast vervorming moet krijgen. Om een ander voorbeeld uit “ik hou van Holland” te noemen (ook ik moet de afstandbediening delen): daarin zit zo’n spel dat ze elkaar een verhaal door moeten vertellen. Na 5 personen is het verhaal behoorlijk vervormd. Dit zelfde zie je als de architectuur-regels teveel lagen door moet, waardoor vervorming van interpretatie ontstaat.
– de projectmanager heeft meer te vertellen dan de architect. Zeker aan het einde van een project wil de projectmanager dat het project opgeleverd, architectuur of geen architectuur.
Een kant en klaar oplossing is er niet voorhanden. Wat mijns inziens wel belangrijk is dat de architect voeling krijgt/houdt met de uitvoering. Laat de architect zelf meedraaien in de praktijk (bijvoorbeeld de installatie van een systeem, meedraaien/kijken bij acceptatietest) maar ook door de architect zelf zijn ideeën uit te laten leggen aan te ontwikkelaars. Hiermee kan enerzijds getoets worden of zijn plannen en concepten begrepen worden door degene die het uiteindelijk moeten implementeren. Anderzijds leren de diverse partijen elkaar zo ook kennen, en worden de drempels verlaagd om contact met de architect op te nemen in geval van twijfel of onduidelijkheid.
Of snelheid boven architectuur gaat is een lastige. Dit is vaak korte termijn versus lange termijn denken.
Een korte termijn oplossing mag misschien afwijken, maar met name bij producten met een lange levenscyclus kan dit je later lelijk opbreken. Als je af wil wijken, moet er geborgd worden dat er nadien nog een architectuur-technisch correcte oplossing wordt geïmplementeerd. In praktijk komt dit er meestal niet van. Het project zelf loopt ten einde, en het vervolgproject had niet ingecalculeerd om de rotzooi van zijn voorganger op te ruimen……
@LRoovers, @Henri Koppen: helemaal eens dat de architect betrokken moet blijven.
@Henri Koppen: je zegt dat technische architectuur ondergeschikt is, maar daar ben ik het niet helemaal mee eens. Vaak wordt een systeem opgeleverd dat niet presteert, niet schaalbaar is en niet “supportable” is omdat de technische architectuur niet goed was of er is niet goed aan voldaan. DDD is zinvol voor business architectuur.
@PaVaKe: Ik bedoelde precies dat spelletje in Linda’s zaterdagavondfestijn. En verder, inderdaad moet de architect betrokken blijven. Ook in een Agile (“snelle”) omgeving.
Bevindingen tot zo ver: Architect moet betrokken blijven en pragmatisch zijn?
Gijs,
Na je reactie over ‘agile’ moest ik even glimlachen maar ook de punten in reactie van PaVaKe zijn herkenbaar. En aangaande je opmerking over pragmatische architectuur stel ik voor dat je van de FOTO (funtioneel en technisch ontwerp) een FILM maakt, dus geen ART op basis van artifacten maar bewegende beelden vanuit de praktijk wat dus betekent dat architecten niet vanuit hun ivoren toren moeten werken. Want is gebrek aan borging vaak niet gewoon het gevolg van het ‘over de muur gooien’ van onmogelijke wensen en eisen?
Een goede architect heeft helemaal geen tijd om TV te kijken.
PaVaKe heeft een punt. Het borgen van architectuur heeft te maken met acceptatie door de mensen die er mee moeten (mogen?) werken. En net als alle andere dingen die mensen niet zelf hebben verzonnen zijn er altijd mensen die daar moeite mee hebben, weerstand tegen tonen of het gewoon niet begrijpen.
Je kunt dan documenteren wat je wilt, maar daarmee win je de oorlog niet. Er is een groot verschil tussen vastleggen (papier is geduldig) en borgen.
Hoe je mensen en hun gedrag kunt begrijpen heeft om te beginnen te maken met heel algemene vaardigheden: luisteren, communiceren, menselijke en organisatorische empathie opbrengen etc.
Begrijpen is volgens mij de eerste stap voor acceptatie. Er zijn meer dan voldoende hulpmiddeltjes om dat handen en voeten te geven. Om er een paar te noemen (in willekeurige volgorde):
• De rouwverwerkingscurve van Kubler Ross
• Kernkwadranten
• De 8 stappen voor succesvol veranderen van John Kotter
• Gesprekstechnieken zoals chunken, “LSD” etc.
Uiteindelijk komt het er op neer dat de architect de helft van zijn doel bereikt als hij (zelf) de “What’s in it for Me” vraag weet te beantwoorden.
Aanvulling op de laatste regel hierboven: met “zelf” beantwoorden bedoel ik “de moeite nemen om aan alle stakeholders uit te leggen wat architectuur hun oplevert”.
Dus niet: het (voor zich)zelf beantwoorden wat architectuur hem (de architect) oplevert.
Gijs leuk dat je feedback geeft maar met je samenvatting van o.a. mijn reactie met “betrokken blijven en pragmatisch zijn” ga je veel tekort dooe de bocht.
Ik zeg niet dat technische architectuur niet belangrijk is, maar dat het in invulling moet geven aan de strategie. Techniek is meestal tactisch van aard. Net als dat een IT afdeling een afgeleide is van de business en de IT dus niet sturend zou moeten zijn en dus ondergeschikt aan de bedrijfsstrategie.
Daarnaast zie ik het in verlengde van PaVaKe’s mooie reactie dus van cruciaal belang dat de architect niet losstaat van de rest van het bedrijf. Het (huidige) bedrijf is *altijd* een belangrijk facet van de nieuwe architectuur. Net als dat een architect ook altijd bewust moet zijn van de technische trackrecord van een organisatie. Maar de crux zit hem dat zijn strategie erkend en gevalideerd wordt en dat kan alleen als deze gedeeld en begrepen wordt. Dat laatste is belangrijker dan de rest.
Betrokken en pragmatisch is daarvan slechts een eigenschap en dus niet de kern van wat ik bedoel.
Als ik dit alles zo lees krijg ik een plaatje in mijn hoofd waar de berijder een paard tot bewegen verleid door een wortel aan een hengel voor te houden. En omdat paard, berijder en wortel alle 3 bewegen krijgt het paard natuurlijk nooit de wortel te pakken. Ik bedoel hiermee dat het probleem volgens mij vooral zit in alle bewegende delen zoals steeds wijzigende techniek, organisatorische veranderingen en aanpassingen op de markt. Architecten in de IT ontwerpen namelijk geen onroerend goed zoals we zien met de ontwikkelingen rond BYOD, Cloud Computing, Sociale Media enzovoort.
@Henri, @Ewout architecten scheppen en bewaken de kaders. Dit geldt voor Business, Informatie en Technische architectuur. Een goed architectuur levert de business de “agility” die ze nodig hebben. Met de onder architectuur ontstane funderingen en oplossingen kan dan snel op veranderende business wensen en eisen worden ingesprongen. Het feit dat de onderliggende techniek vaak aan verandering onderhevig is (denk aan nieuwe frameworks en ontwikkeltalen, SaaS, PaaS, Big Data, etc.) is inderdaad 1 van de vele uitdagingen waar een architect mee te maken heeft. Vandaar dat het vaak verzandt in vaagheden die moeilijk te controleren en af te dwingen zijn. Ik heb bij menig grote organisatie (denk aan o.a. Shell) meegemaakt dat de architecten het onderling niet eens eens konden worden omdat er te veel stakeholders bij betrokken zijn met verschillende wensen en eisen. Om dan een goede fundering te ontwikkelen (en betaald te krijgen) is erg lastig. Het eindresultaat is dan vaak niet goed te keuren omdat de architectuur te vaag was en de business niet blij met het resultaat. Dus, architectuur mag nooit vaag zijn en moet te borgen blijven. Echt een sluitende aanpak is daar niet voor beschikbaar. Dat is de strekking van mijn opinie. Een (soms grote) uitdaging op mijn projecten en als ik het zo zie aan de reacties ook bij vele anderen.