Hva er TOGAF?
The Open Group Architectural Framework (TOGAF) er et åpent rammeverk for enterprise arkitektur. The Open Group er for de fleste mest kjent for sertifisering av Unix operativsystemet, som er et godt eksempel på en åpen standard. TOGAF er utviklet og vedlikeholdt av The Open Group Architecture Forum. Første versjon kom ut i 1995 og er opprinnelig basert på det amerikanske forsvarets rammeverk TAFIM (Technical Architecture Framework for Information). TOGAF-dokumentasjonen er fritt tilgjengelig på nettet.
Hva inngår i TOGAF-rammeverket?
Sentralt i TOGAF er ADM (Architecture Development Method)-metoden og Enterprise Continuum som består av «Best Practice» gjenbrukbare arkitektur komponenter. Man kan se på Enterprise Continuum som et referansebibliotek for enterprise arkitektur utøvere og andre interessenter. Foruten ADM og Enterprise Continuum har TOGAF ressurser og referanser knyttet til forskjellige teknikker, metoder og løsninger som kan brukes til både planlegging og gjennomføring av virksomheten sin arkitektur.
Hva er TOGAF ADM?
ADM (Architecture Development Method) er prosessen som brukes for å analysere en hel organisasjons eller et spesifikt område i organisasjonen. Den viktigste grunnen til å anvende ADM er for å kvalitetssikre at de riktige prosjektene starter opp med de tilhørende endringsplanene for både forretning og de underliggende IT-systemene. Ved hjelp ADM får man fram de spesifikke forretnings- og virksomhetsbehov. ADM består av ti faser.
Figur 1: TOGAF ADM.
Man kan kjøre Iterasjon gjennom hele ADM syklusen, iterasjon mellom ADM fase og en eller flere andre ADM-faser. Det er også mulig “besøke“ tidligere ADM-faser. Det er mulig å ha flere prosjekter som samtidig kjører gjennom ADM med synkronisering mellom prosjektene.
TOGAF og begrensinger
En stor fordel med TOGAF er at det er en åpen standard tilgjengelig for alle og hvor alle har muligheten til å bidra. Men åpenheten og de mange bidragsyterne kan igjen gi inkonsistenser i dokumentasjonen. Når det er mange som bidrar er det viktige å være enig om de samme konseptene. TOGAF er ikke et modelleringsverktøy eller et kvalitetssystem men er der som et verktøysett som du kan tilpasse til din organisasjon. Rammeverket har tidligere vært brukt av offentlige organer i USA det ligger derfor mye erfaring bak.
En svakhet med TOGAF er den omfattende dokumentasjonen og at ikke alt vil ha praktiske nytteverdi for alle virksomheter. Mange ser på TOGAF som for akademisk og teoretisk, og mangel på praktiske eksempler i TOGAF-dokumentasjonen styrker dette synet. Størst nytte vil man typisk ha av ADM, Enterprise Continuum, Architecture Capability Framework og maler. ADM er motoren for å kunne få gjennomført arkitekturendringer i et selskap. ADM er også den komponenten i TOGAF som er mest tidløs. Den svakeste delen av TOGAF er referansemodellene. TOGAF sin TRM (Technical Reference Model) som er en “Foundation Architecture” viktigste mål er å sette navn på terminologien som inngår mellom kommunikasjons og applikasjonslaget (SW, applikasjonsplattform og kommunikasjon). III-RM er en teoretisk applikasjonsmodell som har grensesnitt til basale tjenester du finner i et standard operativsystem. Her har tydeligvis folk med operativsystem og nettverk kompetanse bidratt. Det skinner her gjennom at The Open Group har jobbet med Unix sertifisering. Vi kjenner ikke noen prosjekter som har brukt hverken TRM eller III-RM. Grenseløs informasjonsflyt (Boundaryless Information Flow) er et konsept-varemerke beskyttet av Open Group. TOGAF ønsker at alle nødvendige data er tilgjengelige for alle (når som helst) så lenge man har rettigheter til disse dataene. I en organisasjon sitter vi som regel i en silo med begrenset informasjon. Målet for bedriften må være at data kan flyte fra start til slutt av forretningsprosesser (eller verdikjeden), på tvers av avdelinger og forretningsenheter og at alle i organisasjon får tilgang til nødvendig informasjon. TOGAF sier at en utvidelse av infrastruktur- og forretnings-applikasjoner område under TRM, støtter ideen om "Grenseløs informasjonsflyt". Dette vil av de fleste kun bli betraktet som en markeds-jippo.
Flere og flere bedrifter kurser sine ansatte i TOGAF og sier at de skal bruke metoden men praksis viser at mange ikke bruker metodikken. TOGAF skisser en ideell styringsmodell men vi ser at de fleste større bedrifter har som regel en mer kompleks organisasjon som ikke passer sammen med TOGAF sin styringsmodell. Jeg savner eksempler på arbeidsfordeling/ansvar med tilhørende rollespill mellom enterprise arkitekt -funksjoner (både på strategisk og segmentnivå), programleder, forretningsplanlegger, strategiskplanlegger og prosjektstyring.
Endringer av organisasjonen foregår i de siste fasene i ADM-prosessen men i det virkelige liv skjer dette kontinuerlig. ADM prosessen er fleksibel og man vil se at ikke alle bedrifter vil følge den tradisjonelle prosessflyten visjon, arkitektur, muligheter, løsning, styring/gjennomføring. Mange ønsker kanskje å starte med mulighetene først! Hvordan kan endringsledelse være et skritt på slutten av den arkitektoniske prosessen når det skjer hele tiden? Dette er faktisk innebygd i ADM men vanskelig å se. Fase H binder sammen den implementerte arkitekturen fra ADM prosess A-G med neste ADM prosess A-G. For en organisasjon med utviklet enterprise arkitektur kapasitet er dermed prosessen H-A-...-G (-H). Når gjelder fasen «Preliminary» er ikke den med her da den brukes kun når din enterprise arkitektur kapasitet behøver å utvikles eller endres. Integrasjon med andre rammeverk er viktige for TOGAF, metoden ADM skal også kunne tilpasses med andre selskaper sine tilhørende rammeverk. Men hvordan man skal integrere er ikke beskrevet? Her savner jeg rett og slett eksempler på hvordan man integrer med andre rammeverk. enterprise arkitektur verktøy kan være TOGAF sertifisert. Arkitekter kan være TOGAF sertifisert. Men det finnes ikke noe TOGAF sertifisering for selskaper og organisasjoner? Vi har eksempler på bedrifter som hvor de enkelte divisjonene i selskapet er så forskjellige at man strengt tatt ikke kan ha hverken felles IT prinsipper eller IT strategi, de vil derfor ende opp med forskjellige tilpassinger av TOGAF?
TOGAF er forretningsdrevet men IT orientert
Man fokuserer kun på delene av forretningen som støttes av IT. TOGAF prøver å omfavne forretningsanalyse og forretningsendringer, men er først og fremst ment for å forbedre effektiviteten av IT-støtten for virksomheten. Noen er uenige med TOGAF sin skisserte styringsmodell hvor enterprise arkitekt rapporterer til IT-direktør. Burde enterprise arkitekt rapporterer til adm. direktør slik at man lettere kan knytte arkitektur planlegging til forretningsmessige mål? Enterprise arkitektur ble oppfunnet av IT-avdelingen som et hjelpemiddel for å understøtte forretning bedre. Forretningssiden har aldri bestilt enterprise arkitektur konseptet og spør vanligvis heller ikke om dette (selv om de burde!). For å knytte arkitekturplanlegging til forretningsmessige mål, må virksomheten innse at IT er en del av virksomheten, og at IT arkitektur er en del av virksomhetens arkitektur!
Er du virksomhetsarkitekt eller løsningsarkitekt?
Vi ser i praksis at de fleste enterprise arkitektene fungerer som løsningsarkitekter, enkeltstående prosjektene blir prioritert fremfor langsiktig mål og strategier. Dette er et stort problem! En viktig verdi for bedriftens enterprise arkitektur i henhold til TOGAF er å komme vekk fra prosjektet tilnærming på forretningsmessige endringer, og få et mer langsiktig perspektiv, som også muliggjør kortere og mindre komplekse utviklingsprosjekter med lavere risiko og større kostnadseffektivitet. En enterprise arkitekt som blir knyttet til arkitektur i et enkelt utviklingsprosjekt i 4 måneder, for deretter å løpe til et annet prosjekt i 5 måneder er sannsynligvis i praksis en løsning arkitekt. Hvis man tar AMD på alvor som metoden for å gjennomføre forprosjekter for endringer, og arbeide etter TOGAF sin Architecture Capability Framework så vil skille mellom en enterprise arkitekt og en løsningsarkitekt være tydelig.
