Stadig flere organisasjoner blir opptatt av arkitektur og ansetter arkitekter. Det er bra, å beskjeftige seg med arkitektur overbygger avstanden mellom forretning og IT og det skaper helhetsblikk. Men måten de nærmer seg saken på ofte er begredelig.
Straks diskusjonen begynner å kretse rundt arkitektur, kommer nemlig V-kortet på bordet. V står for verktøy. La oss velge et ordentlig verktøy, sier noen (ofte fra IT) og dansen er i gang. En lang kravspesifikasjon blir utarbeidet, leverandører kontaktet og spørsmålet stilt: Kan ditt verktøy gjøre dét? Og dét? Og hva med dét? Krysse av, analysere, utpeke svakheter. Månedene går. Til slutt velges verktøyet som har fått flest kryss og færrest tomme ruter. Helst skal det ligge blant lederne i Gartners magiske kvadrant.
Det er som å spenne vognen foran hesten. Kanskje er det sant at klær skaper folk. Verktøy skaper ihvertfall ikke arkitektur. Å arbeide med arkitektur er så mangslungent, det kan dreie seg om teknologi, applikasjoner, forretningsprosesser, informasjon, forretning. Behovene varierer fra organisasjon til organisasjon. Alt kan ikke gjøres samtidig. Skal man lykkes, må det være enighet om hva det er man skal fokusere på. Hvilket problem skal vi løse? Hva skal vi bruke verktøyet til? Mange arkitekturprosjekter kommer ikke lengre, intern uenighet dreper dem.
Arkitektur er politikk. Arkitektur er makt. De som har festet grepet kan i en betydelig grad bestemme dagsorden. Hvis de er sterke nok. Derfor vil det være mange syn på hvor man skal ta fatt. Mange misliker at det er noen andre som tilriver seg definisjonsmakten.
For å komme i gang og finne ut om enighet og fokus kan skapes, er det godt nok med klassiske kontorverktøy som Word, Visio, Powerpoint og ikke minst Excel. Kompleksiteten er beskjeden, det viktige er at samtalen kommer i gang. Hvis det viser seg at arkitekturarbeid i større stil er mulig å få til, da kan man skaffe seg et spesialisert verktøy som kan håndtere, sammenknytte og lagre mengder av elementer, lag på lag. På fagspråket kalles dette et repository.
Men altså først: Hvilket problem vil vi løse? Hva skal vi bruke verktøyet til? Den beste måten å besvare det spørsmålet på er å beskrive typiske og spesifikke brukssituasjoner, populært kalt use cases. Ingen andre metoder er i nærheten av use cases for å fokusere på det som er viktig og spesielt. Når Gartner sammenligner produktene på markedet, er det use cases som blir anvendt. Hvordan foreslår du at ditt verktøy skal løse denne spesifikke utfordringen, er spørsmålet til leverandørene. Så kan de demonstere hva de er kommet frem til. Da blir det mye lettere å sammenligne.
Dette bør følges opp av en pilot eller proof-of-concept som baserer seg på ekte programvare og ekte data brukt av ekte brukere. Leverandørene skal etablere PoC og overlevere det til utprøving. Da vil man få syn for sagn – hvor vanskelig er det å bruke verktøyet til noe nyttig? Hvilket verktøy passer oss best? Klagen Gartner oftest får høre fra misfornøyde brukere av slike verktøy er at de er altfor krevende å bruke. Så dette er viktig å sjekke.
Det er også lurt å se seg rundt i organisasjonen: Hvilke verktøy har vi allerede anskaffet? Kan noen av dem brukes til å realisere de use cases vi har valgt? Det viser seg ofte at det finnes løsninger som kan brukes, ihvertfall i en innledningsfase.
Å velge verktøy kan i seg selv være krevende, men den største (og minst omtalte) utfordringen ligger i kulturen. Arkitektur er pr definisjon tverrgående, den prøver å favne sammenhengene i hele organisasjonen. (Det er derfor det heter ”enterprise architecture”.) Men de fleste organisasjoner er fortsatt vertikalisert i ”siloer”. Å knytte siloene sammen gjennom arkitektur eller prosesser kan bli et stridens eple. Hvem vil ”eie” arkitekturen eller prosessene? Hvem vil betale for lisensiering, trening og brukerstøtte? Hvis svaret er at det skal IT gjøre, har man tapt. Det blir ihvertfall mye friksjon og lite fremdrift. I verste fall blir det fine verktøyet liggende på hylla, sammen med andre feilinvesteringer.
“Kanskje er det sant at klær skaper folk; verktøy skaper ihvertfall ikke arkitektur”
