Lean en architectuur

Recent hadden we een kennisavond waarin Lean en architectuur centraal stond. Deze blog beschrijft onze bevindingen van de brainstorm en discussie. De combinatie Lean en architectuur is volgens ons een interessante, want hoe vaak hoor je niet dat (enterprise) architectuur (te) veel tijd en geld kost en onvoldoende oplevert. De vraag die tijdens de avond centraal stond was dan ook, kan de waarde van architectuur, ofwel de waarde van het architectuurproces, vergroot kan worden middels het toepassen van Lean principes? Nu kun je op verschillende manieren architectuur en Lean combineren, elk met compleet andere resultaten. Uit drie verschillende manieren hebben we de best passende op het vraagstuk gekozen.

Eén manier om het vraagstuk te benaderen is te kijken naar hoe architectuur past in een agile/scrum ontwikkelomgeving. Deze benadering wordt vaak agile architectuur genoemd en kijkt met name hoe software-architectuur gecombineerd kan worden met software development in agile/scrum teams. Alleen, hoe andere vormen van architectuur, zoals enterprise-, bedrijfs-, informatie-, technische architectuur, passen binnen agile architectuur tref ik in de literatuur niet aan.

Een tweede manier om het vraagstuk te benaderen is kijken hoe de bedrijfsprocessen in een organisatie zijn in te richten op basis van Lean principes. Bij deze benadering staan de architectuurproducten en -processen geheel buiten schot als het gaat om de waarde van architectuur te vergroten middels toepassen van Lean principes.

De derde, en in deze blog laatste, manier om het vraagstuk te benaderen is te kijken hoe het architectuurproces is in te richten op basis van Lean principes. Deze benadering is in de kennisavond verder uitgewerkt door bij elk Lean principe te bedenken en bediscussieren hoe waarde van het architectuurproces vergroot kan worden door het toepassen van de principes.

Vijf principes van Lean

Als we het gaan hebben over de principes van Lean is het netjes om ze ook even te noemen. Er zijn volgens de literatuur vijf principes van Lean. Deze zijn:

1. Waardecreatie voor de klant: doe alleen dat wat van waarde is voor je klant.
2. Reduceer verspillingen, identificeren van de waardestroom: breng alle activiteiten binnen een organisatie in kaart, van klantvraag tot levering. Bepaal vervolgens voor elke activiteit of ze waarde toevoegt voor de klant.
3. Creëren van flow: zet alle stappen die waarde toevoegen achter elkaar.
4. Pull gebaseerd op de vraag: zet het proces pas in gang wanneer er een klantvraag is.
5. Constante verbetering, perfectie: door constant alert te blijven op verbeteringen ontdek je nieuwe mogelijkheden voor een efficiënt proces.

Per principe wordt hierna beschreven op welke manieren waarde volgens ons kan worden toegevoegd aan het architectuurproces.

Waardecreatie voor de klant

Voordat de stelling “doe alleen dat wat van waarde is voor je klant” beantwoord kan worden dien je je af te vragen wie de klant of de consument is van het architectuurproduct. Is het de aandeelhouder, de opdrachtgever, de directie, de gebruiker van een softwaresysteem, de ontwikkelafdeling, de lead architect, CIO-office, et cetera?

Volgens ons zijn er twee groepen klanten te onderkennen, afhankelijk van de positie waarin de architect zich bevindt in de organisatie, namelijk bevindt de architect zich in de projectorganisatie of in de staande organisatie. In geval sprake is van een software ontwikkelproject denken wij dat de consument doorgaans het ontwikkelteam is. De architectuurproducten die waarde toevoegen zijn doorgaans een gedetailleerd solution architectuur, een logisch ontwerp en architectuurkaders voor het ontwikkelteam en de implementatie van de software in de staande organisatie. In de staande organisatie is volgens ons de bestuurder van de organisatie de consument. De architectuurproducten die waarde toevoegen zijn doorgaans hulpmiddelen om te kunnen sturen. Waarborg ervoor dat de ontwikkeling in lijn is met visie, strategie en doelstellingen.

In de afbeelding is een model weergegeven van de elementen die van invloed zijn op de keuzes van de klant.

Het mag duidelijk zijn dat de architectuurproducten voor de ene klantgroep niet of nauwelijks geschikt zijn, en dus van geen waarde zijn, voor de andere klantgroep.

Vanuit de praktijk was een van onze bevindingen dat architecten de neiging hebben te veel te doen. Bijvoorbeeld er worden geregeld veel lijvige documenten geproduceerd, terwijl een korte afstemming met de klant dikwijls genoeg is. Bekend zijn de voorbeelden van de PSA die tot in groot detail de oplossing beschrijft en die alleen tot doel heeft geaccordeerd te worden door het CIO-office. Of van het over de 100 pagina’s tellende architectuurdocument dat door niemand (klant/consument) gelezen en/of begrepen wordt. Leuke anekdote over een PSA bij een overheid waarin als voorwoord staat vermeld “Met trots presenteren wij dit, over de 100 pagina’s tellende, PSA waarin… Het architectuurteam”. Een goede visualisatie helpt soms meer dan dikke documenten. De waarde zit ‘m in de vastgelegde communicatie over de architectuur.

Reduceer verspilling en identificeer de waardestroom

Binnen Lean worden er diverse soorten verspilling gedefinieerd. Verspillingen zijn werkzaamheden die geen waarde toevoegen voor de klant en vermijdbaar zijn. Voorbeelden zijn: onnodig transport voorraad, onnodige beweging, overbewerking, overproductie, onvolledig gebruik van talent en tijd van medewerkers, wachten, correctie en herstel.

Een van de aangedragen redenen waarom een architectuurdocument vaak te groot is ligt in het feit dat te rigide een template wordt gevolgd en ingevuld. Dus ook de paragrafen die niet relevant blijken voor het onderhanden project of de paragrafen waarvan niemand (meer) weet waarom ze ook alweer bedoelt waren. Aan de andere kant is een template wel weer een goede vorm van hergebruik en standaardisatie. Andere vormen van goed hergebruik zijn industriestandaarden, referentie-architecturen, raamwerken en bouwblokken. Het gebruik van een repository kan helpen om verspilling tegen te gaan. Te veel is natuurlijk nooit goed. Is het gedetailleerd vastleggen van het complete enterprise architectuur in een repository van toegevoegde waarde? En voor wie dan? Of is hier sprake van onvermijdbare activiteiten?

Wat we als verspilling van tijd en geld aanduiden is het gedetailleerd uitwerken van diverse scenario’s ten behoeve van het maken van keuzes. Het management wil dikwijls kunnen kiezen uit alternatieven, en dat is goed, maar in welke mate is het zinvol (geen verspilling) deze tot in groot detail uit te werken? Temeer als vooraf al een besluit is genomen voor een bepaald scenario.

Ook de aard van de architect is in sommige gevallen oorzaak van verspilling. Architecten geven vaak prioriteit aan de interactie met stakeholders in plaats van aan de administratie van de architectuur met als gevolg te veel architectuur(blabla) met te weinig effect.

Het komt er in onze optiek op neer dat je bij architectuurproducten goed moet nadenken voor wie je ze maakt en met welk doel. In het politieke aspect van het architectuurwerk lijken Lean-principes minder te gelden. De waarde zit dan in het eindresultaat en minder in een efficiënt architectuurproces.

Creër flow

De hamvraag hierbij is “bereiken de architectuurproducten de klant?” Met andere woorden, loopt het proces door of stagneert het en blijft er vanalles “hangen” in een 0.9.x versie? Zorg ervoor dat de architectuurproducten de klant (consument) bereiken. Richt hiertoe desnoods een formeel goedkeuringsproces in, waarbij in elk geval ook de klant haar goedkeuring of afkeuring ventileert. Er zijn voorbeelden genoeg te vinden waarbij formele accorderingsgremia in het leven zijn geroepen, maar waar de klant niet in is vertegenwoordigd. Vraag je af wie er besluit over een architectuur. Zijn er te veel beslissingsgremia? Bedienen deze de klant of fungeren ze omdat de opdrachtgever niet in staat is zelf keuzes te maken?

Flow creëren houdt in hetproces inzichtelijk te maken door activiteiten aaneen te koppelen, zodat een flow ontstaat van nieuwe en bijgewerkte archtiectuurproducten. Beperk het aantal architectuurproducten waaraan je simultaan werkt. In een enkele organisatie wordt met succes gewerkt met een Kanban-bord die het proces en het aantal onderhanden architectuurproducten inzichtelijk maakt.

Pull op basis van de klantvraag

Pull op basis klantvraag houdt in, het proces pas in gang zetten wanneer er een klantvraag is. Het betekent ook dat de architect ervoor moet zorgen dat de architectuur geen speeltje wordt van de sponsor. Vraag je af wie de èchte klant is!

Verder zijn we het er over eens dat op moment er een verandering gaat plaatsvinden in de organisatie, de architect er meteen bij betrokken moet zijn om waarde te kunnen toevoegen. Dit fenomeen werd al in DyA (Dynamic Architecture, Sogeti) onderkent met het “just in time & just enough” principe. Uiteraard vinden we dit ook terug in GEA. Vaak is een oplossing al vroegtijdig beklonken of is er al een keuze gemaakt voordat een architect erbij gehaald wordt. Immers die architect kost alleen maar veel tijd en geld en levert nauwelijks iets op. Als architect ben je in die situatie niet meer aan het doen van het administreren van de gekozen oplossing. De oplossing ter discussie stellen blijkt dikwijks niet meer mogelijk omdat dan tijdslijnen oveschreden worden.

Verbeter continue

Continue verbeteren heeft betrekking op zowel de architectuurproducten als ook het -proces. Door constant alert te blijven op verbeteringen ontdek je nieuwe mogelijkheden voor een efficiënt proces en verbeterde producten. Wij architecten evalueren niet of te weinig naar onze mening. Of we evalueren wel maar doen er vervolgens niets mee en blijven in de waan van de dag voortploeteren. Een mogelijke oorzaak is in deze blog al aangestipt, archtiecten zijn vaak te innovatief van aard en kijken doorgaans liever vooruit dan terug. Zijn we niet te veel continue aan het vernieuwen in plaats van aan het verbeteren? Vernieuwen in die zin dat we de hele aanpak (methode, proces, templates, et cetera) ter discussie stellen en verwerpen met een nieuwe aanpak, methode, proces, et cetera. Feit dat we nu tegen een 3e “wave of architecture” aanlopen is hier wellicht een voorbeeld van. De architectuurfunctie is nog (te) weinig gestandaardiseerd en denken dan alweer aan een compleet nieuwe aanpak in plaats van het bestaande te verbeteren. Lean gaat uit van continue verbeteren in kleine stappen; meer evolutie dan revolutie.

Tot slot

De hier beschreven bevindingen zijn het gezamenlijk resultaat van een avond brainstormen en discussieren over hoe de waarde van architectuur vergroot kan worden middels het toepassen van Lean principes. Tussen spekhaken is het Lean-principe vermeld. Recapitulerend, de belangrijkste bevindingen teneinde meer waarde toe te voegen aan architectuur zijn om ervoor te zorgen dat:

• Resultaten van het architectuurproces worden gebruikt door de klant. Dit is doorgaans de bestuurder en/of het ontwikkelteam. Wees je ervan bewust dat een bestuurder andere informatie waardevol vindt dan een ontwikkelteam, er is dus geen “one size fits all”.  [waardecreatie].
• Betrek de klant bij de definitie van het probleem. De klant bepaalt immers welke informatie waardevol is. De architect dient zich te focussen op de combinatie probleem en klant, in plaats van als expert voor het probleem.  [waardecreatie].
• Maak niet te veel of te weinig architectuurproducten, maar stem het af met de klant(groepen).  [verspilling].
• Doe aan hergebruik en standaardisatie. Overweeg het gebruik van een architectuurrepository.  [verspilling].
• Zorg voor een formeel goedkeuringsmoment waarbij de klant is vertegenwoordigd.  [flow]
• Standaardiseer het voortbrengingsproces en beperk het aantal onderhanden archtiectuurproducten/-documenten (beperk work-in-progress). Overweeg het gebruik van een Kanban-bord die het proces en het aantal onderhanden architectuurproducten inzichtelijk maakt.  [flow]
• De producten worden gemaakt op een moment dater behoefte aan is vanuit de klant, “just in time, just enough”. Als architect moet je er meteen bij zijn op moment er een verandering op til is of op moment er belangrijke organisatorische beslissingen worden gemaakt.  [pull]
• Houdt de architectuurproducten up-to-date waardoor ze waardevol blijven. Architectuurproducten die achterlopen met de werkelijkheid zijn waardeloos.  [continue verbeteren]