Enterprise architectuur en Lean

Geen sinecure maar een veelbelovende combinatie.

Auteur: Rob Swinkels

Lean IT

How Lean can you be?

Architectuur is een vakgebied waar Lean nog niet vaak wordt toegepast. Alhoewel de combinatie van de zoektermen ‘lean’ en ‘architectuur’ de nodige resultaten oplevert op Google, blijkt bij nader inzien dat het nagenoeg altijd om de combinatie van Lean met softwarearchitectuur gaat, gekenmerkt door repeterende processen. Dit artikel richt zich op de combinatie van Lean en enterprise architectuur: wat komt er bij kijken om met deze veelbelovende combinatie resultaten te boeken?

Het Lean-gedachtegoed werd in de tweede helft van de vorige eeuw ontwikkeld bij het Japanse Toyota, maar is gebaseerd op Britse en Amerikaanse principes van onder andere W. Edwards Deming en Henry Ford. Tegenwoordig wordt het ook steeds meer toegepast binnen de IT-sector. Vaak wordt dan de term Lean IT gebruikt. Toepassingsgebieden zijn meestal repeterende processen en activiteiten binnen een IT-afdeling, zoals het incident en change managementproces. Daarnaast is ook de toepassing binnen softwareontwikkeling sterk groeiende. Soms wordt dan de term Lean ADM (Application Development and Maintenance) gebruikt, maar ook methoden zoals Agile, Scrum en eXtreme Programming gebruiken concepten uit het Lean-gedachtegoed. De combinatie van Lean en enterprise architectuur is tot nu toe minder vaak voor het voetlicht gekomen.

Kritiek op enterprise architectuur
Enterprise architectuur heeft als doel om ervoor te zorgen dat een organisatie zich in al haar geledingen in de gewenste richting ontwikkelt. Enterprise architecten maken daarvoor beschrijvingen van de gewenste situatie in woord en/of beeld. Bij sommige organisaties staat enterprise architectuur nog in de kinderschoenen of bestaat het niet eens. Bij andere organisaties werken teams aan lijvige architectuurdocumenten en aan een even grote hoeveelheid visualisaties. Dat enterprise architectuur in deze laatste categorie organisaties veel kost, terwijl de resultaten als onvoldoende worden ervaren of op zijn best onduidelijk zijn, is een steeds vaker gehoorde kritiek op het vakgebied. Organisaties die nog niet met enterprise architectuur werken, worden hierdoor in ieder geval niet gemotiveerd om ermee te starten. Dat is jammer, want het toepassen van enterprise architectuur op een juiste manier kan wel degelijk een positieve bijdrage leveren aan de organisatie in het algemeen en de gewenste verandering(en) in het bijzonder.

Lean
De toepassing van het Lean-gedachtegoed binnen enterprise architectuur kan een antwoord op deze kritiek zijn. Om dat antwoord duidelijk te maken is het belangrijk om de vijf uitgangspunten van het Lean gedachtegoed te begrijpen:

1. Definieer waarde vanuit het gezichtspunt van de klant;

2. Identificeer alle waardetoevoegende stappen in de waardestroom en elimineer alle vormen van verspilling (waste);

3. Koppel alle waardetoevoegende activiteiten, zodat flow ontstaat;

4. Laat de klant de waarde door het proces trekken (pull);

5. Verbeter het proces continu.

Door deze uitgangspunten toe te passen op het architectuurproces is de kans een stuk groter dat de resultaten van het architectuurproces worden gebruikt (waarde voor de klant), dat er niet te veel of te weinig architectuurproducten worden gemaakt (verspilling) en dat die producten worden gemaakt op een moment dat er behoefte aan is (pull). Dat klinkt gemakkelijk, maar is het niet. Laten we de uitgangspunten eens nader bekijken.

Waarde vanuit het gezichtspunt van de klant
Dit uitgangspunt lijkt een open deur, zeker als het gaat om het produceren van consumentenartikelen. Het is niet vreemd dat Lean juist in deze context is ontstaan. Het toepassen ervan op (abstracte) processen zoals enterprise architectuur is een stuk lastiger. Welke waarde verwacht de klant van architectuurproducten? Vormen ze een hulpmiddel om de strategie te communiceren? Of hebben ze als doel kaders te scheppen voor medewerkers die vormgeven aan de verandering? Wie is eigenlijk de klant van een architectuurproduct en hoe definieert die de waarde van het product? De opdrachtgever van een enterprise architect is lang niet altijd ook de klant in deze context.

Antwoord krijgen op deze vragen vraagt om een nauwe samenwerking tussen enterprise architect, opdrachtgever en klant(en). In de praktijk zie ik dat deze ‘contractvorming’ vaak wordt overgeslagen. Enerzijds doordat de opdrachtgever er geen tijd aan wil besteden of zelf de antwoorden ook niet heeft. Anderzijds richt de enterprise architect zich als expert vooral op het probleem en niet zozeer op de combinatie van probleem en klant. Het “Statement of Work” uit TOGAF kan als een uitgebreide invulling van deze contactvorming worden gezien.

Elimineer verspilling
Wellicht nog moeilijker dan het definiëren van waarde, is het voorkomen van verspilling. Hier gaat het immers niet om het resultaat, maar om het proces dat tot het resultaat leidt. Afhankelijk van de kennis en kunde binnen de organisatie, vooral op het gebied van enterprise architectuur, is het zaak te bekijken hoe de gewenste resultaten met zo min mogelijk middelen gerealiseerd kunnen worden. Hierbij kan hergebruik van materiaal een belangrijke rol spelen. Hergebruik kan zijn gebaseerd op referentiearchitecturen of eerder geproduceerde producten, maar ook – in het proces – op architectuurraamwerken. Een typerend voorbeeld hiervan kwam ik tegen bij een grote overheidsinstelling, waar werkelijk honderden bladzijden aan architectuurdocumentatie in de kast lagen. De manager en de diverse categorieën architecten waren hiervan op de hoogte, maar de andere stakeholders hadden deze documenten nooit gezien. Een duidelijke verspilling van tijd en middelen dus.

Flow
Het introduceren van flow binnen het architectuurproces is sterk verbonden met het uitgangspunt van continue verbetering. Dit principe is toe te passen om een enterprise architectuur-functie op te bouwen, door te zorgen voor een constante flow van architectuurproducten – nieuwe dan wel bijgewerkte. Dit vraagt om een zorgvuldige planning van wat er nodig is, en wanneer. Ook binnen het proces van een enkel architectuurproduct is het van belang. In de praktijk ben ik al talloze ‘versie 0.9x architectuurproducten’ tegengekomen die nooit de 1.0-status bereiken, omdat formele goedkeuring ontbreekt. Dit roept op zijn minst vragen op als: Moet ik me hier nu wel of niet aan houden? En: Is er inmiddels een nieuwere, wel geodgekeurde versie? Kortom, voorbeelden genoeg van verspilling. Plannen betekent dus ook dat producten in een flow moeten worden samengesteld, inclusief formele goedkeuring en distributie.

Pull
Architecten hebben nogal eens de neiging producten te maken omdat zij denken dat er behoefte aan is. Binnen het Lean-gedachtegoed is dat een schoolvoorbeeld van hoe het niet moet, namelijk het ‘pushen’ van een product. Het toepassen van pull betekent dat er een zorgvuldige afstemming met opdrachtgever dan wel klant moet plaatsvinden over de vraag waar behoefte aan is en wanneer die behoefte er zal zijn.

Het bekende DYA-architectuurraamwerk spreekt van ‘just enough, just in time’, waarbij het gaat om de combinatie van pull met het principe van waarde vanuit het gezichtspunt van de klant. Wie kent niet de architectuurvisualisaties die de gang van de IT-afdeling versieren en meer als decoratie dienen dan dat iemand zijn handelen erdoor laat beïnvloeden? Architectuurvisualisaties kunnen een prima middel zijn, maar dan moet de ontvanger hebben aangegeven er baat bij te hebben.

Verbeter continu
Enterprise architectuur is een jong vakgebied, waar je het streven naar continu verbeteren mag verwachten. De combinatie met Lean zorgt ervoor dat er intensieve en voortdurende afstemming met de opdrachtgever en de klant plaatsvindt. Zo’n proces moet groeien en dat gaat gepaard met vallen en opstaan.

Continu verbeteren is niet alleen op het proces, maar ook op de architectuurproducten van toepassing. Organisaties die al langer enterprise architectuur toepassen, zitten vaak opgezadeld met een hele reeks gedateerde architectuurproducten. De waarde vanuit klantperspectief is bij zulke gedateerde producten vaak ver te zoeken. Door ook architectuurproducten continu te verbeteren en up-to-date te houden, wordt verspilling van de eerder geïnvesteerde middelen in het product voorkomen.

Eisen aan de enterprise architect
Het toepassen van dit alles stelt hoge eisen aan de enterprise architect. Hij moet beschikken over een pragmatische benadering van het vakgebied, wat iets anders is dan het toepassen van een standaardproces. Architectuurraamwerken zoals TOGAF beschrijven een reeks van opvolgende processen, onderverdeeld in activiteiten die een stapel aan documenten opleveren. Een dergelijk raamwerk is waardevol als referentiekader, maar vanuit Lean oogpunt is het toevoegen van waarde vanuit klantperspectief belangrijker dat het volgen van een voorgeschreven proces. Hiervoor dient de enterprise architect wel te beschikken over een gereedschapkist rijk gevuld met architectuurkennis en kennis van Lean. Ook dat klinkt gemakkelijker dan het is. Er is geen eigenaar van Lean en er zijn meerdere instanties die Lean trainingen geven: elk op hun eigen manier en vanuit hun eigen context. Vaak wordt Lean gecombineerd met Six Sigma of wordt het specifiek binnen de context van een branch of proces geplaatst, zoals respectievelijk Lean IT of Lean ADM (application development and maintenance).

In de praktijk
De in dit artikel geschetste werkwijze is toegepast bij een groot Nederlands bouwbedrijf, waar een werkmaatschappij voor zijn kernprocessen afhankelijk was van een landschap van maatwerkfunctionaliteit zonder documentatie, gecreëerd door een team dat de organisatie inmiddels had verlaten. De directie wilde weten hoe ernstig de situatie was en ook hoe architectuur verbetering kon brengen, door waarde voor de klant te creëren. In korte tijd (flow!) is het landschap op basis van interviews en technisch, vooral visueel onderzoek in kaart gebracht, met behulp van de tool ArchiMate (hergebruik, geen verspilling!). Op basis hiervan kon de directie de ernst van de situatie inschatten en de IT-strategie verder vormgeven (verbeter continu!), wat weer leidde tot het verzoek om architectuurproducten op dit gebied (pull!).

Conclusie
Het combineren van enterprise architectuur en Lean vraagt om architecten die de nodige bagage hebben op het gebied van meerdere architectuurraamwerken en de geëigende elementen daarvan kunnen inzetten, afhankelijk van de wensen en eisen van de klant. Dit vereist veel begrip voor de organisatie en de richting waarin ze zich verder wil ontwikkelen. Daarnaast moet er het vermogen zijn om die ontwikkelingsrichting te vertalen in veranderingen op het gebied van processen, informatie en techniek. Deze gewenste veranderingen moeten vervolgens hun weerslag krijgen in architectuurproducten die bij de organisatie passen. Dit alles in de juiste vorm en op het juiste tijdstip.

Al met al geen sinecure, maar als aan deze voorwaarden wordt voldaan, vormen Lean en enterprise architectuur een veelbelovende combinatie.

Rob Swinkels is senior consultant en enterprise architect bij Quint Wellington Redwood, een adviesbureau dat zich richt op het grensvlak van organisatie en IT.