På tvers eller på tverke?

Arkitektur i it-sfæren forbindes med teknikk. Vi kaster rundt oss med begreper som tjenesteorientert arkitektur, Microsoft-arkitektur og nettverksarkitektur. De er som oftest upresist definert, det vil si at alle kan legge det i ordene som de ønsker. Dessuten pleier vi å nevne (og tegne) informasjonsarkitektur og teknisk arkitektur, det vil si hvilke bokser vi bruker og hvordan de er koblet til hverandre. Alt dette har relevans for dem som utvikler applikasjoner, anskaffer infrastruktur eller drifter maskiner. Men det betyr ikke en døyt for dem som driver forretningen.

Har de på forretningssiden behov for noe som kalles arkitektur? Jeg tror det, du tror det, men tror de det? Hvorfor skal de være interessert i noe som de betrakter som a) uforståelig teknikk og b) bortkastet arbeid? Svære, tettskrevne papirark, fulle av firkanter, som blir hengt på veggen for å samle støv?

Skal vi selge virksomhetsarkitektur (populært kalt EA, enterprise architecture eller konsernarkitektur) til dem, må vi selv skjønne hvorfor. Spørsmålet "skal vi ikke ha EA her i bedriften?" virker avskrekkende og abstrakt. Her er noen bedre spørsmål: Skal vi gjøre ting på tvers av organisasjonen? Skal vi ha flere prosjekter gående samtidig? Innføre flere applikasjoner samtidig? Skal vi planlegge noe som gjelder for mer enn én forretningsenhet?

Logikken

Hvis svaret på noen av disse spørsmålene er ja, er det bruk for en virksomhetsarkitektur. Den behøver ikke å se ut som en arkitekttegning full av detaljer, mer som en oversiktsskisse, men den skal vise helheten. EA dreier seg om planlegning mens de andre, mer håndgripelige arkitekturer retter seg mot iverksetting – bygge, kjøpe, endre, implementere.

Det er kanskje bedre å droppe ordet arkitektur. Det vi snakker om er en reguleringsplan, en byplan. De enkelte bygninger har sine uttrykk og utforming som arkitekten har gitt dem. En byplan viser hva slags hus som skal stå hvor og hvordan vi kommer herfra til dit. Den regulerer helhetsinntrykket og gateløpet.

EA er nyttig ut fra to perspektiver. Det ene er å angi standarder og veiledning når de samme ting skal gjøres flere steder. Og det andre er å bestemme hva som gjøres på deling istedenfor å implementeres individuelt.

Aksepterer du logikken så langt, har du antageligvis sett hvor jeg vil hen. En virksomhetsarkitektur har fem formål. Det første og viktigste er å planlegge på tvers av divisjoner eller forretningsenheter. Her stopper vi ikke lenger ved organisasjonens ytre rammer, men tar med oss samarbeidspartnere som kunder og leverandører. Formål nummer to er å sørge for at denne planlegningen faktisk skjer. Det er vanlig i større organisasjoner at hver divisjon planlegger for seg, men det slutter der. Det tredje formålet er å skaffe et felles begrepsapparat for hele organisasjonen. Det finnes vanligvis ikke, og er opphavet til mange misforståelser og mye frustrasjon.

Formålet

Men vi kan ikke stoppe her. Da har vi laget noe som opplagt er bra, et fundament, men hva skal det være godt for? Det fjerde formålet er å øke organisasjonens "agilitet", evne til å respondere raskere på ytre forandringer. Med EAs hjelp klarer vi å overblikke sammenhengene. Hvilke konsekvenser må en forandring få? Hvilke prosesser skal endres? Hvilke applikasjoner må bli videreutviklet? Hvilke ressurser mangler vi? Er det noen nye linker som må til?

Det femte og siste formålet er å sørge for at de konsekvenser vi har fått øye på, blir satt ut i livet.

En rasjonell tankegang – eller hva? Nøkkelspørsmålet som gjenstår er: Hvem vil støtte den med entusiasme, ressurser og penger, når EA unektelig ligner sentralisert planlegning? It-direktøren? Sikkert. Toppledelsen? Kanskje. Forretningslederne? Kanskje ikke, de liker ofte å kjøre sitt eget løp. La oss ikke stikke hodet i sanden – EA er litt teknikk, litt forretning og mye politikk.