Hoe borg je nu eigenlijk architectuur?
CTO bij Motion10
Expert van Computable voor de topics: Architectuur, Cloud Computing en BPM
MeerArchitectuur 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!
Henri Koppen, 18-01-2013 20:50
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.
PaVaKe, 19-01-2013 15:41
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......
Gijs in t Veld, 19-01-2013 16:30
@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?
Ewout Dekkinga, 19-01-2013 22:39
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?
Michiel Croon, 20-01-2013 1:00
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.
Michiel Croon, 20-01-2013 1:55
Dus niet: het (voor zich)zelf beantwoorden wat architectuur hem (de architect) oplevert.
Henri Koppen, 20-01-2013 12:31
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.
Ewout Dekkinga, 20-01-2013 13:54
Gijs in t Veld, 20-01-2013 14:09
Ewout Dekkinga, 20-01-2013 14:52
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
Gijs in t Veld, 20-01-2013 15:11
Ruud Mulder, 20-01-2013 16:34
Ik kijk al uit naar deel II. Want ik denk dat je al een nieuwe opinie artikel kan maken op basis van alle reacties.
Ewout Dekkinga, 20-01-2013 22:22
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;-)
Sjoerd, 21-01-2013 9:34
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.
Ruud Mulder, 22-01-2013 10:44
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.
Ruud Pieterse, 22-01-2013 17:21
Gijs in t Veld, 23-01-2013 16:38
24-05 Profiteer van virtualisatie in hybride omgeving
24-05 Laat je niet overvallen door BYOD
24-05 Cloudintegratie is een ware uitdaging
23-05 Van 3D-film naar 3D-document
23-05 Gevaren van silostorage kun je ondervangen met SSD
22-05 Documenten dubbel zien in de cloud
22-05 Denk in diensten en niet in uren maal tarief
21-05 Beveilig je site tegen DDoS-aanval
21-05 Maak je proces mobiel met een app
17-05 De Red Diesel Blues
22-05 Wacom Cintiq 22HD nu met touch-bediening
13-05 Oracle krijgt strategische rol bij Rabobank
07-05 USoft geeft URequire Studio 3.0 vrij
02-05 Brocade komt met VCS Fabric-plug-in
26-04 ‘Rol ICT-architect verandert volledig’
25-04 Hoe perfectioneer ik het digitale systeem?
25-04 Progress Apama CEP bereikt hogere snelheden
24-04 Info Support biedt IT-minors via HBO's aan
22-04 Fugro en Geodan presenteren VISOR
18-04 Dell laat datacenters groeien met SDN-Enabled...
|
|
Tien stappen naar 3D security
 |
Benieuwd naar het succesrecept voor een zorgeloze en waterdichte security-omgeving? Installeer een......
Star-MDC , Rotterdam
a.s.r. , Utrecht
Michael Page IT , Heerlen
Kempen & Co N.V. , Amsterdam
's Heeren Loo , Amersfoort
| Aantal reacties met 3+ sterren | Gemiddelde waardering | |||
 | 1 | 752 | 6.1 | |
 | 2 | 658 | 6.3 | |
 | 3 | 621 | 6.4 | |
 | 4 | 589 | 6.3 | |
 | 5 | 537 | 6.3 | |
 | 6 | 525 | 6.2 | |
 | 7 | 280 | 6.2 | |
 | 8 | 236 | 6.2 | |
 | 9 | 157 | 6.1 | |
 | 10 | 123 | 6.0 | |
Alle rechten voorbehouden © 1995-2013 De Persgroep
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 :-).