Niet met 'n Ferrari in de file


Dat is toch wat we eigenlijk willen? Een agile enterprise. Geen agile software development en zelfs geen agile architectuur. Dat zijn noodzakelijke, maar op zich onvoldoende voorwaarden voor een agile enterprise. Deze blog gaat over de agile enterprise, en wat er voor nodig is om agile te worden. (Dan komen we vanzelf weer uit bij architectuur, maar net even anders.)

Agile enterprise

Wat bedoel ik daar nu mee? "Een agile enterprise is een organisatie die in staat is om snel te veranderen". Het gaat hier om de woorden 'snel' in combinatie met 'veranderen':

Snel is een relatieve term. Ik zou zeggen dat er tenminste twee geldige interpretaties zijn: 1. Time-to-market korter dan de concurrent, en 2. Vlugger dan de omgeving verwacht.


Veranderen kan betrekking hebben op verschillende aspecten. Meestal denken we aan het lanceren van nieuwe producten en diensten, terwijl dat misschien wel heel snel kan gaan, maar daarmee niet per se agile. We kunnen echter ook denken aan het aanpassen van de organisatiestructuur. Zo had Cisco destijds een reputatie dat overgenomen bedrijven in no time geCisconized werden. En je kunt ook agile zijn in de manier waarop nieuwe ideeën worden vertaald in gedrag, processen en procedures. Denk bijvoorbeeld aan het nieuwe werken, mobile, BYOD en dergelijke.

Snel kunnen veranderen impliceert dat organisatie, proces, mensen en middelen zo zijn ingericht, dat je optimaal bent ingericht op snel kunnen veranderen. Je voelt wel aan dat er een prijs betaald moet worden om deze capability (bij gebrek aan een goede Nederlandse term) te ontwikkelen. Al in de jaren '90 hebben Treacy en Wiersema in "The Discipline of Market Leaders" ons geleerd dat je als bedrijf keuzes moet maken. Als je als organisatie agile wilt zijn, moet je bereid zijn te investeren. Het klinkt in eerste instantie misschien paradoxaal, maar dat is het natuurlijk niet. De crux is natuurlijk dat we deze investering niet up-front hoeven doen, maar gaandeweg kunnen doen. Mits 'Agile' een onderdeel is van de visie, en we onderweg ontwerpbeslissingen consequent in deze lijn nemen. En daarmee zijn we dan toch bij architectuur aangeland.

Investeren in 'agile capabilities'

Agile gaat over snel kunnen veranderen. Laten we daarom de veranderketen eens beschouwen. Dat kan bijvoorbeeld in deze fasen:

  1. Awareness - ontdekken dat er noodzaak tot veranderen is
  2. Analyse - uitzoeken wat te veranderen
  3. Besluitvorming - besluiten tot daadwerkelijk veranderen (+budget)
  4. Ontwerpen - uitwerken hoe te veranderen
  5. Realiseren - de verandering klaarzetten
  6. Implementeren - de verandering doorvoeren
  7. Borgen van de verandering - de verandering permanent maken

De vraag die je je kan stellen als business owner is: "wat moet mijn organisatie nu goed kunnen in elk van deze fasen om agile te worden en te blijven?" Als enterprise architect kan je jezelf afvragen: "en wat kan de architectuurfunctie hieraan bijdragen?"

Ik stel voor dat beide dames of heren zich samen over deze vragen buigen en concrete verbeteracties benoemen. Ze hebben immers alles met elkaar te maken. Een organisatie is pas agile als de optelsom van de hele keten dat is.

In onderstaand overzicht geef ik enkele voorbeelden van capabilities die horen bij een agile organisatie. Sommigen daarvan zijn gemakkelijk, anderen grijpen diep in op cultuur. Als voorbeeld neem ik de context van productinnovatie.

agile capabilities van de organisatieagile capabilities van de architectuur
1. Awareness
  • Iedereen in de organisatie wordt gestimuleerd om veranderingen te spotten (early warnings).
  • Professionele veranderaars (marketing, R&D, corporate staff, ...) hebben oog voor de nabije en verdere toekomst.
  • Er is een laagdrempelige manier om early warnings op de juiste plek te krijgen (al was het maar een ideeënbus).
  • Het past in de cultuur dat Architecten en hun peers (...) op een ad hoc basis de mogelijke impact van veranderingen bespreken.
  • Architecten weten - in voldoende mate - wat de strategische en tactische issues zijn binnen het bedrijf en in de omgeving, en wat die betekenen voor architectuur en actuele projecten.
  • Architecten hebben werkrelaties met marketing, productmanagement, business analisten, executives, ...
2. Analyse
  • Er is een plek in de organisatie waar early warnings snel kunnen worden geanalyseerd. Dit kan de wandelgang zijn, maar ook een innovatie unit. Eis is voldoende ervaring en kunde. Focus op de Wat vraag, zonder direct de Hoe-vraag te verdiepen.
  • Deze plek is in staat om naar behoefte zelf te selecteren, en om conclusies snel op de agenda te krijgen van beslissers.
  • Architecten zijn vroegtijdig betrokken bij nadenken over veranderingen. Het 'erbij gevraagd worden' is iets dat verdiend moet worden, vaak op persoonlijke titel.
  • Architecten zijn in staat om de impact (kansen, bedreigingen) van veranderingen vroegtijdig door te denken en in de juiste gremia (...) op de agenda te krijgen.
  • Architecten zijn in staat hoofd- van bijzaken te scheiden. Wat zijn key (IT-)capabilities? Wat kan de organisatie aan?
  • De architectuurfunctie denkt multidisciplinair, d.w.z. van business- tot software-architectuur. Liever door een samenwerkend team dan door één primadonna.
3. Besluitvorming
  • Besluiten worden genomen. Leiderschap.
  • Besluiten worden genomen door 'hen die er van zijn' (laag gedelegeerd in de organisatie).
  • De besluitvormingscyclus wordt zo kort mogelijk gehouden als verantwoord is. Competitief kort.
  • Architecten zijn in staat de agenda's te beïnvloeden.
  • Architecten zijn in staat om architectuurkeuzes (bijv. in de context van portfolio of projecten) van pro's en con's te voorzien, op een voor beslissers acceptabele manier.
  • Architecten weten er van, maar zijn er niet van. M.a.w. dialoog i.p.v. dictaat.
4. Ontwerpen
  • Er is een innovatieproces ingericht. In het bijzonder: is er een keuze gemaakt of de veranderorganisatie náást of ín de lijnorganisatie staat.
  • Het is duidelijk waar de organisatie agile wil zijn. Product innovatie, fusies, openen van buitenlandse vestigingen, front office, ... Zoals gezegd: agile is een keuze. Overal agile zijn is onbetaalbaar.
  • Ontwerpen kan ook met anderen: ketenpartners, crowdsourcing.
  • Hier verwijs ik naar het gedachtengoed van Agile architectuur.
  • Er is een goed doordachte balans tussen architectuur-in-de-lijn, en architectuur-in-projecten.
  • De architectuur (als product) is ontworpen voor agility. Hoe je dat doet is stof voor een andere blog...
  • Structural capabilities zijn vroegtijdig onderkend (SOA, BRMS, Cloud, Layered architecture, ...), want het kost tijd om deze voorzieningen te maken.
5. Realiseren
  • Hier verwijs ik naar het gedachtengoed van Agile Development, waarover voldoende gepubliceerd is.
  • De architect blijft er bij. Geen architectuur-over-de-schutting-gedrag.
  • De architectuur leert van het project. Architectuur is het begin van de dialoog, niet het einde. Onzekerheid is een leermoment voor de volgende keer.
6. Implementeren
  • De product owner was er steeds bij dus de implementatie levert geen verrassingen.
  • Implementatie in fasen. Een lerende benadering.
  • De architectuur leert van het project.
7. Borgen van de verandering
  • Lessons learned staan expliciet op de agenda. Continuous improvement. Lean: Go See.
  • Architectuur ken geen vastgestelde releases. De architectuur verandert voortdurend (maar wel gecontroleerd). De architectuur heeft een datum.
  • Een balans tussen structural capital (repository, methods, tools) en human capital (vraag het Jan). Die balans heeft iets te maken met omvang, cultuur, stijl en hoe men agility wil bereiken.

Kortom: een agile enterprise en een agile architectuurfunctie gaan hand in hand. Heel hard werken aan alléén een agile architectuurfunctie of een agile ontwikkelstraat leidt er op zijn best toe dat je een Ferrari hebt die vervolgens in de file van de veranderketen staat. Weet je hoe frustrerend dat is? En wat een kapitaalvernietiging dat is? Niet doen dus. We gaan voor de agile enterprise!

Mijn advies aan enterprise architecten die van agile serieus een succes willen maken is daarom: zoek een wannabe agile business owner, en daag hem of haar uit om de daad bij het woord agile te voegen. Loop samen eens door bovenstaande veranderketen. Spreek acties af en blijf in gesprek over de vorderingen, zowel links als rechts!

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • ‘Just enough’ architectuur

    In gesprek met collega’s en klanten over hoeveel architectuur een organisatie nodig heeft, lijken we elkaar te kunnen vinden in de formulering ‘Just-enough’. Maar hoeveel is dat dan?

    Lees verder
  • U bevindt zich hier

    Architectuur is bij grotere organisaties een volwassen functie. Enterprise Architectuur wordt ingezet om grip te krijgen op de informatievoorziening. Solution Architecturen worden gemaakt om project specifieke oplossingen in te kaderen.

    Lees verder
  • Waar blijft het applaus?

    Het overkomt ons allemaal wel eens. Je hebt je best gedaan op een mooi stuk werk, en je bent trots op het resultaat. De analyse is degelijk, de architectuur die je bedacht hebt is beter dan marktconform, helder gedocumenteerd en gepresenteerd.

    Lees verder
  • Het stiefkind van de enterprise architectuur

    Ik stel me voor dat u bij het lezen van deze titel onbewust al heeft ingevuld waar ik het over heb. En ik stel me ook voor dat velen van u het goed geraden hebben. De Architectuur van de Technische Infrastructuur, verder afgekort met TIA.

    Lees verder
  • Good Ideas - Agile en architectuur

    Deze animatie geeft de essentie van agile weer en zet ook de relatie met architectuur op scherp. Maar de kijkers komen niet altijd tot dezelfde conclusies.

    Lees verder