September 2001: Enterprise Architecture Framework (EAF) van John Zachman

Deze maand een stelling die de basis vormt voor een aantal methoden en technieken voor het ont-wikkelen en instandhouden van architecturen aanvecht. De stelling luidt:

---
“Het door John Zachman geïntroduceerde en gepropageerde Framework voor Enterprise Architecture and Information Systems Architecture is sterk verouderd.“
---

Ongeveer 20 jaar geleden heeft de Amerikaan John Zachman een framework in de vorm van een matrix geïntroduceerd[zie voetnoot 1]. Het framework is een algemeen schema dat bedoeld is om ontwerp-“artefacts” (volgens Zachman: beschrijvende representaties van welk complex object ook) te kunnen classificeren. De bedoeling van een classificatie schema als dit framework is dat het mogelijk is om met details bezig te gaan terwijl het algemene beeld (de context, het perspectief) bewaard blijft.

Figuur 1: Het Framework van John Zachman

Dat doel is met dit schema ook wel dichterbij gekomen. In een tijd dat men nog niet echt nadacht over architecturen en brede conceptuele modellen heeft dit framework voor enige mate van orde in de chaos van de automatisering gezorgd. In latere jaren zijn de systemen echter groter en complexer geworden. Het werden er bovendien steeds meer. Met als resultaat dat het noodzakelijk werd om in veel breder termen na te gaan denken over de inzet van IT (en oplossingen die met andere technolo-gie gerealiseerd worden/zijn). Met die verbreding in het denken is het framework van Zachman ver-ouderd.

In de 60-er/70-er jaren introduceerde IBM het woord architectuur voor de opbouw en de inrichting van haar computers. Daarmee werd een andere betekenis aan het bestaande woord toegevoegd, een homoniem. Een architectuur is een beeld van een werkelijkheid en niet alleen een tekening of een model van “iets”. Het beeld dat we een architectuur noemen kan hoogstens gevisualiseerd worden met tekeningen en modellen. Het aardige (en tegelijkertijd moeilijke) van een architectuur is dat je die nooit helemaal zult vastleggen in woorden, tekeningen, modellen enz.. Probeer bijvoorbeeld maar eens een complete beschrijving te maken van het gebruiksgemak van een informatievoorziening. Het is maar zeer de vraag of je bijvoorbeeld zachtere zaken als gevoelens compleet beschreven kan krij-gen, laat staan dat dat binnen een afzienbare (en betaalbare) termijn zou kunnen. Wat IBM bedoelt met architectuur is een beeld van één of van een netwerk van computers. Zo’n beeld is, hoewel dat soms niet eenvoudig zal zijn, in kaart te brengen. Veel verwarring zou voorkomen zijn als IBM een, overigens eveneens zwaarbeladen, woord als model gebruikt had in plaats van het woord architectuur.

Dit concept is ook terug te vinden in het framework van Zachman. De laatste versie kent 5 rijen: Scope, Enterprise Model, System Model, Technology Model en Detailed Representations. De rijen System Model en Technology Model dekken af wat IBM in eerste instantie met de term architectuur wilde aanduiden. De componenten in de cellen van de rijen brengt de technologie in beeld in termen als in-formatiesysteem, applicatie, gegevens, systeemsoftware, hardware, netwerk enz.. We hebben het hier over de werkelijke betekenis van het woord Informatie Technologie (IT).

Deze elementen komen ook in een reeks andere modellen voor. Zo omvat de ISO-standaard voor Open Distributed Processing (ODP) een computational, engineering en technology viewpoint. Die indeling is wat praktischer opgezet dan de 2 rijen van Zachman en bedoeld om de opzet van open sys-temen en distributie goed in kaart te kunnen brengen. Om die reden worden resp. applicaties + data, systeemsoftware en technologie (hardware en netwerk) gezien als separate lagen die “onafhankelijk” van elkaar functioneren. Met als achtergrond dat systeemsoftware los moet werken van bepaalde hardware en netwerk componenten, zoals bij open systemen. Dat geldt ook voor het loskoppelen van applicaties + gegevens en systeemsoftware. Ofwel: systeemsoftware kan op allerlei hardware draai-en en applicaties/data kunnen gebruik maken van allerlei systeemsoftware. Transparantie, dus. De rijen System Model en Technology Model in het Zachman framework omvatten deze elementen ook. De 3-deling past beter bij de praktijk dan de indeling in 2 rijen.

2 andere rijen van het framework, Scope en Enterprise Model, zijn bedoeld om de aansluiting van de IT uit de voornoemde rijen met de enterprise cq. business in kaart te brengen. Het enterprise model brengt het semantische model van de informatie, de bedrijfsprocessen, de workflow enz. in beeld, terwijl de rij Scope allerlei context definities bevat van entiteiten, functies, mensen enz.. Waar veel organisaties op dit moment mee bezig zijn is de aansluiting tussen de IT en de business. In lijn met het denken van Tapscott & Caston[zie voetnoot 2] is veel aandacht besteed aan het verbeteren van deze aanslui-ting onder de noemer “business alignment”. Deze alignment is in het framework vooral terug te vinden in de relatie tussen de rijen Enterprise Model en System Model.

Een probleem in het framework is dat elk van de 30 cellen in de matrix, naast 5 rijen zijn er 6 kolom-men, een aspect van IT zouden belichten. Dat is nog wel goed voor te stellen in de cellen van de rijen System Model en Technology Model. De ODP-achtige herindeling in 3 viewpoints laat al veel meer zien van de verschillende specialismen die betrokken zijn. In de praktijk blijkt dat elk viewpoint zich in een combinatie van één of meer bij elkaar passende beroepsgroepen vertaalt. Zo hebben mensen met een engineering viewpoint als specialisme systeemsoftware. Zij weten het nodige over applica-ties en gegevens, maar zien daar mensen met andere disciplines waar zij zo goed mogelijke facilitei-ten voor moeten realiseren.

Mensen met een enterprise viewpoint kijken naar de enterprise, de business zelf. Het inrichten van die enterprise is belangrijk om te weten te komen waar welke ondersteuning gewenst of zelfs vereist is. Dus: de business alignment. Om te weten hoe je bedrijfsprocessen opzet en inricht moet je het nodige van die enterprise/business afweten, zoals organisatie adviseurs, AO-specialisten enz.. Van verzekeringen, bankzaken, productie, vervoer enz.. Daarom zijn mensen met een enterprise view-point, terecht, ook niet in eerste instantie met IT bezig. IT is voor hen een hulpmiddel om bedrijfspro-cessen beter en soepeler te laten verlopen. Desnoods door een bedrijfsproces in zijn geheel te auto-matiseren. Business specialisten zijn dan ook gebaat bij een optimale business alignment. Een goede afstemming met bijvoorbeeld applicatie specialisten is daarbij onontbeerlijk. Veel van de inhoud van de cellen van de Scope en Enterprise Model rijen, zoals de bedrijfsprocessen en bedrijfsplannen, ho-ren in het werkgebied van de business specialist en niet in dat van de IT-er. Daarmee zijn die cellen geen aspecten van IT meer en dat is anders dan het framework aangeeft.

Nieuwere modellen dan het Zachman framework introduceren een nieuwe “laag” tussen het aan-dachtsgebied van de business specialisten en dat van de IT specialisten. Deze laag is het aandachtsgebied van de informatie specialisten, de informatiekundigen. In ODP spreken we bijvoorbeeld over het information viewpoint. In dit viewpoint hoort wat gezegd kan en moet worden over het bedrijfsmiddel cq. de productiefactor informatie.

De elementen van deze laag zijn ook geen aspecten van IT. In deze laag worden de elementen eruit gelicht die iets zeggen over de gegevens die informatie zijn in de context van de business. Een aantal van de elementen uit het Zachman framework horen thuis in deze laag, zoals de entiteitdefinities, het semantische model en veel van het logische model uit de Data kolom en de business rules. Maar ook vele zaken die geen expliciete plaats hebben in dat framework, zoals (generieke) functies, informa-tiebeleid, informatieplan, (functioneel) beheer enz.. De inhoud van deze laag dient zo goed mogelijk aan te sluiten bij de business en is leidend bij het inrichten van IT-elementen als systemen, applicaties, bestanden enz.

Naast de genoemde IT specialismen hebben we dus 2 groepen met nieuwe disciplines gevonden, de business/enterprise specialisten en de informatie specialisten. Naast de alignment van business en IT zien we “alignments” tussen business en informatie (de gespecificeerde behoefte aan informatie) en tussen informatie en IT (specificatie versus realisatie). Afstemmingen waarvan we tegenwoordig we-ten dat ze zeer belangrijk zijn en die niet in het framework terug te vinden zijn.
We kunnen nog een stap verder gaan door de notie tijd te introduceren in een framework. Je brengt dan de huidige situatie naast het toekomstige in kaart en kijkt naar migratiepaden. In dat geval ontstaan er 8 verschillende soorten alignment, die elk een eigen, belangrijke rol in het geheel spelen. Het voert te ver om die alignments hier te beschrijven, het is wel duidelijk dat het Zachman framework hier niet in voorziet. De opzet van het framework, een matrix, is daar te statisch voor. De verdeling in rijen en kolommen blijkt in de huidige praktijk erg onhandig te zijn, onder meer omdat de cellen niet vrij aan elkaar te relateren zijn.

Het Zachman framework wordt “Enterprise Architecture and Information Systems Architecture” ge-noemd. De term architectuur in Information System Architecture is, zoals gezegd, vergelijkbaar met de term model gebruikt. De Enterprise Architecture heeft te maken met het introduceren van de disciplines business en informatie specialist. De beelden die deze specialisten hebben van hun vakgebied zijn enorm complex en anders dan het beeld dat een IT specialist heeft. Zoals het er nu naar uitziet kunnen we dan ook spreken over een bedrijfsproces architectuur en een informatie architectuur. Bedrijfsproces architecten en informatie architecten hebben het viewpoint dat past bij deze genoemde architecturen. Ze zullen het nodige van elkaars vak moeten weten om met elkaar te kunnen commu-niceren en om synergie mogelijk te maken.
In de veelheid van specialismen rond IT zou over een IT architect gesproken kunnen worden. Daarbij is het waarschijnlijk dat de IT architectuur in de toekomst een beschrijfbaar model zal zijn. Dat is niet te verwachten van de andere 2 architecturen.

De stelling is dat het Zachman framework verouderd is. Enkele argumenten die deze stelling staven:

• Minder dan de helft van de 30 cellen brengen IT aspecten in beeld.
• De rijen Scope en Enterprise Model brengen aspecten van een enterprise/business in beeld. Deze aspecten komen in het framework niet als zodanig naar voren.
• Allerlei cellen, verspreidt over de matrix, brengen aspecten van informatie in beeld. Ook deze aspecten zijn niet als zodanig te herkennen in het framework. Bovendien worden ze gemengd met technologische aspecten.
• De notie van tijd en verandering is niet expliciet terug te vinden in het framework.
• De term architectuur wordt homoniem gebruikt: soms in de betekenis van model en soms in de werkelijke betekenis.
• Het framework gaat alleen uit van oplossingen die met IT gecreëerd zijn. Andersoortige oplossingen hebben geen plek.

Het framework van Zachman heeft bij de introductie, ongeveer 20 jaar geleden, een goede rol ge-speeld in de ontwikkeling van het denken over IT. De wereld is echter niet stil blijven staan en het framework heeft veel van zijn kracht verloren en is zwaar verouderd. Er zijn nieuwe(re) frameworks die beter bij de huidige manier van denken en werken passen. Laten we die gebruiken en het framework van Zachman zijn verdiende plaats in de ontwikkelingen van automatisering cq. IT geven.

Voetnoten:

[1] Voor meer informatie over het framework van John Zachman, zie de website van het Zachman Institute for Framework Advancement http://www.zifa.com/ en de Australische website http://members.ozemail.com.au/~ieinfo/zachman.htm/.

[2] Don Tapscott en Art Caston “Paradigm Shift, the new promise of Information Technology”, 1993, McGraw-Hill inc, New York USA ISBN 0-07-062857-2, zie ook stelling 10 in deze column.