Gaat “Lean” samen met architectuur?

Op 1 april 2014 ben ik begonnen als architect bij Solventa. De auto die ik in gebruik kreeg deed mij denken aan de Lean managementfilosofie. De methode is afkomstig van de Japanse autofabrikant Toyota, waar men zich baseerde op de gedachten van Henry Ford en de scientific management school. De focus ligt op het tegen gaan van verspilling en het creëren van “flow” in het productieproces. Door de vermindering van verspilling verbetert de kwaliteit en nemen de productietijd en kosten af. Door de successen van Toyota kreeg deze filosofie meer bekendheid en navolgers.

Ook binnen Nederlandse organisaties wordt “Lean” steeds vaker toegepast. Dikwijls resulteert dit in procesmatig werken en het meetbaar maken van de processen. Ook het IT-ontwikkelproces ontkomt er niet aan. Flow creëer je door minder variatie aan te brengen en dus te standaardiseren. Verspilling ga je tegen door de requirements volledig en definitief te hebben voordat je begint. Dit om rework als gevolg van onduidelijke of wijzigende requirements te voorkomen.

Als projectarchitect heb ik meegemaakt dat daardoor de focus sterk gelegd werd op het reduceren van de inzet van de architect. Dit door mij niet eerder in te zetten dan wanneer alle requirements en benodigde resources beschikbaar waren. Van mij werd dan verwacht dat ik op basis van de requirements zo snel mogelijk de Project Start Architectuur opleverde, zodat het proces verder kon.

Deze aanpak botst met wat je als architect wilt. Natuurlijk ben je als architect gericht op kwaliteit en heb je niets tegen efficiënt werken. Architectuur is echter niet alleen gericht op de kwaliteit van de oplossing, maar ook op de juiste oplossing. Het bepalen van de juiste oplossingsrichting kost meestal veel doorlooptijd. Beantwoordt de gevraagde functionaliteit wel de echte behoefte van de organisatie of van de gebruikers? Is dit al onderkend in de doelarchitectuur? Is een bestaande toepassing in te zetten, ook al levert deze niet voor 100% de gevraagde functionaliteit? Zijn er ontwikkelingen in andere projecten, waarmee rekening gehouden moet worden of waarvan gebruik gemaakt kan worden?

Zo vroeg mogelijk in een project meelopen voorkomt dat je als architect als remmende factor wordt gezien. Het bepalen van de oplossingsrichting kan dikwijls al goed op basis van globale requirements. Als architect wil je daarom al betrokken zijn bij een project als de eerste ideeën voor de invulling van een behoefte ontstaan. Daarmee kun je voorkomen dat requirements geschreven worden naar een bepaalde oplossing die men voor ogen heeft, maar die niet past in de doelarchitectuur, te duur is en/of niet de werkelijke behoefte invult.

Als architect vanaf het begin meelopen is uiteindelijk meer “Lean” dan de focus op een zo kort mogelijke inzet van de architect. Heel efficiënt de verkeerde dingen doen is pas echte verspilling.