Management Dynamics Volume 19 No.

2, 2010

17

A framework for understanding and comparing Enterprise Architecture models

Marn de Vries
University of Pretoria

ABSTRACT The different worlds of business and Information Technology (IT), and the necessity for their alignment to create business effectiveness and efficiency, are the topics of this study. Enterprise Architecture (EA) has been proposed as a tool to create business-IT alignment. Several EA models and frameworks have been proposed, each based on a different value-creation paradigm. Few case studies, however, demonstrate the integrated use of these models and frameworks. This study addresses the need for a common reference for comparing alignment approaches in addressing businessIT alignment. More specifically, it analyses Enterprise Architecture (EA) frameworks and the components that are used to optimise business-IT alignment. Some common patterns are identified and re-packaged as part of a proposed business-IT alignment framework (BIAF). The conceptual BIAF components are used to demonstrate the interpretation of the framework for four prominent models: the Zachman Framework. the Open Group Architecture Framework (TOGAF), the Federal Enterprise Architecture (FEA), and the Gartner Enterprise Architecture Framework (GEAF). The BIAF forms the foundation of the case-study approach to research in business-IT alignment in this study, and offers a framework for analysing business-IT alignment in a single organisation. The study also provides a common reference for cross-case business-IT alignment analyses for industry-related organisations. INTRODUCTION The current information systems in wide use are becoming increasingly complex. This complexity is primarily due to the growing demand for information systems and IT

infrastructures to support multiple business functions. As a result, some organisations may require new strategies for governing and evolving their complex information system landscapes, which include IT infrastructure, in-house systems, and commercial-off-the shelf (COTS) products. One requirement is that governance strategies are needed to ensure information system agility in supporting rapid business changes. Enterprise Architecture (EA) has emerged as a tool for systematic, holistic planning and decision-making for the operation and evolution of an enterprises business and IT systems. EA, in particular, has received attention in IT circles, and several value propositions have emerged, including using EA to control costs; the optimisation of IT expenditure; and controlling/ governing IT capital planning, information system development/implementation, and security. In contrast with the cost and consolidation focus of many IT managers, EA practitioners and business managers started to realise the potential of using EA as a tool to create business-IT alignment (surveys by Schekkerman, 2006; Matthee, Tobin and Van der Merwe, 2007; and case study by Plazaola et al., 2007). According to the 2007 survey by Luftman and Kempaiah (2008), IT and business alignment and attracting, developing, and retaining IT professionals have consistently been the major IT management concerns since 1994. Business-IT alignment has been an important challenge in both private and public/non-profit sectors since the early 1980s (Knoll and Jarnvenpaa, 1994). There is strong evidence of a link between business-IT strategy alignment and firm performance (Luftman and Kempaiah, 2007), business-IT alignment being defined by the alignment assessment approach of Luftman (2003). However, the attainability of a business-IT-aligned organisation is impeded by various factors. One of the main culprits is the fact that EA originated within the

18

Information and Communication Technology (ICT) environment. Most architecture efforts followed a bottomup approach, modelling the current technical layers (data, applications, and technology) with a few attempts to link these layers back to the process architectures, organisational structures, and roles in an organisation. Software architects primarily focused on efficiency/cost reductions due to application/data/technology standardisation and/or consolidation. These efforts rarely demonstrated links to the motivational aspects of a business vision, mission and goals, and business optimisation. In addition, architecture models mainly reflected the world of IT, where IT systems were believed to be complicated systems whose behaviour could be predicted by analysing the component interactions. Contrary to the analysis approach to understanding IT architectures, strategy and business architectures require a different paradigm for analysis and comprehension (Gharajedaghi, 2006). Organisations are typically complex, non-deterministic, social systems that involve humans and their unpredictable behaviour. In addition, strategic/business variables are interdependent rather than independent. Although it is possible to use mechanisms such as modelling languages and tools to create mechanical links between strategy/business architecture components and IT architecture components, these mechanisms do not address the behavioural nature of organisations. Some practitioners in the field of Business Architecture (BA) suggest that organisations follow a top-down approach in aligning business with IT. The top-down approach implies that one starts an EA analysis by examining the business strategies and architectures, then translating these into IT requirements. This approach places IT in a reactive mode, i.e. IT strategy and structures should be derived from organisational conditions. Business-IT alignment efforts then create a static fit rather than a dynamic fit (Knoll and Jarnvenpaa, 1994). Few organisations realise the potential value of creating the capability for organisational flexibility and agility, resulting in resistance when facing change. Organisations may also need to consider external fit as well as internal fit (Miller, 1992). Currently, supply chain management and applications partially cover this requirement. Business-IT alignment requires a combination of mechanisms to link the different worlds/paradigms of strategy/business and IT. EA needs to address the challenge of the interaction of complex systems with complicated systems (Wegmann, 2002). The strategy/ business and IT domains have an interactive effect (strategically and operationally) on one another, and could both be strategic drivers, especially for organisations that operate in information-intensive industries. Business-IT alignment mechanisms thus need to address the dynamic interaction between the worlds of strategy/business and IT.

OBJECTIVES OF THE STUDY Luftman and Kampaia (2007) point out that many organisations still face significant challenges in aligning business activities with IT. Although it is still an art form rather than a science (Wegman, 2002), it is believed that there is no silver bullet for aligning business activities with IT. There are various alignment theories, each with its own combination of alignment dimensions, mechanisms, and illustrative case studies. Yet there are very few case studies to demonstrate the integrated use of these theories. Today, many EA practitioners follow a lightweight and pragmatic approach to EA and business-IT alignment (Gartner, in Sessions, 2007; Theuerkorn, 2005; and Wagter et al., 2005). The purpose of this study is to introduce a framework to unpack business-IT alignment in terms of generic approaches, dimensions, mechanisms, and practices that are proposed by theoretical models to facilitate businessIT alignment. Whereas previous frameworks simply compared EA frameworks with one another (see Schekkerman, 2004), this framework could be used to compare different theoretical models in terms of their business-IT alignment. A FRAMEWORK FOR AN OPTIMAL BUSINESSIT ALIGNMENT Building the conceptual model Business-IT alignment is considered to be one of the key goals of EA. There are a large number of theoretical alignment models today, each based on a certain belief system, each with its own alignment focus and possible application to a specific industry or type of organisation. This study compares the different theoretical models with one another in terms of business-IT alignment. A combination of inductive and deductive reasoning was used to derive a business-IT alignment framework (BIAF). According to Charmaz (2006:188), induction is a type of reasoning that begins with the study of a range of individual cases and extrapolates patterns from them to form a conceptual category. This reasoning requires one to work back and forth between the themes and the data until one establishes a comprehensive set of themes (Creswell, 2007). In contrast, deductive reasoning stipulates analytic categories beforehand according to an existing framework (Patton, 2002). A bottom-up approach was used to analyse the content of various theoretical models, using inductive reasoning to formulate the main components of the BIAF. The conceptual business-IT alignment components were then used in a deductive way to demonstrate the interpretation of the framework for four prominent theoretical models.

19

A number of frameworks have been studied, including the Zachman Framework, the Extended Enterprise Architecture Framework (E2AF), the Enterprise Architecture Planning (EAP), the Federal Enterprise Architecture (FEA), the Open Group Architecture Framework (TOGAF), the Integrated Architecture Framework (IAF), the Dynamic Architecture (DYA), the Generalised Enterprise Reference Architecture and Methodology (GERAM) , the Gartner Enterprise Architecture Framework (GEAF), and the Enterprise Architecture Cube (The Open Group, 2009; Gartner, 2008a; Gartner, 2008b; Capgemini, 2008; OMB, 2007; OMB, 2005; Wagter et al., 2005; Bittler and Kreizman, 2005; Bernard, 2005; Schekkerman, 2004; ORourke et al., 2003; GERAM, 1999; Zachman, 1996; and Zachman, 1987). Business-IT alignment Alignment endeavours/programmes/projects are usually founded on defendable value propositions. These value propositions are based on certain belief systems about value-creation in an organisation and the capability of marketing the propositions to the owners/funding parties

of the organisation. With reference to Figure 1, the BIAF starts with the foundation part (alignment belief/ paradigm of creating value), which determines the business-IT alignment approaches with reference to the other BIAF parts. A selection of alignment mechanisms and practices (e.g. methodologies, processes, methods, tools, governance structures) is required to facilitate change/evolution to realign business with IT. The alignment mechanisms and practices are also related to one or more BIAF dimensions. The framework contains three key alignment dimensions, represented by three axes in Figure 1. Architecture abstraction layers; Perspective/viewpoint; and Organising scope.

The dimensions part of Figure 1 provides the context of alignment, answering the questions, What needs to be aligned? and From which perspective?. The alignment mechanisms and practices part provides the means for alignment.

FIGURE 1 THE BUSINESS-IT ALIGNMENT FRAMEWORK (BIAF)

Government Industry
Project A Project C Corporate BU 1 BU 3 BU 2 Organising Scope BU n
Pe c pe e tiv s p iew /V

Competitors Partners

Customers Suppliers

Program 1 Project B
oin ts

rs

Architectural Abstraction Layer

Business & Strategy

Information Technology

Al

igm ra d a p e ef/ lu eli g va b nt tin m e re a ign c

of

Alignment Mechanisms and Practices

20

In addition to the aforementioned three dimensions, one can debate the inclusion of other dimensions. Some EA framework designers, for instance, include a dimension of generality (e.g. generic level, partial level, and particular level in the GERA, which is similar to the TOGAF use of an architecture continuum). The architecture continuum provides a continuum of generic-to-specific architectures, such as foundation architectures, common systems architectures, industry architectures, and organisation architectures. This study incorporates other dimensions as mechanisms with respect to the main BIAF dimensions. The alignment mechanisms and practices may be seen as any method or means (e.g. a way of partitioning, or a tool) or activity that may be used to create a business-IT alignment capability and contribute to business-IT alignment at different architectural abstraction layers, for different stakeholder perspectives/viewpoints, and across the organising scope (e.g. business units, programmes, and projects) of the organisation. The alignment mechanisms and practices (the slice across three dimensions in Figure 1) form the heart of the BIAF. The capability itself, and the way in which these mechanisms and practices are used or implemented, affect the success of business-IT alignment endeavours in a socio-technical organisation. The organising scope dimension also reveals extensions at the top of the cube (see Figure 1). Alignment endeavours may thus involve the organisation, or may be extended to external parties such as suppliers, partners, customers, government, industry, or competitors. The individual parts of the alignment framework are as follows: Alignment belief/paradigm of creating value Business-IT alignment practitioners or researchers provide definitions that convey their belief/paradigm about business-IT alignment and its relationship to valuecreation. Luftman and Kempaiah (2008: 102) believe that business-IT alignment refers to how business and IT are integrated, in harmony, converged, linked, fused, synthesized. Wegmann (2005: 1) believes that business-IT alignment is the correspondence between a set of components. Nadler and Tushman (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 the needs, demands, goals, objectives, and/or structure of another component. Enterprise Architecture (EA) has emerged as a new discipline that has the potential of aligning business with IT. The following themes emerge from various EA definitions in terms of its purpose and means of creating business-IT alignment.

Some believe that EA needs to provide an aggregate view or a blueprint for directing the organisation in terms of required high-level processes and IT capabilities (Winter and Fischer, 2007; Ross, Weill and Robertson, 2006; Boar, 1999 ). According to ANSI/IEEE Std 1471-2000, architecture needs to create a systems view - the fundamental organisation of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution (IEEE, 2000). The components (in different architectural abstraction layers), their interaction and interrelationships, should be described in a consistent way. This should ensure holistic solutions in terms of the solution components within 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). Gartner (Willis, 2008:7) believes that EA is about the continuous process of transformation from a current architecture to a future architecture translating business vision and strategy into effective enterprise change (also see Gartner, in Lapkin, 2008; Bernard, 2005; Schekkerman, 2004). Another prominent theme is governance - that is, key principles that are required to govern the design and evolution of information systems, which impact various management areas such as maintenance, compliance, and risk management (The Open Group, 2009; Willis, 2008; Gartner, in Lapkin, 2008; Winter and Fischer, 2007; Theuerkorn, 2005; Wagter et al., 2005 ).

Although the abovementioned definitions reveal some of the value-creation means, EA practitioners still need to demonstrate value to businesses in terms of bottom-line results. An effective value-creating strategy is to demonstrate how EA will be used to address certain organisational pain-points. Many EA practitioners use EA to demonstrate cost reductions through process and information system consolidations (Rosser, 2004). Today the focus of value-creation has shifted to incorporate both efficiency and effectiveness (Lapkin, 2005; Rosser, 2004; Buchanan, 2002). Architecture abstraction layer dimension The architecture abstraction dimension provides the means for creating logical separations between different domains of knowledge, also referred to as architecture abstraction layers. These layers provide a starting point for defining an architecture metamodel. The metamodel describes in a structured way how and with what the architecture will be described for a specific organisation (The Open Group, 2009).

21

The literature reveals many different abstraction layers that may be linked to EA definitions, methodologies, and frameworks. For example, Winter and Fischer (2007) have identified five levels: business architecture, process architecture, integration architecture (e.g. enterprise services), software architecture (e.g. software services and data structures), and technology/infrastructure architecture. The Open Group (2009) defines slightly different architectural layers as part of TOGAF: business architecture, information system architecture (which includes application architecture and data architecture), and technology architecture. Zachman (1987), the father of EA, defines a different set of abstraction layers namely data, function, network, people, time, and motivation. Two main categories of abstraction layers emerge from this review: Business and Strategy, and Information Technology, which encapsulate more detailed abstraction layers. The abstraction layers may be interpreted as follows: Business and Strategy layer: This layer is defined in accordance with Gharadjedaghis (2006) approach in understanding organisational complexities. This approach requires an understanding of the whole in terms of structure, function, and process at the same time, in the organisational purpose and environment or context. The constructs (structure, function, and process) are interdependent, and form a circular relationship. A preconceived notion of the whole (and its purpose) is used as a starting point for analysing organisational complexities. Several iterations may be required to validate original assumptions about structure, function, and process, which may lead to a re-conceptualisation of the constructs. The Information Technology abstraction layer may consist of several technical layers that differ substantially among frameworks. As an example, one could partition this category into three layers:

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 (working system). Other frameworks inspired by Zachman include a subset of these. The IAF includes only the first four viewpoints (Capgemini, 2008). The E2AF relates to the first four Zachman viewpoints, adding the environmental and transformational viewpoints. Perspectives/viewpoints may be related to different abstraction layers to provide distinct views on the system. According to Hilliard (2007), the Zachman framework describes 36 views (six abstraction layers x six viewpoints). Viewpoints that do not necessarily relate to specific abstraction layers may also be required to convey the concerns of certain stakeholder groups. The E2AF, for instance, highlights governance, security, and privacy viewpoints; IAF emphasises security and governance (Schekkerman, 2004), and the EA Cube underlines security, workforce, and standards management (Bernard, 2005). The BIAF is not prescriptive about the viewpoints, but comments on the use of viewpoints in addressing the concerns of different stakeholders to enable business-IT alignment. Organising scope dimension The scope dimension is used to reflect the extent of alignment in terms of the organisation structural elements, such as business units or lines of business, departments, programmes, and projects. The named elements are used to define the boundaries for business-IT alignment endeavours, and directly influence the required EA responsibility framework mechanism (one of the mechanisms of the BIAF). The selection of appropriate structural elements for alignment is usually preceded by initial architecture work to set the intent and extent of business-IT alignment endeavours. According to the Open Group (2009), the Open Group Architecture Framework, Architecture Development Method (TOGAF, ADM), for instance, starts with a preliminary phase and EA vision phase to define alignment scope. Ross, Weill and Roberson (2006) propose the development of alignment scope based on the inherent alignment limitations of the organisational operating model. Alignment mechanisms and practices

The application level conveys the structure of specific applications, how they are designed, and how they interact with one another. The data level describes the logical data stores in the organisation, how they are organised and accessed. The technical level describes both hardware and software infrastructure that supports applications and their interactions.

Perspective/viewpoint dimension Perspectives/viewpoints are used to group the related concerns of certain stakeholders. These concerns are often related to certain life-cycle phases of enterprises/ information systems. These relationships have been highlighted in the GERA. Although IEEE 1741 does not prescribe a fixed set of viewpoints (Hilliard, 2007), most The selected set of mechanisms and practices are based on the alignment belief/paradigm of creating value and the supporting alignment strategy. The set of mechanisms serve as enablers of alignment and should combat inhibitors. Typically - found mechanisms and practices include the following:

22

Frameworks, languages, artefacts that may be prescribed to ensure alignment across various dimensions. Examples include the numerous EA frameworks that are found in the literature, such as the Zachman Framework, TOGAF, IAF, E2AF, PERA (Purdue Enterprise Reference Architecture), Computer Integrated Manufacturing Open System Architecture ( CIMOSA), Federal Enterprise Architecture Framework (FEAF), Joint Technical Architecture (JTA), and Department of Defense Architecture Framework (DODAF) . Languages may be associated with some of the frameworks. Examples are: Business Process Modelling Notation (BPMN), Integrated Definition Language (IDEF), Unified Modelling Language (UML), and Architecture of Integrated Information Systems (ARIS). Various artefacts may be produced during architecture work, defined to address the concerns of certain stakeholders, thus addressing certain viewpoints and architecture abstraction layers. This approach may also be supported by a specific modelling language; examples include process diagrams, organisation structure diagrams, use case models and class models. Methodologies, project/system development phases. A methodology is a recommended collection of philosophies, phases, procedures, rules, techniques, tools, documentation, management, and training for developers (Maddison, 1983). Examples include architecture development methodologies such as TOGAF, ADM, as well as system development methodologies such as Structured Systems Analysis and Design Method (SSADM), Rational Unified Process (RUP) and James Martins Rapid Application Development (JMRAD). Many of the methodologies also include development phases. TOGAF Architecture Development Method (ADM), for instance, includes nine sequential and/or iterative phases. Policies, processes and practices for different existing management areas, such as programme, project, performance, governance, transformation, financial, service, risk, resource, communications, quality, supplier, configuration, and security. EA practitioners emphasise IT governance as a very prominent management area within EA (the Open Group, 2009; Ross, Weill and Robertson, 2006; Schekkerman, 2004). Control Objectives for Information and related Technology (COBIT) is a set of best practices for IT management, and IT Infrastructure Library (ITIL) is a set of best practices for IT service management.Another area that receives considerable attention in EA models is that of transformation: transformation roadmaps and practices are common to various frameworks such as IAF and GERAM.

Analyses (e.g. gaps/impact/dependency). This mechanism is directly linked to architecture work that is performed to map out components and relationships between components. The purpose is to use the analyses results to identify performance gaps or gaps in required future architecture. These analyses could be change drivers, guiding decision-making related to the evolution of architectures (see Dunsire et al., 2005). Responsibility/capability frameworks (also with the extended enterprise). This mechanism ensures that the appropriate organisation structures, processes, roles, responsibilities, and skills are implemented to support the alignment endeavours. Architecture capability may also be measured using various maturity frameworks e.g. the Architecture Capability Maturity Model (ACMM) developed by the US Department of Commerce (the Open Group, 2009), the Federal Enterprise Architecture Program EA Assessment Framework 2.0 (OMB, 2005), and the Strategic Alignment Maturity Model (SAM) of Luftman, used to indicate IT-business alignment maturity (Luftman and Kempaiah, 2007). Reference models and standards. These include generic models that may be used to quick-start architecture efforts, optimise certain processes, and/or ensure integration across architecture abstraction layers. Examples include GERA SupplyChain Operations Reference model (SCOR), Value Chain Operations Reference (VCOR), Capability Maturity Model Integration (CMMI), and enhanced Telecom Operations Map (e-TOM), for business processes in the telecommunications industry. Other examples include Technical Reference Model (TRM) and Reference Model for Integrated Information Infrastructure (III-RM), developed by the Open Group. Standards may be defined to ensure consistent design for specific architecture abstraction layers, viewpoints, and certain industries. An example is the Standards Information Base (SIB) of TOGAF, which is a catalogue of technology standards and specifications that are useful in implementing the services identified in the TRM. Software tools and/or guidance. This mechanism includes the wide variety of tools and tool sets that are available for designing various architecture artefacts. Examples include Systems Architect Family, ARIS Process Platform, Metis Product Family, and ABACUS. Tool comparisons or software decisionsupport instruments are also included under this mechanism category.

23

Alignment approaches Alignment is not explicitly modelled on the BIAF (Figure 1). The BIAF foundation, alignment belief/paradigm of creating value, directly influences the alignment approaches that are followed. An alignment approach is defined in terms of other BIAF parts, and determines the set of practices and mechanisms that are required in accordance with the selected approach. Some of the generic approaches are defined in terms of the following aspects: Versions of architecture The version of architecture refers to the version of the architecture blueprints with reference to the architecture abstraction layers and perspectives/viewpoints. EA models differ in their focus on creating current and/or future versions of architecture. Some theoretical models focus on building a complete blueprint of the current (as-is) architecture. These theoretical models analyse the current architectures before starting the future architectures. The Open Group in its Architecture Development Method (ADM), as well as the META groups EA process model, follow a systematic process in analysing current architectures in defining gaps (gap analysis) (Buchanan and Soley, 2002). This is based on the belief that a current architecture would highlight inefficiencies, reveal opportunities for centralisation, and lead to cost-cutting efforts. Other theoretical models focus on the future (to-be) architectures, while following a pragmatic approach in building a sub-set of as-is architectures, depending on the purpose of the architecture exercise (e.g. providing a baseline for developing a transition strategy). Detailed modelling is only conducted in a selected and highly pragmatic way (Gartner, in Lapkin, 2008; Buchanan and Soley, 2002), based on the principle of just enough architecture, just in time. Starting point and focus of architecture Most models propose either a top-down or a bottom-up approach in developing the architectural abstraction layers. Some theoretical models start at the business architecture level (top level), and work towards the technical architecture layers (bottom levels). Examples include TOGAF Architecture Development Method (ADM) and the Gartner EA Process model. These models are based on the belief that EAneeds to add value in terms of the purpose of the organisation, and contribute towards organisational effectiveness, which is embedded in the business strategy and business architecture. Other models start architecting at the technology layers, attempting to link back to the business layers. This linkback approach is usually associated with the belief system

that alignment could be attained by simply building a very flexible IT infrastructure that would easily accommodate changes in the business layers. Service Oriented Architecture (SOA) projects may be based on this paradigm (Gartner, in Robertson, 2005). According to The Open Group SOA Working Group (2007: 9), a major benefit of SOA is that it delivers enterprise agility, by enabling rapid development and modification of the software that supports the business processes and hence makes it easier to change the business processes themselves. The dynamic nature of architecture components EA blueprints are often compared with the blueprints of a house. Zachman (1996) himself considered the usefulness of EA when observing the architecting effort required for a Boeing 747 aircraft (Zachman, 2009). However, the inherent design of an aircraft changes relatively slowly over time. Some EA theorists consider enterprise architectures to be somewhat static, which may lead to a considerable amount of effort in designing and maintaining architecture artefacts. Other theorists accept that many architectural components change frequently and require a unique approach in terms of design and implementation. The Open Group believes that the practice of open standards and boundaryless integration across departmental/divisional/organisational boundaries addresses the challenges of dynamic changes. Valuecreation is centred on creating maximum flexibility through design, thus creating the ability to change swiftly. However, alignment across the supply chain, integrating diverse databases and applications written in different languages, remains a challenge. Different integration languages partially address this challenge - e.g. Distributed Component Object Model ( DCOM ), Common Object Request Broker Architecture (CORBA), Enterprise JavaBeans, and Extensible Markup Language (XML). Object-orientated and service-orientated design approaches also attempt to ensure flexibility via looselycoupled components that could easily be re-used or assembled in a make-to-requirement fashion. Some approaches acknowledge the architecture design practices that create flexibility, but emphasise the practices that are required to employ architecture in an organisation to enable change (Wagter et al., 2005, and Gartner, in Bittler and Kreizman, 2005). Periodic versus continuous alignment EA models often reveal different paradigms regarding alignment frequency. Some models promote once-off alignment endeavours. The models are supported by the analysis of current and future architectures to identify gaps, which may lead to rip-and-replace efforts - e.g. Business Process Re-engineering (BPR) (Whitten and Bentley, 2007).

24

Other models address the top-down systematic alignment of business requirements with information system functionality and its supporting infrastructure - e.g. Business Process Management (BPM) (Whitten and Bentley, 2007). Most system development methodologies provide alignment methods to ensure alignment between system requirements and system designs. BUSINESS-IT ALIGNMENT THEORIES AND THE BIAF The BIAF provides a framework for discussing and understanding the different dimensions and mechanisms that are involved in current theoretical alignment models. A few prominent theories are reviewed and compared in order to demonstrate the use of the BIAF. Italics are used to emphasise reference to various BIAF dimensions. Table 1 provides a summary of the comparative results. The Zachman Enterprise Framework Zachman (1996) has developed the Zachman Enterprise Framework (six-by-six matrix) that provides a logical structure for classifying and organising the descriptive representations that are significant to the management of the enterprise and the development of enterprise systems (Zachman, 1996). The framework is used to address different perspectives/viewpoints (perspectives in Zachman terminology) and different architecture abstraction layers (aspects in Zachman terminology). The main purpose/value-creating paradigm is to bridge the gap between business people and IT people in communicating effectively. By using different perspectives 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, a planning tool, and a problem-solving tool (ORourke, Fishman and Selkow, 2003). The framework does not enforce the development of a certain version of architecture (current or future), nor does it prescribe the direction of architecture design (e.g. top-down or bottomup). The dynamic nature of the socio-technical organisation could be addressed if primitive models are created, updated and re-used as new requirements emerge. The framework is used primarily to ensure continuous alignment of business requirements with information system functionality and its supporting infrastructure. According to ORourke, Fishman and Selkow (2003), the framework also contains a third dimension (z-axis) to add certain integrated activities to produce the artefacts. The selection of these activities depends on the project team using the Zachman framework, and typically includes project management, project administration, configuration management, change management, version control, methodologies, standards, and principles.

The Zachman Enterprise Framework thus focuses on two BIAF dimensions: architecture abstraction layers and perspectives/viewpoints. Little guidance is given on the third BIAF dimension: scoping the EA effort in terms of structural entities. Other than providing a classification framework, the EA practitioner is not directed in terms of alignment mechanisms and practices to ensure the evolution from current to envisioned organisational architectures. The Zachman Enterprise Framework does allow for alignment of system requirements across different organisations (e.g. customers, suppliers, or partners). The Open GroupArchitecture Framework (TOGAF) TOGAF, owned by the Open Group, became best known for its Architecture Development Method (ADM), which may be categorised as an architectural process/ methodology, rather than an architectural framework. The Open Group believes that adherence to an iterative ADM, which includes a Requirements Management phase, would ensure continuous alignment between different architecture abstraction layers, addressing the dynamic nature of a socio-technical organisation. However, the gap analysis performed could also lead to periodic rip-and-replace initiatives. The methodology follows a top-down approach in terms of architecture development, and promotes the development of both current and future architectural artefacts. With regard to the BIAF architecture abstraction layer dimension, TOGAF divides an organisational architecture into four layers (business, application, data, and technology). Although a separate set of BIAF perspectives/viewpoints is not defined explicitly, TOGAF refers to the importance of defining different viewpoints and stakeholder concerns during some of the ADM phases. TOGAF provides guidance through architecture partitioning (Chapter 40 of TOGAF 9) with regard to the third BIAF dimension, i.e. on scoping EA effort with regard to the inherent organising structures of the organisation. The ADM primarily focuses on alignment within the boundaries of the organisation, rather than extending to external parties such as suppliers and partners. A rich set of alignment mechanisms and practices is provided, especially in terms of a methodology (the ADM), policies, processes and practices for certain management areas (e.g. architecture governance and risk management), a framework called the architecture metamodel, languages (e.g. ArchiMate), gap analyses between current and envisioned architectures, impact analyses, responsibility/capability frameworks (e.g. guidance on governance frameworks, architecture maturity, and architecture skills), reference models (e.g. the III-RM), and standards (e.g. the SIB).

25

The Federal EnterpriseArchitecture (FEA) The FEA evolved from the Federal Enterprise Architecture Framework (FEAF) as the latest attempt made by the US government to unite their agencies and functions under a common EA. The FEA Program Management Office (FEAPMO) believes that FEA provides the Office of Management and Budget (OMG) and federal agencies with a common language and framework to describe and analyse IT investments, enhance collaboration and ultimately transform the federal government (OMB, 2007: 4). FEA has been developed for a specific enterprise, namely government, and not for private enterprises. Segment architecture development is triggered by both top-down (strategic) and bottom-up (tactical) drivers. In terms of architecture versions, architects need to understand both the current versions of architecture and places where business stakeholders would like to make improvements. To address the dynamic changes on different architectural abstraction layers, EA work products are created and maintained to provide a shared view of the current and future state of each agency for each performance improvement lifecycle. Architecture work products (artefacts) are only created in an ad hoc fashion to answer high-priority business questions. The segment architecture development process includes a process called segment architecture maintenance that continually updates architectural change drivers and their impact on segment work products and the programme management plan. The approach mainly supports continuous improvement as defined by the performance improvement lifecycle of each agency (OMB, 2005). FEA fully supports the scoping BIAF dimension by dividing the US Federal Government agencies into multiple segments that could be classified either as business services or core mission area segments. Enterprise services are identified as cross-cutting services, spanning multiple segments. The classification scheme allows for the re-use of shared assets defined at an organisational level (e.g. data, business processes, investments, applications, and technologies) as well as aligning segment architectures with organisational business strategies, mandates, standards, and performance measures. Alignment extends the organisational boundaries, by defining areas of collaboration and commonality with government and industry partners. In terms of the other BIAF dimensions, FEA uses the scoping dimension as a starting point to highlight relationships with perspectives/viewpoints and architectural abstraction layers. FEA defines four architectural abstraction layers : business, data, application, and technology. Although no formal taxonomy of perspectives/viewpoints is defined (OMB, 2006), FEApractices do refer to different stakeholders.

Various alignment mechanisms and practices are defined: the framework (FEA); artefacts (e.g. description of segment architecture work products, standard work product content and formats); methodologies (e.g. the segment architecture development process) and project development phases (e.g. performance improvement lifecycle); policies, processes and practices (e.g. performance measurement practices required during the performance improvement lifecycle, and EA governance processes); gap and impact analyses; responsibility frameworks (e.g. Integrated Program Team [IPT] members associated with segment architecture development and their role in the segment architecture development process); and reference models used to facilitate cross-agency analysis and the identification of duplicate investments, gaps, and opportunities for collaboration within and across agencies (e.g. performance reference model, business reference model, service component reference model, technical reference model, and data reference model). The Gartner Enterprise Architecture Method (GEAM) Gartner, an IT research and consulting organisation, developed the GEAM that consists of a Gartner EA process model and a Gartner EA framework. The Gartner EA process model represents key characteristics and a synthesis of best practices for developing and maintaining an EA, while the Gartner EA framework articulates the relationships between enterprise business architecture (EBA), enterprise information architecture (EIA), enterprise technical architecture (ETA), and their synthesis with enterprise solutions architecture (ESA). The Gartner EA process model declares the future state of EA to be the heart of the entire process, which should be developed before the current state EA. The list of prioritised futurestate initiatives and investments guides the scoping of current-state documentation architecture efforts produce just enough artefacts just in time. Linked to the futurestate approach, Gartner follows a top-down strategy by translating business strategy into a set of prescriptive guides to be used by the organisation in projects that implement change. The Gartner EA process model addresses the dynamic internal and external environmental conditions that will affect the organisations future state via change forecasts for the tactical and strategic planning horizons. The process model is a multiphase, iterative, and nonlinear model that supports continuous alignment. Periodic re-alignment initiatives could also result from gap analyses (Gartner, in Bittler and Kreizman, 2005). In terms of BIAF dimensions, Gartner defines three primary architecture abstraction layers (viewpoints in Gartner terminology): enterprise business architecture (EBA), enterprise information architecture (EIA), and enterprise technology architecture (ETA). Each viewpoint represents the concerns central to a specific set of stakeholders. In addition, they define an enterprise

26

TABLE 1 SUMMARY OF FRAMEWORK COMPARISON RESULTS

BIAF Parts Approaches Versions of architecture Starting point of architecture Current / Future / Non-prescriptive Top-down / Bottom-up / Non-prescriptive NP NP Primitive Models NP C&F TD C&F TD / BU Segment Architecture Maintenance C F TD Iterative Process Model P&C Qualifier Zachman TOGAF 9 FEA GEAM

Addressing dynamic nature of components Periodic or continuous Key dimensions Abstraction layers Business and strategy Information technology Pre-defined viewpoints Internal and external organising scope Internal External Mechanisms and practices Frameworks, languages, artefacts Policies, processes and practices Analyses (e.g. gaps / impact / dependency) Responsibility / capability frameworks Reference models and standards Software tools and / or guidance

Main mechanism used Periodic / continuous / Non-prescriptive

Iterative ADM P&C

Explicitly Defined (Yes / No) Explicitly Defined (Yes / No) Explicitly Defined (Yes / No) Omits / Allows / Faciliates Omits / Allows / Faciliates Articulated (Yes / No / Limited) Articulated (Yes / No / Limited) Articulated (Yes / No / Limited) Articulated (Yes / No / Limited) Articulated (Yes / No / Limited) Articulated (Yes / No / Limited)

Y Y Y A A Y N N N N N N

Y Y N F A L Y Y Y Y Y Y

Y Y Y F F Y Y Y Y Y Y N

Y Y Y A A L Y Y L L N N

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

solution architecture framework (ESAF), which combines and reconciles the requirements, principles and models of intersecting stakeholder-specific viewpoints within the three primary viewpoints into a set of architectural descriptions that can be used to generate the entire portfolio of enterprise solutions (Gartner, in James et al ., 2005). Gartner also specifies consistent perspectives/viewpoints that should be applied to each abstraction layer. These include a business context, and a conceptual, a logical, and an implementation viewpoint (Gartner, in James et al., 2005). The Gartner Enterprise Architecture Framework does not scope EA effort with regard to the inherent organising structures of the organisation 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 EAprocess model); limited guidance on analyses (gaps/impact/ dependency); and responsibility/capability frameworks (Gartner, in Bittler and Kreizman, 2005).

CONCLUSIONS As a discipline, EA has the potential to re-align business with IT to improve both business effectiveness and efficiency. Although a number of theoretical models do exist, few case studies demonstrate the different approaches advocated in the various theoretical models. The vast number of strategies and theoretical models that are used also inhibit business-IT alignment comparisons between organisations - in other words, cross-case studies. Various theoretical models address the alignment dimensions and the dynamic interaction between the different worlds of strategy/business and IT, using different mechanisms and practices. The Zachman approach advocates the use of primitive models that need to be created, updated and re-used as new requirements emerge. The Open Group proposes an iterative ADM, which includes a Requirements Management phase, to address the dynamic interaction of different architecture components. The FEA uses the segment architecture

27

development process, which includes a process called segment architecture maintenance, to continually update architectural change drivers and their impact on segment work products and the programme management plan. Finally, GEAM uses a multiphase, iterative, and nonlinear process model to address the dynamic internal and external environmental conditions that will affect the organisations future state via change forecasts for the tactical and strategic planning horizons. The author embarked on follow-up research to consider the effectiveness of these mechanisms in addressing the interaction between complex systems with complicated systems. This study has proposed a generic business-IT alignment framework (BIAF) to comprehend and compare different alignment beliefs/value-creation paradigms, dimensions, practices, and mechanisms that are employed by current theoretical models to facilitate business-IT alignment. The usefulness of the BIAF was demonstrated by comparing four prominent theoretical models. Using the BIAF as a common framework for alignment, one could combine and adapt current models, their mechanisms and practices, to address the interaction between complex systems and complicated systems more effectively. LIMITATIONS AND RECOMMENDATIONS FOR FUTURE RESEARCH The study intended to make a contribution to the body of knowledge on Enterprise Architecture. The main purpose was to demonstrate how different models attempt to address Business-IT alignment. The study was based on inductive reasoning, analysing the content of various theoretical models, to formulate the main components of the BIAF. The conceptual business-IT alignment components were then used in a deductive way to demonstrate the interpretation of the framework for four prominent theoretical models. Additional research could be done to validate the BIAF components by analysing case studies that used different theoretical models or a combination of theoretical models. These efforts may lead to further refinements of the BIAF. Although the various theoretical models have been discussed to address the alignment dimensions and the dynamic interaction between the different worlds of strategy/business and IT, follow-up research is required to measure the effectiveness of these mechanisms in addressing the interaction between complex systems and complicated systems. MANAGERIAL IMPLICATIONS The studys findings are useful from both a theoretical and managerial perspective. According to the 2007 survey by Luftman and Kempaiah (2008), IT and business alignment and attracting, developing, and retaining IT professionals have consistently been the major IT

management concerns since 1994. Although several EA theoretical models exist to promote organisation-wide business-IT alignment, few case studies demonstrate the value of different theoretical models. In addition, comparative analyses on the success of using these models and how the different mechanisms and practices contributed to enhanced and dynamic business-IT alignment are not available. The BIAF could be used as a foundation for doing comparative analyses that will provide new insight into the success of EA models due to certain contributing mechanisms and practices. IT management could consequently use these analyses to select and / or adapt their business-IT alignment approach. REFERENCES Bernard, S.A. 2005. An Introduction to Enterprise Architecture EA3 (2 nd ed.). Bloomington: AuthorHouse. Bittler, R.S. and Kreizman, G. 2005. Gartner Enterprise Architecture Process: Evolution 2005. ID Number: G00130849. USA: Gartner Research. Boar, B. H. 1999. Constructing Blueprints for Enterprise ITArchitecture. New York: J. Wiley. Buchanan, R.D. and Soley, R.M. 2002. Aligning Enterprise Architecture and IT Investments with Corporate Goals. Whitepaper. Needham: OMG and Meta Group. Capgemini. 2008. Integrated Architecture Framework. [Online] http://www.capgemini.com/services-andsolutions/technology/soa/soa-solutions/ ent_architecture/ iaf/. [Accessed 18 November 2009.] Chamaz, K. 2006. Constructing Grounded Theory. A Practical Guide through Qualitative Analysis. California: Sage. Creswell, J.W. 2007. Qualitative Inquiry and Research Design. Choosing Among Five Approaches (2nd ed.). California: Sage. Dunsire, K., ONeill, T., Denford, M., and Leaney, J. 2005. The ABACUS architectural approach to computerbased system and enterprise evolution. In: Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems: 662-69. USA: IEEE. EA Research Forum. 2009. Enterprise Architecture Definition . Working document. Pretoria: EAResearch Forum. Gartner. 2008a. Develop solution architectures and the enterprise solution architecture. In: Gartner Summit, November 2008 4. USA: Gartner Research. Gartner 2008b. Develop the business context. In: Gartner Summit, November 2008 4. USA: Gartner Research. GERAM. 1999. Generalised Enterprise Reference Architecture and Methodology, Version 1.6.3. [Online]http://hobbit.ict.griffith.edu.au/~bernus/task force/geram/versions/geram1-6-3/v1.6.3.html. [Accessed 30 November 2009.]

28

Gharajedaghi, J. 2006. Systems Thinking - Managing Chaos and Complexity: A Platform for Designing Business Architecture (2nd ed.). New York: Elsevier Inc. Handler, R. 2004. Enterprise Architecture is Dead - Long Live Enterprise Architecture. [Online] http://itmanagement.earthweb.com/columns/article. php/11079_3347711_1. [Accessed 5 Jan 2007.] Hilliard, R. 2007. All about IEEE Std 1471. In: IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 1471-2000). New York: IEEE Computer Society. IEEE. 2000. IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 1471-2000). New York: IEEE Computer Society. James, G.A., Handler, R.A., Lapkin, A., and Gall, N. 2005. Gartner Enterprise Architecture Framework: Evolution 2005. ID Number: G00130855. USA: Gartner Research. Knoll, K. and Jarvenpaa, S. 1994. Information Technology alignment or fit in highly turbulent environments: The concept of flexibility. In: Proceedings of the 1994 Computer Personnel Research Conference on Reinventing IS, 1-14.Alexandria. Lapkin, A. 2005. Business Strategy Defines Enterprise Architecture Value. ID Number: G00129604. USA: Gartner Research. Lapkin, A. 2008. Gartner Clarifies the Definition of the Term Enterprise Architecture . ID Number: G00156559. USA: Gartner Research. Luftman, J., and Kempaiah, R. 2007. An update on Business-IT alignment: A line has been drawn. MIS Quarterly Executive 6(3): 165-177. Luftman, J., and Kempaiah, R. 2008. Key issues for IT executives 2007. MIS Quarterly Executive, 7(2): 99-112. Luftman, J.N. 2003. Competing in the Information Age Align in the Sand. Oxford: Oxford University Press. Maddison, R.N. 1989. Information System Methodologies. Chichester: Wiley Heyden. Matthee, M.C., Tobin, P.K.J., and Van der Merwe, P. 2007. The status quo of Enterprise Architecture implementation in South African financial services companies. South African Journal of Business Management, 38(1): 11-23. Miller, D. 1992. Environmental fit versus internal fit organization. Organisation Science, 3(2): 159-178. Nadler, D. and Tushman, M.L. 1980. A congruence model for diagnosing organizational behaviour. In: Miles, R. Resource Book in Macro Organizational Behaviour: 30-49. Santa Clara CA: Goodyear. OMB. 2005. Federal Enterprise Architecture Program EA Assessment Framework 2.0. [Online] http:// www.cio.gov/documents/OMB_EA_Assessment_Fr amework_2.pdf. [Accessed 8 June 2009.]

OMB. 2006. FEA Practice Guidance . [Online] http://www.whitehouse.gov/omb/assets/ fea_docs/ FEA_Practice_Guidance_Nov_2007.pdf. [Accessed 8 June 2009.] OMB. 2007. FEA Consolidated Reference Model D o c u m e n t Ve r s i o n 2 . 3 . [ O n l i n e ] h t t p : / / www.whitehouse.gov/omb/assets/fea_docs/FEA_C RM_v23_Final_Oct_2007_Revised.pdf. [Accessed 9 June 2009.] ORourke, C., Fishman, N., and Selkow, W. 2003. Enterprise Architecture using the Zachman Framework. Boston: Thomson Course Technology. Patton, M.Q. 2002. Qualitative Research and Evaluation Methods (3rd ed.). California: Sage. Plazaola, L., Flores, J., Silva, E., Vargas, N., and Ekstedt, M. 2007. An approach to associate strategic Business-IT alignment assessment to Enterprise Architecture. In: Conference on Systems Engineering Research. USA: Stevens Institute of Technology Campus. Robertson, B. 2005. Architecting the Technology Viewpoint Requires Defining a Service-oriented Infrastructure Strategy. ID Number: G00134007. USA: Gartner Research. Ross, J.W., Weill, P., and Robertson, D.C. 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston: Harvard Business School Press. Rosser, B. 2004. Sell the Value of Architecture to the Business. ID Number: G00123412. USA: Gartner Research. Schekkerman, J. 2004. How to Survive in the Jungle of Enterprise Architecture Frameworks (2nd ed.). Victoria: Trafford Publishing. Schekkerman, J. 2006. Enterprise Architecture Survey 2006, Institute for Enterprise Architecture Developments (IFEAD). [Online] http://enterprisearchitecture.info/EA_Survey_2006.htm. [Accessed 6 November 2007.] Sessions, R. 2007. A Comparison of the Top Four Enterprise Architecture Methodologies. [Online] http://www.objectwatch.com/whitepapers/4EACom parison.pdf. [Accessed 9 June 2009.] Theuerkorn, F. 2005. Lightweight Enterprise Architectures. New York:Auerbach Publications. The Open Group. 2009. TOGAF Version 9.0, Enterprise Edition. [Online] https://www.opengroup.org/onlinepubs. [Accessed 1 June 2009.] The Open Group SOA Working Group. 2007. Service Oriented Architecture (SOA). [Online] http://www.opengroup.org/onlinepubs/7699929599/ toc.pdf. [Accessed 1 June 2009.] Wagter, R., van den Berg, M., Luijpers, J., and van Steenberg, M. 2005. Dynamic Enterprise Architecture - How to Make it Work. New Jersey: John Wiley and Sons, Inc. Wegmann, A. 2002.

29

The Systemic Enterprise Architecture Methodology (SEAM): Business and IT Alignment for Competitiveness. Technical Report, EPFL/I&C/ No.200265. Lausanne: LAMS / EPFL. Wegmann, A., Regev, G., and Loison, B. 2005. Business and IT alignment with SEAM. In REBNITA Workshop, 14 t h International Requirement Engineering Conference . [Online] http:// lamswww.epfl.ch. [Accessed 2 July 2009.] Whitten J.L. and Bentley L.D. 2007. System Analysis and Design for the Global Enterprise (7th ed.). New York: McGraw-Hill / Irwin. Willis, T. 2008. Enterprise Architecture Workshop Notes, 1-46. Pretoria: Gartner Research. Winter, R., and Fischer, R. 2007. Essential layers, artefacts, and dependencies of Enterprise Architecture. Journal of Enterprise Architecture, 3(2): 7-18. Zachman, J.A. 1987.Aframework for information systems architecture. IBM Systems Journal, 26(3): 276-292. Zachman, J.A. 1996. The Framework for Enterprise Architecture: Background, Description and Utility. [Online] http http://www.aeablogs.org/eakd/ files/The_Fram e work_for_EA_Background_ Description_and_Utility.pdf. [Accessed 9 June 2009.] Zachman, J.A. 2009. The Zachman Framework for Enterprise Architecture: A Primer for Enterprise Engineering and Manufacturing . [Online] http://zachmaninternational.com/ index.php/homearticle/15#maincol. [Accessed 19 November 2009.]

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.