Zachman-katastrofen

Kender du Zachman' Sikkert ikke, John A. Zachman er en ældre amerikaner der oprindeligt er uddannet som kemiker og siden har drevet det vidt. Men måske har du stødt på hans "The Zachman Framework for Enterprise Architecture", også kaldet for Zachman i daglig tale'

Modellen, som giver mulighed for katastrofer, består af en matrix hvor kolonne-overskrifterne i sin essens er en udtømmende række af hv-spørgsmål (hvad, hvordan, hvor, hvem, hvornår og hvorfor) der besvares ud fra en række synsvinkler, nemlig fra planlæggerens, forretningsejerens, designerens, entreprenørens og underleverandørens. Bag ved disse synsvinkler ligger en filosofisk betragtning af tingsliggørelse, altså hvordan en abstrakt ide udvikles til en instans, et fysisk objekt - en filosofi som jf. wikipedia åbenbart stammer fra de gamle græske filosoffer.

Illustration: Privatfoto

Resultatet af denne filosofiske øvelse bliver en masse felter (30 styk) som du kan udfylde med dokumentation af den nutidige eller fremtidige situation for en enterprise: Logisk datamodel, semantisk model, præsentationsarkitektur, kontrolstrukturer, logistiknetværk og 25 andre slags dokumenter.

Problemet med Zachman (altså "The Zachman Framework for?") er sådan set, at det bare ligger dér og virker komplet og fuldstændig. Mere præcist udtrykt er problemet egentligt at folk bruger det som en bibel når de dokumentere en Enterprise arkitektur.

I modsætning til Zachman kender du sikkert Spørge-Jørgen: En dreng i røde bukser og stribet trøje med en ubændig lyst til at spørge om alt mellem himmel og jord. Hans forældre ender med at blive så trætte af ham, at han får en endefuld og sendes på hovedet i seng. Når en Enterprise arkitekt bruger Zachman som dokumentations-kanon får hans chefer lyst til at gøre nogenlunde det samme.

Alligevel er der flere, der har forsøgt sig gennem tiden. Som resultat har ideen om Den Store Enterprise Arkitektur bredt sig. Den Store Enterprise Arkitektur er den totale beskrivelse af alle aspekter af en enterprise. Den store enterprise arkitektur for en bilfabrik i Detroit ville være så komplet og detaljeret, at man alene på baggrund af dokumentationen kunne opbygge en identisk bilfabrik på Amager, trykke på en knap, hvorefter det hele bare kørte. Men hvor tit er det lige vi har brug for dét? Aldrig.

Nogle arkitekter promoverer altså desværre det nyttige at dokumentere 'Den Store Enterprise Arkitektur'. Det har betydet, at folk opfatter EA-disciplinen som et meget stort og tungt stykke arbejde som blot ender med at producere dokumenter, der ender deres liv på en (meget stor) reol.

Der er ingen tvivl om at Zachman er interessant og har været en væsentlig inspirationskilde for en række mere operationelle dokumentations-ontologier som OIO EA reolen eller EA3's Living Enterprise. Men i praksis er den rå Zachman-tilgang ikke en brugbar konstruktion.

Zachman-katastrofen er betegnelsen for den bjørnetjeneste, en Enterprise arkitekt gør sig selv, sin virksomhed og sit fag ved slavisk at benytte Zachman-frameworket til EA-dokumentation. Og hvis du tror at en bjørnetjeneste betyder "en stor tjeneste", så se lige et billede, der illustrerer La Fontaines fabel om bjørnen, der ville fjerne en flue fra sin herres hoved - ved hjælp af en meget stor sten.

Hvis du er i gang med at dokumentere en enterprise, fx som et led i en enterprise arkitektur-proces, så undgå Zachman-katastrofen. Undersøg i stedet præcist hvad det minimalt nødvendige niveau for dokumentation er, og gå så først da i gang med at dokumentere. Din business-case bliver bedre og du forøger chancen for at komme i mål med dit projekt.

Formålet med EA-disciplinen er trods alt ikke dokumentation, men at skabe sammenhængen mellem strategi, forretning og it.

Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Kvan Clausen

Problemet med rammeværker er, at de udfylder andre funktioner end blot at være hylder for dokumentation: de viser noget om visionen for enterprisearkitekturen, og fungerer som illustration af fremdriften i arbejdet. Hvis man helt undlader at bruge dem, bør man derfor starte med at overveje, hvordan man så vil håndtere vision og fremdrift.

  • 0
  • 0
Peter Nørregaard Blogger

Yees, siir, et hvert it-projekt (og et hvert større projekt i det hele taget) bør som minimum orientere sig i forhold til visioner og strategier for virksomheden. Derfor vil de nyttige fremgangsmåder for dokumentation udpege netop dokumenter om strategier og visioner som essentielle.

Problemet med Zachman og reglerne for at udfylde matrixen er, at alt er lige vigtigt at have med – der er ikke en afvejning af hvad der er vigtigst, eller for den sags skyld om noget er mere vigtigt end andet.

Men hvilke erfaringer har du med hvilke fremgangsmåder eller vejledninger der fungerer bedst i praksis?

  • 0
  • 0
Casper Kvan Clausen

Nu arbejder jeg p.t. med et yderst begrænset EA-mæssigt modenhedsniveau, men jeg har haft fin glæde af at sætte mig ned med OIO (som jeg synes lidt bedre om end Zachman) og udvælge et par indsatsområder. Kriterierne var dels at de gav mening for den nuværende situation, dels var skridt i retning af min vision for EA-arbejdet i koncernen.

Men det er selvfølgelig meget lettere, når man starter fra nul. Gjorde jeg ikke det, ville jeg nu stadig starte med at bruge et rammeværk til at kategorisere og få overblik over det eksisterende, og til at identificere områder hvor der kunne være mangler.

Grundlæggende betragter jeg vel i virkeligheden mere rammeværkerne som en slags gabsanalyse-værktøjer og inspirationskilder, end som slutprodukter.

  • 0
  • 0
Leif Andersen

For mig har Zachman været en god referenceramme - ikke en komplet bibel. Bevidstheden om hvilken "søjle" hhv. hvilket lag et begreb hører til har været et godt redskab i mange sammenhænge.
Jeg opfatter Zachman som et bud på en struktur (som ikke er uden svagheder, men som dog er) og jeg mener det er god ide at forholde sig til informationsmodellen for de ting en "enterprise" baserer sin virksomhed på.
For mig er katastrofen større hvis professionelle har svært ved at kende forskel på processer, mål, ting/informationer eller organisationsstrukturer - hhv. hvis professionelle har svært ved at forholde sig til, hvilket beskrivelsesniveau noget hører til.

  • 0
  • 0
Peter Nørregaard Blogger

Selv bruger jeg ofte OIO EA-reolen i forhold til vores kunder, både statslige men også private – den er nemlig rigtig god til at formidle hvad et givent dokument handler om og til at belyse hvilken slags information der mangler i en eller anden sammenhæng, fx i en kravspecifikation.

Specifik har jeg brugt reolen som baggrunds-billede og malet konturerne af dokumenter (fx den funktionelle systembeskrivelse) ind over reolen for at vise hvilke dokumenter i en samlet dokumentation der berørte hvilke dele af reolen. Det er med andre ord ikke en "efter bogen" brug, men den formidler stadigt formidabelt. Kunden, der er statslig og kender reolen, forstår hvor i dokumentations-samlingen de skal lede efter hvilken information, hvilket er en stor hjælp fx når nye folk skal introduceres til området.

Et andet eksempel er, at vi står foran at lave et analyse-arbejde. Her bruger jeg reolen til at vise hvad analyserne vil dække og også hvilket niveau, de udarbejdes på. Fx har reolen gjort det nemt at vise at analyserne tager udgangspunkt i eksisterende dokumentation på det konceptuelle niveau og at de ikke dækker hverken det fysiske niveau eller dækker kolonnen Teknologi. Og kunden forstår det.

OIO EA reolen er klart et vellykket eksempel på en praktisk, om end ikke helt akademisk korrekt, adoption af Zachman.

Er der andre eksempler på dokumenations-rammeværk derude der virker? Eller ikke virker?

  • 0
  • 0
Johnny Lüchau Blogger

Sjovt nok sad jeg forgårs og læste op på både Zachmann og TOGAF, for at finde et passende rammeværk til kommunikationsløsninger. I den anledning stødte jeg også på metoden (til Information Management) MIKE2.0 (og SAFE) - er der nogen der kender til det eller har erfaring med det?

  • 0
  • 0
Peter Nørregaard Blogger

En fælles, struktureret sprog er ikke en katastrofe, men en nødvendighed! Det ser ud til at vi er enige så langt at Zachman-matricen ikke skal tages bogstaveligt og at der ikke med djævlens vold og magt skal fyldes noget i alle felter.

Ud over det store antal dokumentationstyper er et andet problem at der ikke her er noget bud på hvor man skal starte og slutte og hvilke dele af forretningen du i det hele taget bør dokumentere.

Her tilbyder EA3 (eller EA Cube som den også omtales) et relativt begavet koncept om Line of Business, der er en del af den enterprise, vi forsøger at forandre. EA3 er et bedre bud på en operationelt anvendelig EA-metode med en god business-case.

  • 0
  • 0
Jens Jakob Andersen

Hej,

Spørgsmålet er vel hvilke virksomheder der har så fokuserede styringsprocesser, at en stringent og ensartet dokumentation giver stor mening.

Jo mere stringente og velfungerende processer og veldisciplinerede ansatte - jo større glæde af struktureret dokumentation (der også vedligeholdes).

Omvendt - med adhoc processer, ildsjæle, løbende skift i bemanding, metoder, leverandører osv - så er der meget lidt glæde ved fælles dokumentation.

Og der er jo også killer-argumentet, til tider hørt fra leverandører "Vi kan bruge vores eget velafprøvede dokumentations-setup.
Så kan vi lægge en fast pris på den del.
Vi kan også bruge jeres, det gør vi gerne, men så er det time&material.........."

Nå - derudover - jeg har haft stor glæde af hvad jeg kalder "Nem-EA". Bruge EA rammeværk, som f.eks OIOEA eller Zachman eller lignende i "jysk harehøjde" - bruge det som ramme for at etablere et pejlemærke for et fælles sprog der kan bruges på højt niveau til at oversætte mellem projekter og skabe gensidig forståelse.
"Ah, det i kalder services, er det som i OIOEA hedder B4 - det er det vi kalder proces-implementeringer".

Jeg tror på at EA arbejdet skal gøres meget enklere, nemmere, leverance-fokuseret - og så vente lidt med de store rammeværk osv. - men meget gerne bruge et fælles sprog til det fælles repositorie osv. - og een fælles indgang til hvor informationen findes.

Men mon ikke vi om x år bare googler os igennem hvad der er af dokumentation, og finder vej på den måde?

Mvh

Jens Jakob

  • 0
  • 0
Peter Nørregaard Blogger

Jens Jakob har en ret vigtig pointe, som vel gælder alle former for it-understøttelse: Automatisering af processer kræver at processerne gennemføres tit nok og ensartet nok, til at det kan betale sig at dokumentere og efterfølgende automatisere dem.

For organisationer med adhoc processer og den slags, bør fokus snarere være på at understøtte at de rigtige (rigelige?) mængder information er tilgængelige på et hvert givet tidspunkt for de rette folk. Det er en lidt anden indsats, der er nødvendig i de tilfælde, men den kan stadig kaldes EA og der er sandelig brug for en indsats for at understøtte den type organisationer.

Det fælles sprog er jo altid en god ide, som også Leif Andersen skriver ovenfor. Jysk harehøjde er for øvrigt også en god sprogkonstruktion – den må jeg huske at bruge :-)

  • 0
  • 0
Carsten Mølgaard

TOGAF 9 blev annonceret 2. februar i San Diego, og der er store nyheder.

Det ny "Content Framework" gør TOGAF til det første offentligt frit tilgængelige framework til enterprise arkitektur, der både dækker processen, indholdet og kompetencerne.

Det betyder at virksomheder og organisationer kan droppe Zachman og bruge ét og samme framework til enterprise arkitektur.

Mere (på engelsk) i min blog, "The Rasmussen Report":
http://rasmussenreport.wordpress.com/2009/02/06/never-mind-the-architect...

  • 0
  • 0
Marc de Oliveira

Peter, det virker som om du kritiserer Zachman for ikke at være en metode. Selvfølgelig får du ikke at vide, hvor du skal starte eller slutte, eller hvilke felter, der er vigtigere end andre. Zachman Framework er et skelet. En tom reol med en ide om hvad der principielt skal ligge i hver celle.

Zachman Framework kan bruges med vandfaldsmetoder, objektorienterede metoder, ja sågar Lean eller egenudviklede metoder, hvis det er det man er til. Dvs at det er op til brugeren at beslutte hvilken metode Zachman skal bruges med.

Tilsvarende er det også op til brugeren at definere standarderne for den dokumentation, man vil bruge, og dermed også at tildele prioriteringer til de enkelte celler. Det kan være meget forskelligt fra forretning til forretning, hvordan de enkelte elementer bør prioriteres.

Venlig hilsen
Marc de Oliveira
Simplify Systems

  • 0
  • 0
Carsten Mølgaard

Ja, Zachman Frameworket er først og fremmest en logisk klassifikation af de elementer vi beskriver enterprise arkitektur med.

En af mine bekendte betegnede det engang som "pidgeon holes" -- og det er måske ikke helt ved siden af.

Det svære for mange virksomheder har været at finde ud af, hvordan "reolen" egentlig skulle udfyldes i praksis.

Her beskriver det ny TOGAF 9 faktisk disse elementer eller 'artefakter' på hele 170 sider i det ny "Architecture Content Framework".

Se http://www.opengroup.org/architecture/togaf9-doc/arch/

  • 0
  • 0
Peter Nørregaard Blogger

Marc, jeg kritiserer den ukritiske, misforståede brug af Zachman som om den var en metode, selvom den så ganske klart ikke er det. Men John Zachman er måske ikke uden skyld i denne misforståelse da behovet for en nuanceret tilgang til anvendelsen stort set ikke er omtalt i sammenhæng med hans præsentation af rammeværket. Så vidt jeg har hørt, så er John. Zachman selv af den opfattelse, at alle hylder bør fyldes ud, så måske er misforståelsen / Zachman-katastrofen ikke opstået helt af sig selv.

  • 0
  • 0
Marc de Oliveira

Selv om det ikke gør Zachman Framework simplere, så skulle du måske kigge lidt på Zachman DNA (Zachman Depth iNtegrating Architecture), der netop handler om hvordan man integrerer Zachman Framework med feks en metode, men også med ting som projektledelse, test, versionering osv. Der er tale om en 3D-udgave af Zachman Framework.

Zachman DNA er ikke skabt af John Zachman selv, men det er lavet i mere eller mindre tæt samarbejde med ham.

  • 0
  • 0
Søren Tilma

ved godt at det er en gammel tråd, men:

"Zachman selv af den opfattelse, at alle hylder bør fyldes ud, så måske er misforståelsen / Zachman-katastrofen ikke opstået helt af sig selv"

Jeg har lige været på kursus med Zachman, og han mener at det vil være en god idé over tid at udfylde alle celler. Men til konkrete problemstillinger, bør man kun vælge de celler ud der er relevante.

mht. værktøj, så brugte vi Sparxs. Det er ikke et perfekt værktøj til EA, men overholder Zachmans ontologi.

  • 0
  • 0
Log ind eller Opret konto for at kommentere