A framework for understanding and

comparing Enterprise Architecture

models

Marné de VriesUniversity of Pretoria

Management Dynamics 17Volume 19 No. 2, 2010

ABSTRACT

INTRODUCTION

The different worlds of business and InformationTechnology (IT), and the necessity for their alignment tocreate business effectiveness and efficiency, are the topicsof this study. Enterprise Architecture (EA) has beenproposed as a tool to create business-IT alignment. SeveralEA models and frameworks have been proposed, eachbased on a different value-creation paradigm. Few casestudies, however, demonstrate the integrated use of thesemodels and frameworks.

This study addresses the need for a common reference forcomparing alignment approaches in addressing business-IT alignment. More specifically, it analyses EnterpriseArchitecture (EA) frameworks and the components thatare used to optimise business-IT alignment. Somecommon patterns are identified and re-packaged as part ofa proposed business-IT alignment framework (BIAF).

The conceptual BIAF components are used to demonstratethe interpretation of the framework for four prominentmodels: the Zachman Framework. the Open GroupArchitecture Framework (TOGAF), the Federal EnterpriseArchitecture (FEA), and the Gartner EnterpriseArchitecture Framework (GEAF).

The BIAF forms the foundation of the case-study approachto research in business-IT alignment in this study, andoffers a framework for analysing business-IT alignment ina single organisation. The study also provides a commonreference for cross-case business-IT alignment analysesfor industry-related organisations.

The current information systems in wide use are becomingincreasingly complex. This complexity is primarily due tothe growing demand for information systems and IT

infrastructures to support multiple business functions.As aresult, some organisations may require new strategies forgoverning and evolving their complex information systemlandscapes, which include IT infrastructure, in-housesystems, and commercial-off-the shelf (COTS) products.One requirement is that governance strategies are neededto ensure information system agility in supporting rapidbusiness changes.

Enterprise Architecture (EA) has emerged as a tool forsystematic, holistic planning and decision-makingfor the operation and evolution of an enterprise’s businessand IT systems. EA, in particular, has receivedattention in IT circles, and several value propositionshave emerged, including using EA to control costs; theoptimisation of IT expenditure; and controlling/governing IT capital planning, information systemdevelopment/implementation, and security.

In contrast with the cost and consolidation focus of manyIT managers, EA practitioners and business managersstarted to realise the potential of using EA as a tool tocreate business-IT alignment (surveys by Schekkerman,2006; Matthee, Tobin and Van der Merwe, 2007; and casestudy by Plazaola , 2007). According to the 2007survey by Luftman and Kempaiah (2008), “IT andbusiness alignment” and “attracting, developing, andretaining IT professionals” have consistently been themajor IT management concerns since 1994. Business-ITalignment has been an important challenge in both privateand public/non-profit sectors since the early 1980s (Knolland Jarnvenpaa, 1994). There is strong evidence of a linkbetween business-IT strategy alignment and firmperformance (Luftman and Kempaiah, 2007), business-ITalignment being defined by the alignment assessmentapproach of Luftman (2003).

However, the attainability of a business-IT-alignedorganisation is impeded by various factors. One of themain culprits is the fact that EA originated within the

et al.

Information and Communication Technology (ICT)environment. Most architecture efforts followed a bottom-up approach, modelling the current technical layers (data,applications, and technology) with a few attempts to linkthese layers back to the process architectures,organisational structures, and roles in an organisation.Software architects primarily focused on efficiency/costreductions due to application/data/technologystandardisation and/or consolidation. These efforts rarelydemonstrated links to the motivational aspects of abusiness vision, mission and goals, and businessoptimisation. In addition, architecture models mainlyreflected the world of IT, where IT systems were believedto be complicated systems whose behaviour could bepredicted by analysing the component interactions.

Contrary to the analysis approach to understanding ITarchitectures, strategy and business architectures require adifferent paradigm for analysis and comprehension(Gharajedaghi, 2006). Organisations are typicallycomplex, non-deterministic, social systems that involvehumans and their unpredictable behaviour. In addition,strategic/business variables are interdependent rather thanindependent. Although it is possible to use mechanismssuch as modelling languages and tools to createmechanical links between strategy/business architecturecomponents and IT architecture components, thesemechanisms do not address the behavioural nature oforganisations.

Some practitioners in the field of Business Architecture(BA) suggest that organisations follow a top-downapproach in aligning business with IT. The top-downapproach implies that one starts an EA analysis byexamining the business strategies and architectures, thentranslating these into IT requirements. This approachplaces IT in a “reactive” mode, i.e. IT strategy andstructures should be derived from organisationalconditions. Business-IT alignment efforts then create astatic fit rather than a dynamic fit (Knoll and Jarnvenpaa,1994). Few organisations realise the potential value ofcreating the capability for organisational flexibility andagility, resulting in resistance when facing change.Organisations may also need to consider external fit as wellas internal fit (Miller, 1992). Currently, supply chainmanagement and applications partially cover thisrequirement.

Business-IT alignment requires a combination ofmechanisms to link the different worlds/paradigms ofstrategy/business and IT. EA needs to addressthe challenge of the interaction of complex systems withcomplicated systems (Wegmann, 2002). The strategy/business and IT domains have an interactive effect(strategically and operationally) on one another, and couldboth be strategic drivers, especially for organisations thatoperate in information-intensive industries. Business-ITalignment mechanisms thus need to address the dynamicinteraction between the worlds of strategy/business and IT.

OBJECTIVES OF THE STUDY

A FRAMEWORK FOR AN OPTIMAL BUSINESS-IT ALIGNMENT

Building the conceptual model

Luftman and Kampaia (2007) point out that manyorganisations still face significant challenges in aligningbusiness activities with IT. Although it is still an art formrather than a science (Wegman, 2002), it is believedthat there is no silver bullet for aligning business activitieswith IT.

There are various alignment theories, each with its owncombination of alignment dimensions, mechanisms, andillustrative case studies. Yet there are very few case studiesto demonstrate the integrated use of these theories. Today,many EA practitioners follow a lightweight and pragmaticapproach to EA and business-IT alignment (Gartner, inSessions, 2007; Theuerkorn, 2005; and Wagter .,2005).

The purpose of this study is to introduce a framework tounpack business-IT alignment in terms of genericapproaches, dimensions, mechanisms, and practices thatare proposed by theoretical models to facilitate business-IT alignment. Whereas previous frameworks simplycompared EA frameworks with one another(see Schekkerman, 2004), this framework could be used tocompare different theoretical models in terms of theirbusiness-IT alignment.

Business-IT alignment is considered to be one of the keygoals of EA. There are a large number of theoreticalalignment models today, each based on a certain beliefsystem, each with its own alignment focus and possibleapplication to a specific industry or type of organisation.This study compares the different theoretical modelswith one another in terms of business-IT alignment.A combination of inductive and deductive reasoning wasused to derive a business-IT alignment framework (BIAF).

According to Charmaz (2006:188), induction is “a type ofreasoning that begins with the study of a range ofindividual cases and extrapolates patterns from them toform a conceptual category”. This reasoning requires oneto work back and forth between the themes and the datauntil one establishes a comprehensive set of themes(Creswell, 2007). In contrast, deductive reasoningstipulates analytic categories beforehand “according toan existing framework” (Patton, 2002). A bottom-upapproach was used to analyse the content of varioustheoretical models, using inductive reasoning to formulatethe main components of the BIAF. The conceptualbusiness-IT alignment components were then used in adeductive way to demonstrate the interpretation of theframework for four prominent theoretical models.

et al

18

A number of frameworks have been studied, including theZachman Framework, the Extended EnterpriseArchitecture Framework (E2AF), the EnterpriseArchitecture Planning (EAP) Federal EnterpriseArchitecture (FEA), he Open Group ArchitectureFramework (TOGAF) Integrated ArchitectureFramework (IAF) Dynamic Architecture (DYA)Generalised Enterprise Reference Architecture andMethodology (GERAM) Gartner EnterpriseArchitecture Framework (GEAF), and the EnterpriseArchitecture Cube (The Open Group, 2009; Gartner,2008a; Gartner, 2008b; Capgemini, 2008; OMB, 2007;OMB, 2005; Wagter ., 2005; Bittler and Kreizman,2005; Bernard, 2005; Schekkerman, 2004; O’Rourke

., 2003; GERAM, 1999; Zachman, 1996; and Zachman,1987).

Alignment endeavours/programmes/projects are usuallyfounded on defendable value propositions. These valuepropositions are based on certain belief systems aboutvalue-creation in an organisation and the capability ofmarketing the propositions to the owners/funding parties

, thet, the

, the , the

, the

et alet

al

Business-IT alignment

of the organisation. With reference to Figure 1, the BIAFstarts with the foundation part ( alignment belief/paradigm of creating value”), which determines thebusiness-IT alignment approaches with reference to theother BIAF parts.

A selection of alignment mechanisms and practices (e.g.methodologies, processes, methods, tools, governancestructures) is required to facilitate change/evolution to re-align business with IT. The alignment mechanisms andpractices are also related to one or more BIAFdimensions . The framework contains three key

alignment dimensions, represented by three axes inFigure 1.

rchitecture abstraction layers;Perspective/viewpoint; andOrganising scope.

The “dimensions” part of Figure 1 provides the context ofalignment, answering the questions, “What needs to bealigned?” and “From which perspective?”. The “alignmentmechanisms and practices” part provides the means foralignment.

“

“ ”

“ ”

•••

A

Business & Strategy

Information

Technology

Customers Suppliers

Government

Industry

Competitors

Partners

Arc

hit

ectu

ral

Ab

str

acti

on

Layer

Corporate

BU 1 BU 2 BU 3 BU n

Alignment b

elief/p

aradigm

of

creatin

g value

Alignment Mechanisms

and Practices

Perspectiv

es / Viewpoin

ts

Program 1

Organising Scope

Project AProject B

Project C

FIGURE 1THE BUSINESS-IT ALIGNMENT FRAMEWORK (BIAF)

19

In addition to the aforementioned three dimensions, onecan debate the inclusion of other dimensions. Some EAframework designers, for instance, include a dimension ofgenerality (e.g. generic level, partial level, and particularlevel in the GERA, which is similar to the TOGAF use ofan architecture continuum). The architecture continuumprovides a continuum of generic-to-specific architectures,such as foundation architectures, common systemsarchitectures, industry architectures, and organisationarchitectures.

This study incorporates other dimensions as mechanismswith respect to the main BIAF dimensions. The “alignmentmechanisms and practices” may be seen as any method ormeans (e.g. a way of partitioning, or a tool) or activity thatmay be used to create a business-IT alignment capabilityand contribute to business-IT alignment at different“architectural abstraction layers”, for different stakeholder“perspectives/viewpoints”, and across the “organisingscope” (e.g. business units, programmes, and projects) ofthe organisation. The “alignment mechanisms andpractices” (the slice across three dimensions in Figure 1)form the heart of the BIAF. The capability itself, and theway in which these mechanisms and practices are used orimplemented, affect the success of business-IT alignmentendeavours in a socio-technical organisation.

The “organising scope” dimension also reveals extensionsat the top of the cube (see Figure 1).Alignment endeavoursmay thus involve the organisation, or may be extended toexternal parties such as suppliers, partners, customers,government, industry, or competitors.

The individual parts of the alignment framework are asfollows:

Business-IT alignment practitioners or researchers providedefinitions that convey their belief/paradigm aboutbusiness-IT alignment and its relationship to value-creation.

Luftman and Kempaiah (2008: 102) believe that “business-ITalignment” refers to how business and IT are “integrated, inharmony, converged, linked, fused, synthesized”. Wegmann(2005: 1) believes that business-IT alignment is the“correspondence between a set of components”. Nadler andTushman (1980: 40) have broadly defined business-IT fit as“the degree to which the needs, demands, goals, objectives,and/or structure of one component are consistent with theneeds, demands, goals, objectives, and/or structure of anothercomponent”.

Enterprise Architecture (EA) has emerged as a newdiscipline that has the potential of aligning business withIT. The following themes emerge from various EAdefinitions in terms of its purpose and means of creatingbusiness-IT alignment.

Alignment belief/paradigm of creating value

• Some believe that EA needs to provide an aggregateview or a blueprint for directing the organisation interms of required high-level processes and ITcapabilities ( Ross, Weilland Robertson, 2006; Boar, 1999 ).

Gartner (Willis, 2008:7) believes that EA is about thecontinuous process of transformation from a currentarchitecture to a future architecture “translatingbusiness vision and strategy into effective enterprisechange” (also see Gartner, in Lapkin, 2008; Bernard,2005; Schekkerman, 2004).

Although the abovementioned definitions reveal some ofthe value-creation means, EA practitioners still need todemonstrate value to businesses in terms of bottom-lineresults. An effective value-creating strategy is todemonstrate how EA will be used to address certainorganisational pain-points. Many EA practitioners use EAto demonstrate cost reductions through process andinformation system consolidations (Rosser, 2004).Today the focus of value-creation has shifted toincorporate both efficiency and effectiveness (

Rosser, 2004; Buchanan, 2002).

The architecture abstraction dimension provides themeans for creating logical separations between differentdomains of knowledge, also referred to as “architectureabstraction layers”. These layers provide a starting pointfor defining an architecture metamodel. The metamodeldescribes in a structured way how and with what thearchitecture will be described for a specific organisation(The Open Group, 2009).

Winter and Fischer, 2007;

According to ANSI/IEEE Std 1471-2000,architecture needs to create a systems view - the“fundamental organisation of a system, embodied inits components, their relationships to each other andthe environment, and the principles governing itsdesign and evolution” (IEEE, 2000). The components(in different architectural abstraction layers), theirinteraction and interrelationships, should bedescribed in a consistent way. This should ensureholistic solutions in terms of the solution componentswithin and between socio-technical organisations(see The Open Group, 2009; EA Research Forum,2009; Gartner, in Lapkin, 2008; Winter and Fischer,2007; Theuerkorn, 2005; and Handler, 2004).

Another prominent theme is governance - that is, keyprinciples that are required to govern the design andevolution of information systems, which impactvarious management areas such as maintenance,compliance, and risk management (The Open Group,2009; Willis, 2008; Gartner, in Lapkin, 2008; Winterand Fischer, 2007; Theuerkorn, 2005; Wagter .,2005 ).

Lapkin,2005;

•

•

•

et al

Architecture abstraction layer dimension

20

The literature reveals many different abstraction layersthat may be linked to EA definitions, methodologies, andframeworks. For example, Winter and Fischer (2007) haveidentified five levels: business architecture, processarchitecture, integration architecture (e.g. enterpriseservices), software architecture (e.g. software services anddata structures), and technology/infrastructurearchitecture. The Open Group (2009) defines slightlydifferent architectural layers as part of TOGAF: businessarchitecture, information system architecture (whichincludes application architecture and data architecture),and technology architecture. Zachman (1987), the father ofEA, defines a different set of abstraction layers namelydata, function, network, people, time, and motivation.

Two main categories of abstraction layers emerge from thisreview: Business and Strategy, and InformationTechnology, which encapsulate more detailed abstractionlayers. The abstraction layers may be interpreted asfollows:

Business and Strategy layer: This layer is defined inaccordance with Gharadjedaghi’s (2006) approach inunderstanding organisational complexities. This approachrequires an understanding of the whole in terms ofstructure, function, and process at the same time, in theorganisational purpose and environment or context.The constructs (structure, function, and process) areinterdependent, and form a circular relationship.A preconceived notion of the whole (and its purpose) isused as a starting point for analysing organisationalcomplexities. Several iterations may be required tovalidate original assumptions about structure, function,and process, which may lead to a re-conceptualisation ofthe constructs.

The Information Technology abstraction layer may consistof several technical layers that differ substantially amongframeworks. As an example, one could partition thiscategory into three layers:

The application level conveys the structure of specificapplications, how they are designed, and how theyinteract with one another.

The data level describes the logical data stores in theorganisation, how they are organised and accessed.

The technical level describes both hardware andsoftware infrastructure that supports applications andtheir interactions.

Perspectives/viewpoints are used to group the relatedconcerns of certain stakeholders. These concerns are oftenrelated to certain life-cycle phases of enterprises/information systems. These relationships have beenhighlighted in the GERA. Although IEEE 1741 does notprescribe a fixed set of viewpoints (Hilliard, 2007), most

•

•

•

Perspective/viewpoint dimension

EA frameworks do. Zachman (1987), for instance,identifies six primary viewpoints: scope (contextual),enterprise model (conceptual), system model (logical),technology model (physical), detailed representations(components), and functioning enterprise (workingsystem). Other frameworks inspired by Zachman include asubset of these. The IAF includes only the first fourviewpoints (Capgemini, 2008). The E2AF relates to thefirst four Zachman viewpoints, adding the environmentaland transformational viewpoints.

Perspectives/viewpoints may be related to differentabstraction layers to provide distinct views on the system.According to Hilliard (2007), the Zachman frameworkdescribes 36 views (six abstraction layers x sixviewpoints). Viewpoints that do not necessarily relate tospecific abstraction layers may also be required to conveythe concerns of certain stakeholder groups. The E2AF, forinstance, highlights governance, security, and privacyviewpoints; IAF emphasises security and governance(Schekkerman, 2004), and the EA Cube underlinessecurity, workforce, and standards management (Bernard,2005).

The BIAF is not prescriptive about the viewpoints, butcomments on the use of viewpoints in addressing theconcerns of different stakeholders to enable business-ITalignment.

The scope dimension is used to reflect the extent ofalignment in terms of the organisation structural elements,such as business units or lines of business, departments,programmes, and projects. The named elements are used todefine the boundaries for business-IT alignmentendeavours, and directly influence the required EAresponsibility framework mechanism (one of themechanisms of the BIAF). The selection of appropriatestructural elements for alignment is usually preceded byinitial architecture work to set the intent and extent ofbusiness-IT alignment endeavours. According to the OpenGroup (2009), the Open Group Architecture Framework,Architecture Development Method (TOGAF, ADM), forinstance, starts with a preliminary phase and EA visionphase to define alignment scope. Ross, Weill and Roberson(2006) propose the development of alignment scope basedon the inherent alignment limitations of the organisationaloperating model.

The selected set of mechanisms and practices are based onthe alignment “belief/paradigm of creating value” and thesupporting alignment strategy. The set of mechanismsserve as enablers of alignment and should combatinhibitors. Typically - found mechanisms and practicesinclude the following:

Organising scope dimension

Alignment mechanisms and practices

21

• Frameworks languages artefacts

Methodologies project/system development phases

, , that may beprescribed to ensure alignment across variousdimensions. Examples include the numerous EAframeworks that are found in the literature, such as theZachman Framework, TOGAF, IAF, E2AF, PERA(Purdue Enterprise Reference Architecture),

CIMOSA),(FEAF),

(JTA), andDODAF) . Languages may

be associated with some of the frameworks. Examplesare: BPMN),

IDEF),UML), and

ARIS). Variousartefacts may be produced during architecture work,defined to address the concerns of certainstakeholders, thus addressing certain viewpoints andarchitecture abstraction layers. This approach mayalso be supported by a specific modelling language;examples include process diagrams, organisationstructure diagrams, use case models and class models.

, .A methodology is a “recommended collection ofphilosophies, phases, procedures, rules, techniques,tools, documentation, management, and training fordevelopers” (Maddison, 1983). Examples includearchitecture development methodologies such asTOGAF, ADM, as well as system developmentmethodologies such as

SSADM , Rational UnifiedProcess and James Martin’s RapidApplicationDevelopment Many of the methodologiesalso include development phases. TOGAF

forinstance, includes nine sequential and/or iterativephases.

Computer Integrated Manufacturing Open SystemArchitecture ( Federal EnterpriseArchitecture Framework Joint TechnicalArchitecture Department of DefenseArchitecture Framework (

Business Process Modelling Notation (Integrated Definition Language ( UnifiedModelling Language ( Architecture ofIntegrated Information Systems (

Structured Systems Analysisand Design Method ( )

(RUP)(JMRAD).

Architecture Development Method (ADM),

, for differentexisting management areas, such as programme,project, performance, governance, transformation,financial, service, risk, resource, communications,quality, supplier, configuration, and security. EApractitioners emphasise IT governance as a veryprominent management area within EA (the OpenGroup, 2009; Ross, Weill and Robertson, 2006;Schekkerman, 2004). Control Objectives forInformation and related Technology (COBIT) is a setof best practices for IT management, and ITInfrastructure Library (ITIL) is a set of best practicesfor IT service management.Another area that receivesconsiderable attention in EA models is that oftransformation: transformation roadmaps andpractices are common to various frameworks such asIAF and GERAM.

•

• Policies processes and practices

•

•

•

Analyses

et al

(e .g . gaps / impact /dependency) .This mechanism is directly linked to architecturework that is performed to map out components andrelationships between components. The purpose is touse the analyses’ results to identify performance gapsor gaps in required future architecture. These analysescould be change drivers, guiding decision-makingrelated to the evolution of architectures (see Dunsire

., 2005).

Architecture CapabilityMaturity Model

M (SAM)

Supply-Chain Operations Reference model ValueChain Operations Reference CapabilityMaturity Model Integration

(e-TOM),

Technical Reference ModelReference Model for Integrated Information

Infrastructure

Standards Information Base (

(also with theextended enterprise). This mechanism ensures thatthe appropriate organisation structures, processes,roles, responsibilities, and skills are implemented tosupport the alignment endeavours. Architecturecapability may also be measured using variousmaturity frameworks e.g. the

(ACMM) developed by the USDepartment of Commerce (the Open Group, 2009),the Federal Enterprise Architecture Program EAAssessment Framework 2.0 (OMB, 2005), and theStrategic Alignment Maturity odel ofLuftman, used to indicate IT-business alignmentmaturity (Luftman and Kempaiah, 2007).

. These includegeneric models that may be used to quick-startarchitecture efforts, optimise certain processes,and/or ensure integration across architectureabstraction layers. Examples include GERA

(SCOR),(VCOR),

(CMMI), and enhancedTelecom Operations Map for businessprocesses in the telecommunications industry. Otherexamples include (TRM)and

(III-RM), developed by the OpenGroup. Standards may be defined to ensure consistentdesign for specific architecture abstraction layers,viewpoints, and certain industries. An example is the

SIB) of TOGAF, whichis a catalogue of technology standards andspecifications that are useful in implementing theservices identified in the TRM.

. This mechanismincludes the wide variety of tools and tool sets that areavailable for designing various architecture artefacts.Examples include Systems Architect Family, ARISProcess Platform, Metis Product Family, andABACUS. Tool comparisons or software decision-support instruments are also included under thismechanism category.

Responsibility/capability frameworks

Reference models and standards

Software tools and/or guidance•

22

Alignment approaches

Alignment is not explicitly modelled on the BIAF(Figure 1). The BIAF foundation, alignmentbelief/paradigm of creating value, directly influences thealignment approaches that are followed. An alignmentapproach is defined in terms of other BIAF parts, anddetermines the set of practices and mechanisms that arerequired in accordance with the selected approach.Some of the generic approaches are defined in terms of thefollowing aspects:

Versions of architecture

The version of architecture refers to the version of thearchitecture blueprints with reference to the architectureabstraction layers and perspectives/viewpoints.EA models differ in their focus on creating current and/orfuture versions of architecture.

Some theoretical models focus on building a completeblueprint of the current ( as-is ) architecture. Thesetheoretical models analyse the current architectures beforestarting the future architectures. The Open Group in itsArchitecture Development Method (ADM), as well as theMETA group s EA process model, follow a systematicprocess in analysing current architectures in defining gaps(gap analysis) (Buchanan and Soley, 2002). This is basedon the belief that a current architecture would highlightinefficiencies, reveal opportunities for centralisation, andlead to cost-cutting efforts.

Other theoretical models focus on the future ( to-be”)architectures, while following a pragmatic approach inbuilding a sub-set of “as-is” architectures, depending onthe purpose of the architecture exercise (e.g. providing abaseline for developing a transition strategy). Detailedmodelling is only conducted in a selected and highlypragmatic way ( Buchanan andSoley, 2002), based on the principle of “just enougharchitecture, just in time”.

Starting point and focus of architecture

Most models propose either a top-down or a bottom-upapproach in developing the architectural abstractionlayers.

Some theoretical models start at the business architecturelevel (top level), and work towards the technicalarchitecture layers (bottom levels). Examples includeTOGAF Architecture Development Method (ADM) andthe Gartner EA Process model. These models are based onthe belief that EAneeds to add value in terms of the purposeof the organisation, and contribute towards organisationaleffectiveness, which is embedded in the business strategyand business architecture.

Other models start architecting at the technology layers,attempting to link back to the business layers. This “link-back approach” is usually associated with the belief system

“ ”

’

“

Gartner, in Lapkin, 2008;

that alignment could be attained by simply building a veryflexible IT infrastructure that would easily accommodatechanges in the business layers.

(SOA) projects may be based on thisparadigm (Gartner, in Robertson, 2005). According to TheOpen Group SOA Working Group (2007: 9), “a majorbenefit of SOA is that it delivers enterprise agility, byenabling rapid development and modification of thesoftware that supports the business processes and hencemakes it easier to change the business processesthemselves”.

The dynamic nature of architecture components

EA blueprints are often compared with the blueprints of ahouse. Zachman (1996) himself considered the usefulnessof EA when observing the architecting effort required for aBoeing 747 aircraft (Zachman, 2009). However, theinherent design of an aircraft changes relatively slowlyover time. Some EA theorists consider enterprisearchitectures to be somewhat static, which may lead to aconsiderable amount of effort in designing andmaintaining architecture artefacts. Other theorists acceptthat many architectural components change frequently andrequire a unique approach in terms of design andimplementation.

The Open Group believes that the practice of openstandards and “boundaryless” integration acrossdepartmental/divisional/organisational boundariesaddresses the challenges of dynamic changes. Value-creation is centred on creating maximum flexibilitythrough design, thus creating the ability to change swiftly.However, alignment across the supply chain, integratingdiverse databases and applications written in differentlanguages, remains a challenge. Different integrationlanguages partially address this challenge - e.g.Distributed Component Object Model ( ),Common Object Request Broker Architecture ),Enterprise JavaBeans, and Extensible Markup Language

). Object-orientated and service-orientated designapproaches also attempt to ensure flexibility via loosely-coupled components that could easily be re-used orassembled in a make-to-requirement fashion.

Some approaches acknowledge the architecture designpractices that create flexibility, but emphasise the practicesthat are required to employ architecture in an organisationto enable change (Wagter ., 2005, and Gartner, inBittler and Kreizman, 2005).

Periodic versus continuous alignment

EA models often reveal different paradigms regardingalignment frequency. Some models promote once-offalignment endeavours. The models are supported by theanalysis of current and future architectures to identifygaps, which may lead to rip-and-replace efforts - e.g.Business Process Re-engineering ) (Whitten andBentley, 2007).

Service OrientedArchitecture

DCOM(CORBA

(XML

(BPR

et al

23

Other models address the top-down systematic alignmentof business requirements with information systemfunctionality and its supporting infrastructure - e.g.Business Process Management ) (Whitten andBentley, 2007). Most system development methodologiesprovide alignment methods to ensure alignment betweensystem requirements and system designs.

The BIAF provides a framework for discussing andunderstanding the different dimensions and mechanismsthat are involved in current theoretical alignment models.A few prominent theories are reviewed and compared inorder to demonstrate the use of the BIAF. Italics are used toemphasise reference to various BIAF dimensions.Table 1 provides a summary of the comparative results.

Zachman (1996) has developed the Zachman EnterpriseFramework (six-by-six matrix) that provides a logicalstructure for classifying and organising the descriptiverepresentations that are significant to the management ofthe enterprise and the development of enterprise systems(Zachman, 1996). The framework is used to addressdifferent perspectives/viewpoints ( perspectives” inZachman terminology) and different architectureabstraction layers ( aspects” in Zachman terminology).

The main purpose/value-creating paradigm is to bridge thegap between business people and IT people incommunicating effectively. By using differentperspectives and architecture abstraction layers( perspectives and aspects in Zachman terminology),the framework ensures that all requirements are addressed.The framework is classified as a writing system, aplanning tool, and a problem-solving tool (O Rourke,Fishman and Selkow 2003). The framework does notenforce the development of a certain version ofarchitecture (current or future), nor does it prescribe thedirection of architecture design (e.g. top-down or bottom-up). The dynamic nature of the socio-technicalorganisation could be addressed if primitive models arecreated, updated and re-used as new requirements emerge.

The framework is used primarily to ensure continuousalignment of business requirements with informationsystem functionality and its supporting infrastructure.

According to O’Rourke, Fishman and Selkow (2003),the framework also contains a third dimension (z-axis) toadd certain integrated activities to produce the artefacts.The selection of these activities depends on the projectteam using the Zachman framework, and typicallyincludes project management, project administration,configuration management, change management, versioncontrol, methodologies, standards, and principles.

(BPM

“

“

“ ” “ ”

“” ’

BUSINESS-IT ALIGNMENT THEORIES AND THEBIAF

The Zachman Enterprise Framework

,

The Zachman Enterprise Framework thus focuses on twoBIAF dimensions: and

. Little guidance is given on thethird BIAF dimension: the EA effort in terms ofstructural entities. Other than providing a classificationframework, the EA practitioner is not directed in terms ofalignment mechanisms and practices to ensure theevolution from current to envisioned organisationalarchitectures. The Zachman Enterprise Framework doesallow for alignment of system requirements acrossdifferent organisations (e.g. customers, suppliers, orpartners).

TOGAF, owned by the Open Group, became best knownfor its Architecture Development Method (ADM), whichmay be categorised as an architectural process/methodology, rather than an architectural framework.The Open Group believes that adherence to an iterativeADM, which includes a “Requirements Management”phase, would ensure continuous alignment betweendifferent architecture abstraction layers, addressing thedynamic nature of a socio-technical organisation.However, the gap analysis performed could also lead toperiodic rip-and-replace initiatives. The methodologyfollows a top-down approach in terms of architecturedevelopment, and promotes the development of bothcurrent and future architectural artefacts.

With regard to the BIAFdimension, TOGAF divides an organisational architectureinto four layers (business, application, data, andtechnology). Although a separate set of BIAF

is not defined explicitly, TOGAFrefers to the importance of defining different viewpointsand stakeholder concerns during some of theADM phases.TOGAF provides guidance through architecturepartitioning (Chapter 40 of TOGAF 9) with regard to thethird BIAF dimension, i.e. on EA effort withregard to the inherent organising structures of theorganisation. The ADM primarily focuses on alignmentwithin the boundaries of the organisation, rather thanextending to external parties such as suppliers andpartners.

A rich set of alignment mechanisms and practices isprovided, especially in terms of a methodology(the ADM), policies, processes and practices for certainmanagement areas (e.g. architecture governance and riskmanagement), a framework called the “architecturemetamodel”, languages (e.g. ArchiMate), gap analysesbetween current and envisioned architectures, impactanalyses, responsibility/capability frameworks(e.g. guidance on governance frameworks, architecturematurity, and architecture skills), reference models(e.g. the III-RM), and standards (e.g. the SIB).

architecture abstraction layersperspectives/viewpoints

scoping

architecture abstraction layer

perspectives/viewpoints

scoping

The Open GroupArchitecture Framework (TOGAF)

24

The Federal EnterpriseArchitecture (FEA)

The FEAevolved from the Federal EnterpriseArchitectureFramework (FEAF) as the latest attempt made by theUS government to unite their agencies and functions undera common EA. The FEA Program Management Office(FEAPMO) believes that FEA provides the Office ofManagement and Budget (OMG) and federal agencieswith “a common language and framework to describe andanalyse IT investments, enhance collaboration andultimately transform the federal government” (OMB,2007: 4). FEAhas been developed for a specific enterprise,namely government, and not for private enterprises.Segment architecture development is triggered by bothtop-down (strategic) and bottom-up (tactical) drivers. Interms of architecture versions, architects need tounderstand both the current versions of architecture andplaces where business stakeholders would like to makeimprovements.

To address the dynamic changes on different architecturalabstraction layers, EA work products are created andmaintained to provide a shared view of the current andfuture state of each agency for each performanceimprovement lifecycle. Architecture work products(artefacts) are only created in an fashion to answerhigh-priority business questions. The segment architecturedevelopment process includes a process called “segmentarchitecture maintenance” that continually updatesarchitectural change drivers and their impact on segmentwork products and the programme management plan.The approach mainly supports continuous improvement asdefined by the performance improvement lifecycle of eachagency (OMB, 2005).

FEA fully supports the BIAF dimension bydividing the US Federal Government agencies intomultiple segments that could be classified either asbusiness services or core mission area segments.Enterprise services are identified as cross-cutting services,spanning multiple segments. The classification schemeallows for the re-use of shared assets defined at anorganisational level (e.g. data, business processes,investments, applications, and technologies) as well asaligning segment architectures with organisationalbusiness strategies, mandates, standards, and performancemeasures. Alignment extends the organisationalboundaries, by defining areas of collaboration andcommonality with government and industry partners.

In terms of the other BIAF dimensions, FEA uses thescoping dimension as a starting point to highlightrelationships with and

. FEA defines four: business, data,

application, and technology. Although no formaltaxonomy of is defined (OMB,2006), FEApractices do refer to different stakeholders.

ad hoc

scoping

perspectives/viewpointsarchitectural abstraction layersarchitectural abstraction layers

perspectives/viewpoints

Various alignment mechanisms and practices are defined:the framework (FEA); artefacts (e.g. description ofsegment architecture work products, standard workproduct content and formats); methodologies (e.g. thesegment architecture development process) and projectdevelopment phases (e.g. performance improvementlifecycle); policies, processes and practices (e.g.performance measurement practices required during theperformance improvement lifecycle, and EA governanceprocesses); gap and impact analyses; responsibilityframeworks (e.g. Integrated Program Team [IPT]members associated with segment architecturedevelopment and their role in the segment architecturedevelopment process); and reference models used tofacilitate cross-agency analysis and the identification ofduplicate investments, gaps, and opportunities forcollaboration within and across agencies (e.g. performancereference model, business reference model, servicecomponent reference model, technical reference model,and data reference model).

Gartner, an IT research and consulting organisation,developed GEAM that consists of a Gartner EAprocessmodel and a Gartner EA framework. The Gartner EAprocess model represents key characteristics and asynthesis of best practices for developing and maintainingan EA, while the Gartner EA framework articulates therelationships between business architecture(EBA), information architecture (EIA),

technical architecture (ETA), and their synthesiswith enterprise solutions architecture (ESA). The GartnerEA process model declares the future state of EA to be theheart of the entire process, which should be developedbefore the current state EA. The list of prioritised future-state initiatives and investments guides the scoping ofcurrent-state documentation architecture efforts produce“just enough” artefacts “just in time”. Linked to the future-state approach, Gartner follows a top-down strategy bytranslating business strategy into a set of prescriptiveguides to be used by the organisation in projects thatimplement change. The Gartner EA process modeladdresses the dynamic internal and external environmentalconditions that will affect the future state viachange forecasts for the tactical and strategic planninghorizons. The process model is a multiphase, iterative, andnonlinear model that supports continuous alignment.Periodic re-alignment initiatives could also result from gapanalyses (Gartner in Bittler and Kreizman, 2005).

In terms of BIAF dimensions, Gartner defines threeprimary

business architecture(EBA), information architecture (EIA), and

technology architecture (ETA). Each viewpointrepresents the concerns central to a specific set ofstakeholders. In addition, they define an enterprise

The Gartner Enterprise Architecture Method (GEAM)

the

enterpriseenterprise

enterprise

organisation’s

,

(“viewpoints” inGartner terminology): enterprise

enterpriseenterprise

architecture abstraction layers

25

solution architecture framework (ESAF), which“combines and reconciles the requirements, principles andmodels of intersecting stakeholder-specific viewpointswithin the three primary viewpoints into a set ofarchitectural descriptions that can be used to generate theentire portfolio of enterprise solutions” (Gartner in James

., 2005). Gartner also specifies consistentthat should be applied to each

abstraction layer. These include a business context, and aconceptual, a logical, and an implementation viewpoint(Gartner, in James ., 2005). The Gartner EnterpriseArchitecture Framework does not scope EA effort withregard to the inherent organising structures of theorganisation or extended parties.

Various alignment mechanisms and practices are defined:a framework (GEAF - a method combined with policies,processes, and practices as found in the Gartner EAprocessmodel); limited guidance on analyses (gaps/impact/dependency); and responsibility/capability frameworks(Gartner, in Bittler and Kreizman, 2005).

,et alperspectives/viewpoints

et al

CONCLUSIONS

As a discipline, EA has the potential to re-align businesswith IT to improve both business effectiveness andefficiency. Although a number of theoretical models doexist, few case studies demonstrate the differentapproaches advocated in the various theoretical models.The vast number of strategies and theoretical models thatare used also inhibit business-IT alignment comparisonsbetween organisations - in other words, cross-case studies.

Various theoretical models address the alignmentdimensions and the dynamic interaction between thedifferent worlds of strategy/business and IT, usingdifferent mechanisms and practices. The Zachmanapproach advocates the use of primitive models that needto be created, updated and re-used as new requirementsemerge. The Open Group proposes an iterative ADM,which includes a “Requirements Management” phase, toaddress the dynamic interaction of different architecturecomponents. The FEA uses the segment architecture

Versions of architecture Current / Future /

Non-prescriptive NP C&F C&

Starting oint of rchitecture

NP TD TD / BU TD

Architecture

M Maintenance Model

Periodic or continuous Periodic / continuous /

Non-prescriptive NP P&C C P&C

Abstraction layers

• Business and strategy

BIAF Parts Qualifier Zachman TOGAF 9 FEA GEAM

Mechanisms and practices

Approaches

F

Key dimensions

F

p a Top-down / Bottom-up /

Non-prescriptive

Segment Iterative

Primitive Process

Addressing dynamic nature of components ain mechanism used Models Iterative ADM

Explicitly Defined (Yes / No) Y Y Y Y

• Information technology Explicitly Defined (Yes / No) Y Y Y Y

Pre-defined viewpoints Explicitly Defined (Yes / No) Y N Y Y

Internal and external organising scope

• Internal Omits / Allows / Faciliates A F F A

• External Omits / Allows / Faciliates A A F A

Frameworks, languages, artefacts Articulated (Yes / No / Limited) Y L Y L

Methodologies, project / development phases Articulated (Yes / No / Limited) N Y Y Y

Policies, processes and practices Articulated (Yes / No / Limited) N Y Y Y

Analyses (e.g. gaps / impact / dependency) Articulated (Yes / No / Limited) N Y Y L

Responsibility / capability frameworks Articulated (Yes / No / Limited) N Y Y L

Reference models and standards Articulated (Yes / No / Limited) N Y Y N

Software tools and / or guidance Articulated (Yes / No / Limited) N Y N N

TABLE 1SUMMARY OF FRAMEWORK COMPARISON RESULTS

26

management concerns since 1994. Although several EAtheoretical models exist to promote organisation-widebusiness-IT alignment, few case studies demonstrate thevalue of different theoretical models. In addition,comparative analyses on the success of using these modelsand how the different mechanisms and practicescontributed to enhanced and dynamic business-ITalignment are not available. The BIAF could be used as afoundation for doing comparative analyses that willprovide new insight into the success of EA models due tocertain contributing mechanisms and practices.IT management could consequently use these analyses toselect and / or adapt their business-IT alignment approach.

Bernard, S.A. 2005.(2 ed.). Bloomington:

AuthorHouse.

Bittler, R.S. and Kreizman, G. 2005.. ID Number:

G00130849. USA: Gartner Research.

Boar, B. H. 1999.. NewYork: J. Wiley.

Buchanan, R.D. and Soley, R.M. 2002.

. Whitepaper. Needham: OMG andMeta Group.

Capgemini. 2008. .[Online] http://www.capgemini.com/services-and-s o l u t i o n s / t e c h n o l o g y / s o a / s o a - s o l u t i o n s /ent_architecture/ iaf/. [Accessed 18 November 2009.]

Chamaz, K. 2006..

California: Sage.

Creswell, J.W. 2007.(2 ed.).

California: Sage.

Dunsire, K., O’Neill, T., Denford, M., and Leaney, J. 2005.The ABACUS architectural approach to computer-based sys tem and enterpr ise evolut ion .

: 662-69. USA: IEEE.

EA Research Forum. 2009.. Working document. Pretoria:

EAResearch Forum.

Gartner. 2008a. Develop solution architectures and theenterprise solution architecture. ,November 2008 4. USA: Gartner Research.

Gartner 2008b. Develop the business context., November 2008 4. USA: Gartner Research.

GERAM. 1999..

[Online]http://hobbit.ict.griffith.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html.[Accessed 30 November 2009.]

REFERENCES

An Introduction to EnterpriseArchitecture EA3

Gartner EnterpriseArchitecture Process: Evolution 2005

Constructing Blueprints for EnterpriseITArchitecture

AligningEnterprise Architecture and IT Investments withCorporate Goals

Integrated Architecture Framework

Constructing Grounded Theory.A Practical Guide through Qualitative Analysis

Qualitative Inquiry and ResearchDesign. Choosing Among Five Approaches

In: Proceedings of the 12 IEEE InternationalConference and Workshops on the Engineering ofComputer-Based Systems

Enterprise ArchitectureDefinit ion

In: Gartner Summit

In: GartnerSummit

Generalised Enterprise ReferenceArchitecture and Methodology, Version 1.6.3

nd

nd

th

development process, which includes a process called“segment architecture maintenance”, to continually updatearchitectural change drivers and their impact on segmentwork products and the programme management plan.Finally, GEAM uses a multiphase, iterative, and nonlinearprocess model to address the dynamic internal and externalenvironmental conditions that will affect theorganisation’s future state via change forecasts for thetactical and strategic planning horizons. The authorembarked on follow-up research to consider theeffectiveness of these mechanisms in addressing theinteraction between complex systems with complicatedsystems.

This study has proposed a generic business-IT alignmentframework (BIAF) to comprehend and compare differentalignment beliefs/value-creation paradigms, dimensions,practices, and mechanisms that are employed by currenttheoretical models to facilitate business-IT alignment. Theusefulness of the BIAF was demonstrated by comparingfour prominent theoretical models. Using the BIAF as acommon framework for alignment, one could combine andadapt current models, their mechanisms and practices, toaddress the interaction between complex systems andcomplicated systems more effectively.

The study intended to make a contribution to the body ofknowledge on Enterprise Architecture. The main purposewas to demonstrate how different models attempt toaddress Business-IT alignment. The study was based oninductive reasoning, analysing the content of varioustheoretical models, to formulate the main components ofthe BIAF. The conceptual business-IT alignmentcomponents were then used in a deductive way todemonstrate the interpretation of the framework for fourprominent theoretical models. Additional research couldbe done to validate the BIAF components by analysingcase studies that used different theoretical models or acombination of theoretical models. These efforts may leadto further refinements of the BIAF.

Although the various theoretical models have beendiscussed to address the alignment dimensions and thedynamic interaction between the different worlds ofstrategy/business and IT, follow-up research is required tomeasure the effectiveness of these mechanisms inaddressing the interaction between complex systems andcomplicated systems.

The study’s findings are useful from both a theoretical andmanagerial perspective. According to the 2007 survey byLuftman and Kempaiah (2008), “IT and businessalignment” and “attracting, developing, and retaining ITprofessionals” have consistently been the major IT

LIMITATIONS AND RECOMMENDATIONS FORFUTURE RESEARCH

MANAGERIAL IMPLICATIONS

27

Gharajedaghi, J. 2006.

(2 ed.). New York: ElsevierInc.

Handler, R. 2004.. [On l ine ]

http://itmanagement.earthweb.com/columns/article.php/11079_3347711_1. [Accessed 5 Jan 2007.]

Hilliard, R. 2007. All about IEEE Std 1471. In:

(IEEE Std1471-2000). NewYork: IEEE Computer Society.

IEEE. 2000.

(IEEE Std 1471-2000). New York:IEEE Computer Society.

James, G.A., Handler, R.A., Lapkin,A., and Gall, N. 2005.

. ID Number: G00130855. USA:Gartner Research.

Knoll, K. and Jarvenpaa, S. 1994. Information Technologyalignment or fit in highly turbulent environments:The concept of flexibility. In:

, 1-14.Alexandria.

Lapkin, A. 2005.. ID Number: G00129604. USA:

Gartner Research.

Lapkin, A. 2008.. ID Number:

G00156559. USA: Gartner Research.

Luftman, J., and Kempaiah, R. 2007. An update onBusiness-IT alignment: ‘A line’ has been drawn.

6(3): 165-177.

Luftman, J., and Kempaiah, R. 2008. Key issues for ITexecutives 2007.

.

Luftman, J.N. 2003.. Oxford: Oxford University Press.

Maddison , R.N. 1989 .. Chichester: Wiley Heyden.

Matthee, M.C., Tobin, P.K.J., and Van der Merwe, P. 2007.The status quo of Enterprise Architectureimplementation in South African financial servicescompanies.

, 38(1): 11-23.

Miller, D. 1992. Environmental fit versus internalfit organization. , 3(2): 159-178.

Nadler, D. and Tushman, M.L. 1980. A congruence modelfor diagnosing organizational behaviour. In: Miles, R.

:30-49. Santa Clara CA: Goodyear.

OMB. 2005.[Online] http://

www.cio.gov/documents/OMB_EA_Assessment_Framework_2.pdf. [Accessed 8 June 2009.]

Systems Thinking - ManagingChaos and Complexity: A Platform for DesigningBusiness Architecture

Enterprise Architecture is Dead - LongLive En te rp r i s e Arch i t ec tu r e

IEEERecommended Practice forArchitectural Descriptionof Software Intensive Systems

IEEE Recommended Practice forArchitectural Description of Software IntensiveSystems

Gartner Enterprise Architecture Framework:Evolution 2005

Proceedings of the 1994Computer Personnel Research Conference onReinventing IS

Business Strategy Defines EnterpriseArchitecture Value

Gartner Clarifies the Definition of theTerm ‘Enterprise Architecture’

MIS Quarterly Executive

MIS Quarterly Executive,7(2): 99-112

Competing in the Information Age -Align in the Sand

Informat ion Sys temMethodologies

South African Journal of BusinessManagement

Organisation Science

Resource Book in Macro Organizational Behaviour

Federal Enterprise Architecture Program EAAssessment Framework 2.0.

nd

OMB. 2006. . [Online]http://www.whitehouse.gov/omb/assets/ fea_docs/FEA_Practice_Guidance_Nov_2007.pdf. [Accessed8 June 2009.]

OMB. 2007.[Onl ine] ht tp : / /

www.whitehouse.gov/omb/assets/fea_docs/FEA_CRM_v23_Final_Oct_2007_Revised.pdf. [Accessed9 June 2009.]

O’Rourke, C., Fishman, N., and Selkow, W. 2003.

. Boston: Thomson Course Technology.

Patton, M.Q. 2002.(3 ed.). California: Sage.

Plazaola, L., Flores, J., Silva, E., Vargas, N., and Ekstedt,M. 2007. An approach to associate strategicBusiness-IT alignment assessment to EnterpriseArchitecture. In:

. USA: Stevens Institute of TechnologyCampus.

Robertson, B. 2005.

. ID Number: G00134007.USA: Gartner Research.

Ross, J.W., Weill, P., and Robertson, D.C. 2006.

. Boston: Harvard BusinessSchool Press.

Rosser, B. 2004.. ID Number: G00123412. USA: Gartner

Research.

Schekkerman, J. 2004.(2 ed.).

Victoria: Trafford Publishing.

Schekkerman, J. 2006.

. [Online] http://enterprise-architecture.info/EA_Survey_2006.htm. [Accessed6 November 2007.]

Sessions, R. 2007.. [Online]

http://www.objectwatch.com/whitepapers/4EAComparison.pdf. [Accessed 9 June 2009.]

Theuerkorn, F. 2005.. NewYork:Auerbach Publications.

The Open Group. 2009.. [Online] https://www.opengroup.org/online-

pubs. [Accessed 1 June 2009.]

The Open Group SOA Working Group. 2007.. [On l ine ]

http://www.opengroup.org/onlinepubs/7699929599/toc.pdf. [Accessed 1 June 2009.]

Wagter, R., van den Berg, M., Luijpers, J., and vanSteenberg, M. 2005.

. New Jersey:John Wiley and Sons, Inc. Wegmann, A. 2002.

FEA Practice Guidance

FEA Consolidated Reference ModelDocument Vers ion 2.3 .

Enterprise Architecture using the ZachmanFramework

Qualitative Research and EvaluationMethods

Conference on Systems EngineeringResearch

Architecting the TechnologyViewpoint Requires Defining a Service-orientedInfrastructure Strategy

EnterpriseArchitecture as Strategy: Creating a Foundation forBusiness Execution

Sell the Value of Architecture to theBusiness

How to Survive in the Jungle ofEnterprise Architecture Frameworks

Enterprise Architecture Survey2006, Institute for Enterprise ArchitectureDevelopments (IFEAD)

A Comparison of the Top FourEnterprise Architecture Methodologies

Lightweight EnterpriseArchitectures

TOGAF Version 9.0, EnterpriseEdition

ServiceOr ien ted Arch i t ec tu re (SOA)

Dynamic EnterpriseArchitecture - How to Make it Work

rd

nd

28

The Systemic Enterprise Architecture Methodology(SEAM): Business and IT Alignment forCompetitiveness. Technical Report, EPFL/I&C/No.200265. Lausanne: LAMS / EPFL.

Wegmann, A., Regev, G., and Loison, B. 2005. Businessand IT alignment with SEAM. In

. [Online] http:/ /lamswww.epfl.ch. [Accessed 2 July 2009.]

Whitten J.L. and Bentley L.D. 2007.(7 ed.). New York:

McGraw-Hill / Irwin. Willis, T. 2008. EnterpriseArchitecture Workshop Notes, 1-46. Pretoria:Gartner Research.

Winter, R., and Fischer, R. 2007. Essential layers,artefacts, and dependencies of EnterpriseArchitecture. ,3(2): 7-18.

Zachman, J.A. 1987.Aframework for information systemsarchitecture. , 26(3): 276-292.

Zachman, J.A. 1996..

[Online] http http://www.aeablogs.org/eakd/files/The_Fram work_for_EA_Background_Description_and_Utility.pdf. [Accessed 9 June2009.]

Zachman, J.A. 2009.

. [Online]http://zachmaninternational.com/ index.php/home-article/15#maincol. [Accessed 19 November 2009.]

REBNITAWorkshop, 14 International RequirementEngineering Conference

System Analysis andDesign for the Global Enterprise

Journal of Enterprise Architecture

IBM Systems Journal

The Framework for EnterpriseArchitecture: Background, Description and Utility

e

The Zachman Framework forEnterprise Architecture™: A Primer for EnterpriseEngineering and Manufacturing

th

th

29

All correspondence should be addressed to: Mrs Marné de Vries, Department of Industrial and Systems Engineering, University of Pretoria,marne.devries@up.ac.za

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.