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.