Enterprisearkitekten som forandringsagent
- Eller: En personlig granskelse af organisationers fremtidige arbejde med enterprisearkitektur.

I dette indlæg ønsker jeg først og fremmest at dissekere og fremstille begrebet enterprisearkitektur (EA) på en lidt anderledes måde end størstedelen af talerne på EA-konferencen. Selv om størstedelen af de mange EA-rammeværk og -værktøjskasser er opstået ud af erhvervslivets (berettigede!) behov for best practices frem for mellem sociologiens og organisationsteoriens fire akademiske vægge, vil jeg alligevel være så flabet at hive arkitekturbegrebet ind under sociologiens skærende byglampe. Forhåbentligt kan en bedre forståelse af grundlaget for og en art metateori om discplinen skabe bedre resultater i både offentlige og private organisationer.

Lidt baggrundsteori
Selv om mægtige frameworks som TOGAF og beslægtede discipliner som ITIL er opstået ud af stakkevis af best practices fra industrien og it-erhvervet, er det tæt beslægtet med moderne sociologi. Sociologerne DiMaggio og Powell har i en artikel med den udsædvanligt uspiselige titel "The Iron Cage Revisited: Institutional Isomophism and Collective Rationality in Organizational Fields" beskrevet en række indikatorer for, hvad der driver nutidens forandringsprojekter. Enterprisearkitekten er jo netop en forandringsagent, der med mas og besvær søger at beskrive, omlægge og effektivisere virksomhedens vigtigste processer -- med kraftigt tryk på effektivisering. Min påstand er, at EA oftest er et led i en større effektiviseringsproces under CIO'ens forventning, at virksomheden kan blive smidig, konkurrencedygtig og samtidig overholde de retningslinjer, som eksterne faktorer kræver af organisationen (Sarbanes-Oxley, anyone?). Men det fælles rationale er netop: Rationalitet.
DiMaggio og Powell anfægter med en skarp klinge virksomhedens konstante higen og søgen efter en optimal, rationel struktur og eskapader udi ambitiøse buzzwordeventyr som "business process reengineering":

"We argue that the causes of bureaucratization and rationalization have changed. The bureaucratization of the corporation and the state have been achieved. Organizations are still becoming more homogenous, and bureaucracy remains the common organizational form. Today, however, structural change in organizations seems less and less driven by competition or by need for efficiency. Instead, we will content, bureaucratization and other forms of organizational change occur as the result og processes that make organizations more similar without necessarily making them more efficient."

Pointen er altså, at forkromede EA-projekter ikke leder til yderligere konkurrence mellem virksomhederne inden for samme industri -- ej heller skaber det en mere effektiv organisation, når Finansministeriet forsøger at komme i FORM. Næh, det er snarere resultatet af en fælles koncensus, at EA er det "eneste rigtige" inden for en industri eller et specifikt erhverv. Arkitektens egen opfattelse af sin rolle som forandringsagent bør altså ikke bunde i ingeniørens klassiske tanke om rigid rationalitet og optimering af virksomheden, men snarere:

At EA-projekter opstår, fordi virksomheder ensrettes under det globale og regionale pres af politik, regulativer og samhandelsregler. Implementerer Systematic A/S CMMI niveau 5 af pure, rationelle overvejelser, eller skyldes det snarere en tendens i forsvarsindustrien anført af Department of Defence, at man død og pine skal sovses til i procesbeskrivelser for at byde ind på Joint Strike Fighter-projektet?

Overfør den analogi til dit eget EA-projekt og overvej årsagerne til, hvorfor arkitekter er i vælden.

Og hvad skal du bruge teorien til?
En sociologisk funderet forståelse af EA skal ikke kun forsvares for at give universitetsprofessorer højere lønninger. Nej, den åbenlyse styrke er, at det giver en anledning for virksomheden til at spejle sig i sine omgivelser på et højere plan end det konkurrencemæssige og operationelle. Hvorfor skal CIO'en kaste tusindvis af euro i udviklingen af en intern referencemodel? Hvad gør mine konkurrenter? Er det et gevaldigt buzzwordrytteri, som galoperende horder af enterprisekonsulenter har listet ind ad bagdøren for derefter at fakturere for os for det rene luft, fordi "EA er det nyeste, hotte i branchen"? Kan EA effektivisere forretningen, eller skaber det udelukkende en større kløft mellem IT, forretning og strategi, fordi vi bruger mere tid og flere penge på at dokumentere og modellere frem for at handle og markedsføre?
Frem for alt har det en anden, interessant konsekvens, som i min optik er hamrende vigtig: EA er ikke et værktøj, som vi kan købe os til, eller et produkt, som vi kan modellere os frem til i Eclipse eller en UML-editor. En fornuftigt sammenstykket EA er i konstant forandring og reflekterer netop det førnævnte politiske og institutionelle pres, som jeg præsenterede før. Det opstår i og vokser op igennem organisationen (emergence), men succesen er i hvert fald ikke proportionel med antallet af dyre diagrammer eller fancy softwaresuiter til arkitekten. En sådan kritisk ransagelse bør efter min mening være in mente hos fremtidens enterprisearkitekt.

Efterlyses: Smidighed!
Nok akademia. I mit arbejde med EA og ikke mindst procesrelaterede projekter har jeg tit oplevet, at man spørger sig selv: Er det her virkelig arbejdsbyrden værd? CMMI, der er en model til at måle, dokumentere og forbedre udviklingsprocessen i en softwareforretning, er faktisk et godt eksempel: Meget af arbejdet går ud på at måle effekten af de skridt, vi foretager os, når vi udvikler et stykke software. Processerne skal nøje beskrives, og derefter formoder ledelsen blindt, at ensretningen af softwareprocessen afføder bedre produkter. For mange practitioners er CMMI dog også et gevaldigt, bureakratisk arbejde, for procedurerne skal følges, og alle skridt måles og vejes.
Den samme problematik vil jeg -- lidt provokerende -- overføre til EA-feltet: Hvis alle statslige instanser skal overholde FORM, kan vi så blindt stole på, at det skaber en mere effektiv offentlig sektor? Udfaldet kan lige så godt være diagramrytteri og stakkevis af EA-artefakter for vores blå øjnes skyld, inden ordene 'portaler' og 'EPJ' går hen og bliver yt. Læssevis af nøje procesbeskrivelser skaber selvsagt kun værdi, hvis det stemmer overens med medarbejdernes arbejde -- og det samtidig er en lettelse at følge processen frem for en tung dokumentationsbyrde. Sidstnævnte har -- efter min opfattelse -- været et stort problem for softwareudviklere, der har arbejdet i en virksomhed, der har implementeret CMMI.
Det, jeg efterlyser inden for fremtidens EA, er en høj grad af smidighed i de værktøjer og processer, arkitekturen gennemløber. Det massive procesapparat, man sætter igang, når TOGAF kommer på bordet, kan forståeligt nok skræmme mange. Kompleksiteten og ambitiøsiteten, der ligger bag EA, kan være en "resistance to change" -- og dermed en art forandringsprojekternes hækkeløb.
Fokus på smidighed og "agile EA" kan med rette hente inspiration fra udviklingsdiscipliner som Scrum og eXtreme Programming. Her er formålet netop at gøre udviklingsprocessen så overskuelig og let, at man hurtigt kan vende processen i en anden retning og dermed bedre håndtere de usikkerheder, som omgiver kravspecifikation, forretning og virksomhed. Jeg har bestemt ikke løsningen derpå, thi dertil er pladsen alt for smal. Men hermed er bolden givet op til en diskussion af:

1) Hvorfor kompleksiteten og dokumentationsarbejdet i EA og governance kan være en stopklods i sig selv -- frem for en effektivisering.
2) Givet at du er enig: Hvordan kan vi -- med baggrund i f.eks. Scrum og agile udviklingsmetoder -- gøre EA til en smidig disciplin, der muliggør skalering og tilpasning frem for store, forkromede referencemodeller, der har let ved at falde ud af trit med virkeligheden?
3) Med skalerbarhed mener jeg, hvordan EA også kan tilpasses mindre foretagender og projekter -- uden at det bør omfatte samtlige processer i et multinationalt selskab. Vil en agil EA-metode gøre arkitekturarbejdet mere spiselig for selv mindre virksomheder?

Links:

books.google.com/books -- Læs artiklen af DiMaggio og Powell.