Hoe borg je nu eigenlijk architectuur?

18-01-2013 15:22 | Door Gijs in ‘t Veld | Er zijn 18 reacties op dit artikel | Permalink
Computable Expert
Gijs in ‘t Veld
Gijs in ‘t Veld

CTO bij Motion10

Expert van Computable voor de topics: Architectuur, Cloud Computing en BPM

Meer

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!
Reacties op dit artikel
De redactie vindt deze reactie: OKlroovers, 18-01-2013 15:45
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 :-).
De redactie vindt deze reactie: OKHenri Koppen, 18-01-2013 20:50
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.
 
De redactie vindt deze reactie: OKPaVaKe, 19-01-2013 15:41
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......
 

De redactie vindt deze reactie: OKGijs in t Veld, 19-01-2013 16:30
@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?
De redactie vindt deze reactie: OKEwout Dekkinga, 19-01-2013 22:39
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?
De redactie vindt deze reactie: OKMichiel Croon, 20-01-2013 1:00
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.
De redactie vindt deze reactie: OKMichiel Croon, 20-01-2013 1:55
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.
De redactie vindt deze reactie: OKHenri Koppen, 20-01-2013 12:31
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.
De redactie vindt deze reactie: OKEwout Dekkinga, 20-01-2013 13:54
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.
De redactie vindt deze reactie: OKGijs in t Veld, 20-01-2013 14:09
@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.
De redactie vindt deze reactie: OKEwout Dekkinga, 20-01-2013 14:52
Gijs,
 
Je betoog is duidelijk, de richting om het op te lossen alleen nog niet helemaal. Heb hier - en dan met name de rol van EA - al eens wat over geschreven:
 
http://www.xr-magazine.nl/blogs/1418/architectuurraamwerken/loopt-enterprise-architectuur-straks-op-de-rotsen
De redactie vindt deze reactie: OKGijs in t Veld, 20-01-2013 15:11
@Ewout Leuk stuk en ook een heel leuk plaatje van Zapthink. Maar ook geen sluitende antwoorden nog dus...
De redactie vindt deze reactie: OKRuud Mulder, 20-01-2013 16:34
Leuk artikel Gijs. Ik ben het niet overal met je eens, maar je artikel levert wel een mooie discussie op.
 
Ik kijk al uit naar deel II. Want ik denk dat je al een nieuwe opinie artikel kan maken op basis van alle reacties.
De redactie vindt deze reactie: OKEwout Dekkinga, 20-01-2013 22:22
Gijs,
 
Meeste architectuur raamwerken zijn rechthoekig en zoals je kon zien zijn de problemen in het plaatje van Zapthink rond. Dat wordt dus nog een heleboel slijpen, schaven en schuren;-)
De redactie vindt deze reactie: OKSjoerd, 21-01-2013 9:34
@Pavake
Ooit eens meegemaakt dat een architect ook de eigenlijke (praktische) projectmanager was en dat gaf het project toch wel een heel andere dimensie. Was voor de arme man toch wel redelijk aanpoten maar een interessant voorbeeld wanneer een architect ook betrokken wordt bij het bouwen wat hij bedacht heeft.
De redactie vindt deze reactie: OKRuud Mulder, 22-01-2013 10:44
@ Sjoerd,
 
Dat is alleen maar prettig. Ik doe dat zo nu en dan zelf ook nog steeds. Zo blijf je als architect-zijnde bij van waar de andere kant mogelijk tegen aanloopt.
 
En vice-versa is natuurlijk ook zeer handig. Zo wordt er meer wederzijds begrip voor elkaars rol gecreëerd. En dit komt de kwaliteit alleen maar ten goede.
De redactie vindt deze reactie: OKRuud Pieterse, 22-01-2013 17:21
TOGAF heeft genoeg methodes and definities om aan borging te doen. De vraag is hoe zoiets up to date te houden. Immers initieel plaatsen is 1 ding, het up to date houden vereist discipline.
De redactie vindt deze reactie: OKGijs in t Veld, 23-01-2013 16:38
Hedenmorgen bij een opdrachtgever weer een mooi staaltje van wildgroei aan knutseloplossingen meegemaakt. Met een betrokken architect en het juiste team mandaat had dit voorkomen kunnen worden. Nu moeten veel van deze oplossingen opnieuw gebouwd worden, omdat ze simpelweg op deze manier niet mee kunnen in de geplande migratie naar een 3rd party hosting provider.
Gerelateerde artikelen

26-04-13  ‘Rol ICT-architect verandert volledig’

6 vacatures
IT Projectmanager

MN , 's-Gravenhage

Ervaren sharepoint architect

De Nederlandsche Bank , Amsterdam

Senior ketenbeheerder MijnOverheid

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Logius , 's-Gravenhage

Medior applicatieontwikkelaar .NET

Belastingdienst , Apeldoorn

Grafisch Designer

Itility B.V. , Son

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1572 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1271 6.2
Klik voor meer info4 1072 6.2
Klik voor meer info5 993 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 524 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 399 6.0