Evolution Of Enterprise Architecture Business Essay

2.0 Introduction

Research is a continuous process. It builds on previous research work of earlier researchers, even as it also lays a foundation for future research. In light of this, we examine previous studies in the area of EA, which provides a background of EA best practice and its relationship to organisation change and Information Technology (IT) effectiveness. The literature review will guide the present study and provide a foundation for the gathering of relevant empirical material.

The next sub-section of this chapter provides us with the evolution of Enterprise Architecture. We develop an understanding of Enterprise Architecture in the sub-sequent sub-section, and examine the importance of Enterprise Architecture in the fourth sub-section. The fifth sub-section is the Enterprise Architecture framework, the sixth sub-section is the benefits of Enterprise Architecture, and the seventh sub-section highlights Architecture principles. The last sub-section is a discussion on what defines Best practice.

2.1 The Evolution of Enterprise Architecture

Enterprise Architecture evolution began as an idea in 1980 (Chen et al., 2008; Shah and Kourdi, 2007) and was embodied in John Zachman’s early EA framework. Thus, informing the reference to John Zachman, as the father of EA (Zachman, 1987; Pereira and Sousa 2005; Shah and Kourdi, 2007). The evolution of Enterprise architecture was to address the increasing complexity of IT systems and difficulty of delivering business value using those systems (Sessions, 2008).

Enterprise architecture is characterised by a framework that supports the alignment of business and IT strategy (Langenberg & Wegmann, 2004). It was first defined in 1992 by Zachman and Sowa, resulting in its reference as the Zachman framework. It was then referred to as Information System Architecture (Perko, 2008) but later changed in reference, to enterprise architecture in 1996 when Clinger-Cohen Act of the U.S. government directed all federal agencies to implement a holistic approach to incorporate IT to their business goals (Langenberg & Wegmann, 2004). Interest in adopting Enterprise architecture has increased as a result, as both government and private organisations have adopted it in business processes (Shah and Kourdi, 2007).

The importance of Enterprise Architecture to an organization is encompassed is the definition of Enterprise Architecture according to USA federal CIO Council.

“Enterprise Architecture is a strategic information asset base, which defines the business mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs”. USA Federal CIO Council

The body of knowledge on Enterprise Architecture is still young (Steenbergen, 2008). Despite this, it is considered as one of the important keys for addressing the ever-increasing complexity in modern enterprise (Shah & Kourdi, 2007).

Focus on EA has arisen from a number of different areas, one of which is the desire to align business and IT strategy in today’s growing competitive environment (Wang et al., 2008). Another impetus for the focus on EA is the strong desire of enterprises to reach their objective putting architectural thinking into practice, and creating a holistic architecture.

2.2 Towards a definition of Enterprise Architecture

An in-depth understanding of Enterprise Architecture is obtained if one considers its constituent words: “Enterprise” and “Architecture”. These are two words which while appearing simple enough to understand, require a thorough understanding in the context of Enterprise Architecture.

An enterprise as defined by Federal Chief Information Officer (CIO) Council (2001) is, “an organisation or cross organisational entity supporting a defined business scope and mission”. It consists of people, information, technologies that perform business functions, in a defined organisational structure that is distributed in multiple location which respond to internal and external events and provide specific services to its customers (Rood, 1994). In producing an output in the form of products and services, an enterprise as a whole moves through various activities in a cyclic form (Rood, 1994). This is referred to as the enterprise life cycle. It is dynamic and iterative due to changes over time owing to new business process, technology advancement, capabilities, maintenance, disposition and re-use of existing elements of the enterprise (CIO, 2001).

The definition of “architecture”, and more specifically in relation to enterprises or systems, is a lot more complicated. This is made all the more so, given that there exists no single agreed definition (Rood, 1994). Taking into account the general view of the composition of architecture itself, we are led to adopt the definition of Architecture according to ANSI/IEEE standard 1471-2000. This defines “architecture” as “the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution”. This can be viewed as the orderly arrangement of the components that makes up a system and the relationships of these components.

Enterprise Architecture has emerged from business and IT perspectives (Winter & Fischer, 2006). A broad range of EA definitions exist as observed from literatures reviewed. This though depends on the field within which enterprise architecture is defined. In cognisance of that fact, as argued by Rohloff, (2005) and, Janssen & Hjort-Madsen (2007), the various definitions of EA by both practitioners as well as researchers shows that there is no universal accepted definition.

While Rood (1994) defined EA as a “conceptual framework that describes how an enterprise is constructed by defining its primary components and the relationships among these components”, Ross et al. (2006, p.9) defines EA as the “organising logic for business processes and IT infrastructure reflecting the integration and standardisation requirements of the company’s operating model”.

A further definition of EA is provided by Sessions (2008, p.9) who defines EA as “a description of the goals of an organisation, how these goals are realised by business processes, and how these business processes can be better served through technology”. However, enterprise architecture is defined somewhat differently, by Wegmann, (2007); Pereira & Sousa, (2005); and Wang et al., (2008) who view Enterprise Architecture as a discipline whose purpose is to align IT and business strategy to achieve a competitive advantage. The foregoing analysis indicates that the definitions of EA emphasise EA as a framework and EA as a process for transforming an enterprise. EA thus consist of a framework which provides a structured holistic view of an enterprise used to manage and align IT with business strategy where IT is used to support the business operations.

2.4 Importance of EA in organisation

Increasing pace of information Technology has influenced the increased need for Enterprise Architecture. Zachman (1999) claims that adopting EA is the key to the survival of an enterprise due to the high rates of change and complexity in the world economy. An enterprise that aspires to achieve its vision must be able to identify its current or as-it state, and have a concrete plan on how to get to its target or to-be state. Without an appropriate communication method and tools, it can be challenging to communicate the vision of the enterprise. However, EA depicts an enterprise current state and aspired future state with visual models making communication much easier and faster. Enterprise Architecture plays an important role in an organization. It is critical to the survival and success of the organization, while enabling the organisation to achieve a right balance between IT efficiency and business innovation (Townson, 2008). Typically, EA helps to facilitate business success such as competitive advantage through the effective use of information management strategies and IT resources. Enterprise Architecture can be used by a company to organise and structure its enterprise infrastructure providing stakeholders and system architects appropriate architectural details (Shah and Kourdi, 2007).

EA may however be developed for a wide variety of reasons. CIO, (2001) & Jahani et al., (2010) enumerate a number of general reasons for EA. EA is developed for:

Alignment: to ensure that the implemented enterprise aligns with management’s intent.

Integration: the connectivity and interoperability of business rules, processes, information flow and interfaces are consistent across the organisation.

Convergence: pushing towards standardised IT portfolio based on Technical Reference Model (TRM). Thus, creating a common organisational language.

Change: facilitating and managing improvement in all aspects of the enterprise.

Another important reason to consider EA adoption is the need for an organisation to stay commitment to her long term goals. The agility of an enterprise is dependent on a long-term implementation strategy using EA while short-term implementation creates a temporary illusion of an agile enterprise (O’Rourke et al., 2003, 545). Therefore, EA is a mechanism to help her adopters remain focused on the achievement of long-term visions while providing a framework for managing everyday operational risks.

In order to respond to the constant changes in business needs, a stable platform is needed to support the enterprise operations (Ross et al., 2006). The traditional approach to building an information system, by purchasing applications specifically for a department or a unit area increases complexity, introduces redundancy and hinders the enterprise from growing. This according to Ross et al. (2006) is known as business silos. It is whereby individually the application functions effectively but when combine gives no foundation for execution of enterprise processes. However, the introduction of EA into an enterprise process is a holistic approach taken to address the organisation-wide application needs with a clear understanding of how each component is related to others both at the data, software and hardware levels of abstraction resulting to integrated silos architecture (Sessions, 2008).

2.5 Components of Enterprise Architecture

Enterprise Architecture is all about the elements that make up an enterprise and how these elements inter-relate. Enterprise Architecture frameworks contain a list of recommended standards and compliant products for designing information systems in terms of a set of building blocks and how these building blocks relate together (Shah and Kourdi 2007). It supports the integration of the business, system and technology architectures while aligning business and IT strategy (Shah and Kourdi 2007; Wang and Zhao 2009). The four architectural disciplines based on a hierarchical, multi-level systems theory approach that are commonly accepted as subsets of the overall enterprise architecture (CIO Council 1999; Wang and Zhao 2009):

Enterprise Strategy

Strategy

IT Strategy

Business Strategy

Enterprise Architecture

Business Architecture

Application Architecture

Planning

Technology Architecture

Information Architecture

Business Operating Environment and IT Infrastructure

Design and Deliver

Figure 1. Enterprise Architecture components (Wang & Zhao, 2009)

Business Architecture: it represents the fundamental structure of an organisation from the business strategy viewpoint such as goal systems, governance, key business process and organisation.

Application Architecture: it represents the fundamental structure of an enterprise that provides a blueprint of the individual application system to be deployed, their interaction with core business process.

Data (Information) Architecture: it represents the fundamental structure of the logical and physical data assets of the organisation and its data management resources.

Technology Architecture: it represents the fundamental structure of an enterprise that describes the hardware platforms and software infrastructure that support the applications.

Often used to denote the compound set of application, information and technology architectures is IT architecture. According to Ross et al (2006), IT architecture is defined as “the organising logic for data, applications and infrastructure, captured in a set of policies, relationships and technical choices to achieve desired business and technical standardisation and integration”. Thus, representing the business and IT structure of an enterprise is EA.

2.6 Enterprise Architecture Framework

EA frameworks provide common terminology and generic concepts which makes it easy for stakeholders to communicate without taken into consideration various languages (Shah and Kourdi 2007). They have been adopted by many organisations government agencies for operational use (Ross et al. 2006; Shah and Kourdi 2007). Two often cited architectural frameworks which are commonly considered a founding framework (Schekkerman, 2006) are The Open Group Architectural Framework (TOGAF), and The Zachman Framework are explained below. Other frameworks have been developed by customising an existing framework to meet the enterprise needs such as The Extended Enterprise Architecture Framework, Archimate and Federal Enterprise Architecture Framework (FEAF).

TOGAF – it was developed based on the Department of Defence’s Technical Architecture Framework for Information Management in 1995. The framework provides rules for governance, designing, developing and implementing an EA. Its main components are architecture capability framework, Architecture Development Method (ADM), Architecture Content Framework and Enterprise Continuum. The important part of TOGAF is the ADM which specifies the process of developing the architecture. However, it does not provide a set of architecture principles.

Zachman Framework – it is a framework that shows the interconnected relationship within an enterprise. It was published in 1987 by John Zachman (Zachman 1987). The framework is based on architecture and engineering principles. The framework represents two dimensions, the first dimension concerns the different perspectives of people involved in the architecture process which are: Planner, Owner, Designer, Builder, Subcontractor and User. The second dimension deals with the basic questions: what, how, where, who, when and why. Zachman framework presents comprehensive view of the actual processes of an enterprise which guides decision making, IT resources and architecture principles. However, it does not provide an avenue for practical application of the framework (Lankhorst et al., 2009) as much guidance for planning, implementation and maintenance of the architecture (Goethals, 2003).

2.7 Benefits of Enterprise Architecture

During the past few years, IT has not only affected ways in which organisation do business such as automating its processes, but has extended to how customers, stakeholders and regulatory bodies interact with the organisation (Drobik, 2002). However, Enterprise Architecture is faced with re-engineering of the whole organisation from all perspective such as users, systems, geographical location and mode of dispersion to improve the working processes in the organisation (Bass et al., 2003). Using EA properly, an enterprise can get significant business and IT benefits (CIO 2001; Shah and Kourdi, 2007; Townson, 2008):

It provides clear model of the organisations’ business, application, data and technology architecture, their dependencies and inter-relatedness. This will help the organisation to make business decisions based on holistic view instead as a stand-alone part.

Enterprises can increase their business values by aligning IT with their business strategy; it helps the organisation to unlock the power of information, unifying information silos that inhibit business processes.

EA ensures organisations invest in projects that are targeted towards their goals, objectives and visions. It identifies opportunities for reuse and integration which prevent inconsistent processes and information.

It provides an organisation with a planning process to better understand its business strategy which helps the organisation to respond faster to competitive pressures and deploy a higher quality faster.

EA identifies duplicate and overlapping processes, services, data hardware and software, traces high cost areas of IT assets in order to develop a fairer cost model and ensures compliance to legal and regulatory laws.

The goal of EA is to add business value to the organisation and not to only be used for the documentation of the processes, systems and information that exist in the organisation (Sessions, 2008). The alignment of business and information technology strategy is a key issue in an organisation based on the impact IT has in the overall organisation (Pereira and Sousa 2005). In such an organization EA provides the fundamental technology and process infrastructure (Shah and Kourdi 2007). IT develops the application, technology and data foundation necessary for the delivery of the needed integration and standardisation while business defines the strategies that use the capabilities that are in place (Ross et al, 2006). Thus, the integration of business strategy with IT objectives is not only an IT issue but an organisational concern (Van den Berg & Van Steenbergen, 2006; Ross et al., 2006).

Enterprise Architecture has been widely adopted by many private and government organisations to cope with ever-increasing complexity (Ross et al. 2006). It has been promoted as a key tool for transformation and modernisation of government institutions around the world (Hjort-Madsen and Pries-Heje, 2009). This ensures the proper use and optimisation of the organisations’ technical resources in other to reduce costs while increasing their strategic agility (Shah and Kourdi 2007). Wang and Zhao (2009) emphasises that EA is not just a technology map but a strategy for the entire enterprise. Organisations such as UPS, Toyota Motor Marketing Europe, Dow Chemical Company have adopted EA to strategic areas such as budget allocation, information sharing, performance measurement and component-based architecture (Ross et al. 2006; Shah and Kourdi 2007). In addition, EA is used as a management tool for aligning IT and business objectives with respect to the current and future vision of an enterprise (Shah and Kourdi, 2007). As a tool it helps stakeholders and business owners manage dynamic changes and challenges in a timely and cost effective way (Ross et al., 2006).

2.8 Architecture Principles

Principles are foundation based set of rules and behaviours used for governance. Architectural principles are fundamental requirements and practices believed to be of importance to an enterprise which are mapped to the organisations business strategy and IT vision. Architectural principles govern the EA process and implementation of architecture (CIO, 2001). Perks & Beveridge, (2003) noted that architectural principles act as umbrella for EA covering the information architecture, business architecture, application architecture and technology architecture. Conversely, principles that govern the EA process affect the development, maintenance and use of the EA. While the architectural principles for EA implementation provides guidance for making decision on the designing and development of information systems. However, architectural principles are refined to meet an organisation’s need (Perks & Beveridge, 2003). The figure below shows architectural principles that map enterprise’s IT vision and strategic plans.

IT Vision, Requirements and Practices

Business Needs

Strategic Plans

Principles

. EA

. Enterprise

Actions

Implications

EA Policies and Guidelines

. EA Development

. EA Use

. EA Maintenance

. EA Compliance

Systems Life Cycle

. Systems Migration

. Technology Insertion

. Dual Operations

. Deployment Plans

Capital Planning and Investment Control

. Project selection

. Project Control

. Project Evaluation

. Return on Investment

Figure 2. Role of Architecture Principles (CIO Council, 2001)

2.9 Best Practices

The term “Best Practice” (BP) is commonly used in the discourse of business and IS professionals (Wanger et al., 2006). BP can be defined as a method, technique, process or activity that is believed to be effective and efficient in delivering a particular outcome based on repeated procedures that have proven themselves overtime (Bogan et al., 1994, Burns, 2009). BP thus is a practical application of suggested practices, critical success factors and recommendation. The term BP can be viewed in different phenomena.

In the engineering and supplying field, it is a reference model or design which provides a blueprint for optimizing technical and organisational structures (Kondreddi, 2001). In contrast, from a manufacturers’ perspective it is in relation to competitive advantage for aspiring high level of service and revenue generation (Cortada, 1998). Regulators use Best Practice as a means to promote risk management for legal and regulatory compliance. However, it is argued that neither the proposal nor the analysis of best practice guidelines are very common topic in Information Systems literature (Wanger et al., 2006).

Nonetheless, benchmarking best practice offer reduction in cost and time of developing a project (O’Dell & Grayson, 1998) and organisations associated with best practice adoption boost their integrity and standing with their consumers (Dube & Renaghan, 1999). However, most BPs put forward by commercial vendors are not all based on investigative process but have suggested application of the practice to a real life environment. Best practice in IT context is a collection of practices that have proven to be effective when implemented in an organisation (Burrin et al., 2007). However, the use of best practice should be tailored appropriately to specific context of an organisation to enable EA effectiveness (CIO, 2001; Hjort-Madsen and Pries-Heje 2009; Wang & Zhou, 2009; Jahani et al., 2010).

The benefit of using EA best practices is broadly divided into three areas. EA best practice is of benefit to business. It provides greater agility and consistency, better decision making and ROI, and better information. In IT, EA best practice is beneficial for reducing technology diversity, support and project costs, while increasing reuse and operational stability. For the EA team, EA best practice is of extreme benefit. it provides stability, job satisfaction, opportunities for personal and professional growth (Lapkin,2007).

2.10 EA best practices

Use of best practice enhances the pace and the quality of the EA being developed (IAC, 2005). Several best practices have been proposed for an effective Enterprise Architecture. Within the research community, Ross et al. (2006) based on their study on EA in more than 200 enterprises proposed commitment to the business strategy, senior management involvement, architecture compliance, architecture built into project methodology, full-time EA team, one-page core diagram, experiment with synergistic businesses, EA guiding principles, implement one project at a time, Schekkerman (2004) proposed holistic in scope, collaboration based, alignment driven, value driven, dynamic environments, normative results and non-prescriptive and Jahani et al., (2010) proposed leadership styles, openness to communication, partnership between business and IT groups, autonomy of business groups, buiness linkage, senior management involvement, EA resources and holistic approach. With respect to government agencies, IAC (2005) recommend provide sponsorship, plan the EA program, develop a marketing and communication plan, develop EA and business metrics early, obtain organisational buy-in, identify the thought leader(s), tie the EA sequencing plan into the investment control process, manage EA change, conduct independent verification and validation. CIO (2001) propose obtain executive buy-in and support, establish management structure and control, enterprise architecture program activities and products, define the intended use of the architecture, define the scope of the architecture, determine the depth of the architecture, select appropriate EA products, evaluate and select a framework, select an EA toolset, develop a sequencing plan, use the EA, maintain the EA, continuously control and oversee the EA program.

Although terminologies may differ among respective authors, there is noted association in their interpretation. For example, business linkage has been associated with business driven (IIkevicius, 2008) and alignment driven (Lapkin, 2007), governance structure with architecture governance. Obtain executive buy-in and support means senior management commitment and involvement (TOGAF, 2010). While EA team competency is similar to EA resources (EA direction, 2007), which has further been associated with experienced team (IIkevicius, 2008).

While the above review is not exhaustive, it however references key Best Practices and provides an indication of common and emerging implemented BPs. With this in mind, we elected to proceed with the following best practice based: scope of the EA, executive support and sponsorship, EA flexibility, plan the EA program, develop effective communication plans, EA resource, business driven, use an appropriate framework, business driven, set up a measurement program, develop a sequencing plan and governance which is defined in more depth below.

2.10.1 Define the scope of EA

The architecture should address all aspects of the whole enterprise; which should be directly associated with the business structure, business activities, business process, information flows, standards, policies, information systems and infrastructure (Wang and Zhao, 2009). Thus, cooperative effort of all business and IT units across the entire organisation should be adopted. A clear understanding of what is within the scope of EA should be approved by stakeholders (CIO, 2001). In addition, a committee should be set up to govern the EA program. Schekkerman (2008) cautioned that most Enterprise Architecture effort does not include customer and key stakeholders because they are too enterprise focused which causes misaligned IT and business strategy, thus resulting to inability of the enterprise to gain competitive advantage and government effectiveness. Defining the scope helps to determine the needed resources required for build the architecture and level of skilled personnel for the analysis and designing of tasks involved.

2.10.2 Executive support and sponsorship

It is concerned with commitment and support from top level personnel of the enterprise such as board/executive management (IAC, 2003; Seppanen et al., 2009; Akkasi et al. 2008). Obtaining executive support ensures that the business will support EA decisions, the EA program can be marketed effectively, ways can be found to adjust tight budget which will speed up the development of the architecture (Van den Berg & Van Steenbergen, 2006; Jahani et al., 2010). It is suggested that a favourable environment should be created by business and IT managers to ensure architectural processes is granted enough fund, implementation time and other resources (Bussells, 2006). According to Ross et al., 2006, senior management should be able to describe their company’s EA not only funding or taking part in the planning stage. However, EA is a long term commitment which takes time and perseverance to enjoy its benefits (Kaisler et al., 2005). Management accountabilities and responsibilities must be well defined and sponsorship declaration from executive management should be gained (IAC, 2003) before the commencement of the EA program which should be repeated periodically throughout the duration of the program. Participation of senior executive team involves attending planning meeting, being a spokesperson for the EA effort and resource commitment. In addition to senior executive support, commitment from middle management should also be gained; this is to ensure that line managers understand, support and enforce the EA shared values across the enterprise so as to overcome passive resistance from lower level officers (Jahani et al., 2010). Jahani et al further explains that middle business managers often view architecture as a collection of rigid standards that will inhibit their flexibility and threaten their autonomy. Thus, it can be suggested that educating staff on how to respond to organisational changes, effective communication and introduction of behavioural change lever will diminish or mitigate opposition from middle management staff (Jahani et al., 2010).

2.10.3 Manage EA change

Even the most well planned projects will still require some changes as the project progresses. The flexibility of the EA to accommodate changes to the business drivers, technology, new opportunities and its environment helps an enterprise to respond effectively (Ross et al., 2006; Akkasi, et al. 2008). It is essential that changes that affect the four layers of EA which are business, data, application and technology should be given prompt attention. However, the proposed modification to the EA should be reviewed before it is been approved or rejected (IAC, 2003). Thus, a change or configuration plan should be in place in preparation for changes (Kaisler et al., 2005) providing transformation options that mitigate risk and other organisational constraints (Wang and Zhao 2009).

2.10.4 Plan the EA program

Planning the EA program is a foundation that focuses on the scope and objectives of the EA, needed resources to develop the architecture products, timeline for delivery to ensure a reasonable high probability of success (EA Directions, 2007). IAC (2003) suggested four planning activities which are establishing a management structure to maintain oversight of the EA process across leadership and management functions to monitor alignment with the goals, objectives and business strategy of the enterprise; specifying the EA scope to ensure that it covers the business and technology aspects, business and technology drivers relationship, scope and depth of the baseline, target and transition architecture; specify the EA framework products to meet the organisations’ requirements; selecting tools and EA support resources which is used to effectively develop, maintain and communicate the architecture.

2.10.5 Develop effective communication plans

Effective communication plan promotes the goals and benefit of EA efforts which is essential to the continued development and maintenance of the organisation’s EA (Lapkin 2007; TOG, 2010; Wang & Zhao, 2009). This keeps senior executive and business units continually informed of the progress, findings and future strategies (IAC, 2005). Furthermore, effective communication plans will promote awareness among users of EA and staff providing updates on latest architecture-related project development (Jahani et al.). Information can be communicated through intranet, web pages, electronic surveys, publishing, meetings, seminars and one-on-one discussion. Effectively communication helps to avoid ivory tower architecture (TOG, 2010; Lapkin 2007). CIO recommends that a primer be used to inform executive management and stakeholders of the EA strategies and plans. The primer expresses the vision for the enterprise and the role of EA in accomplishing that vision.

2.10.6 EA Resources

Implementation of Enterprise Architecture is expensive and complex (EA Direction, 2007); and poor execution will result into numerous problems for the organisation (Jahani et al., 2010). However, it is necessary to have personnel who understand the technical as well as the business needs of the enterprise to form the EA team (Rehkopf and Wybolt, 2003). The EA team should include personnel with excellent interpersonal skills, business knowledge, technology competencies, and managerial skills which are directly involved in developing EA and those who govern and use the EA such as the chief architect, chief information officer, project managers, infrastructure engineers and application developers (CIO, 2001). However, the success of the EA is dependent to a large extent on the credibility of EA staff which can only be gained over years (EA Direction, 2007; TOG, 2010). Furthermore, everyone using EA must understand its concepts, methodologies, tools and must be able to communicate effectively at all levels of business and IT (IBM, 2006; IIkevicius 2008). According to Lapkin (2007) Enterprise Architects must have enterprise perspective, must be able to create EA documents, manage EA processes and define EA governance. Further, the architect must act effectively as a visionary, translator, engineer/system designer, auditor and consultant (Rehkopf and Wybolt 2003). Therefore building an experienced EA team will involve investing on team members through trainings, motivating and retaining team members (Ross et al. 2006; IIkevicius 2008). Kaisler (2005) & Rehkopf and Wybolt (2003) suggested that the organisation should either train employees or hire contractors to transfer the knowledge. Rehkopf and Wybolt (2003) further discussed that best source of EA team members comes from within the organisation because they will have a stronger sense of ownership than hired consultants.

2.10.7 Business Driven

Is concerned with the extent to which any EA effort is linked to business strategy. The EA must be driven by key business goals of the enterprise (Lapkin, 2007; Van den Berg & Van Steenbergen, 2006; Schekkerman, 2008; Graves, 2008). An EA that has little or no connection with the enterprise business strategy will find it difficult to induce and sustain recommendation of significant investment so as to provide effective guidance for decision making (TOG, 2010). According to IBM Corporation, EA methodologies and tools must be business defined to ensure that the EA program is totally business driven (IIkevicius, 2008). Business driven can be measured by a business strategy document written in natural language which is relevant to the enterprise.

2.10.8 Use an appropriate framework

An agreed EA framework for defining IT processes must be agreed upon and should be integrated into the organisations practices (Kaisler et al. 2005; Akkasi et al. 2008; Xueying et al. 2008; Van den Berg & Van Steenbergen, 2006; TOG, 2010). It enables architect to represent the scope of EA, the boundaries shared with business units and to monitor the progress of the EA program (Van den Berg & Van Steenbergen, 2006). Frameworks manage, publish and use complex collection of inter-dependent building blocks to represent the architectural content (IBM, 2006). Most commonly, frameworks serve as a documentation and component specification tool and can also facilitate planning and problem solving (Shah and Kourdi 2007). Kaisler et al. 2005 explained further that each framework is unique but they all have the same principles and processes, therefore the appropriate framework should be used. Laplante and Costello 2006, suggested that before using any commercial framework or tool, the enterprise should verify that the framework is current and can accommodate the whole enterprise processes. The use of an EA framework ensures uniformity and standardization when migrating and integrating information systems (Jassen & Hjort_Madesen, 2007). CIO, (2005) suggested the use of existing framework which contain essential and supporting products or an in-house framework could be developed. However, the risk and cost implications of developing in-house framework should be considered against the risks of adopting publicly existing framework (CIO, 2005).

2.10.9 Set up a measurement program

A measurement system or scorecard should be created to monitor progress, underpin and reinforce achievement of EA objectives (IAC, 2003; NCC, 2005; Lapkin, 2008). This help to measure EA deliverables, determine its maturity compared to the best and common practice; and measure the direct impact of EA on business and IT (Lapkin, 2007; TOG, 2010). The measures and metric used must be in business terms and should be approved by stakeholders (NCC, 2005).

2.10.10 Develop EA

Starting small and growing EA slowly as opposed to modelling everything in sight increases the chances of its success (Kaisler et al. 2005; Lapkin, 2007; Akasi et al., 2009). To develop the EA, the current or “as-is” and the target or “to-be” state of the business and technology infrastructure should be described using a set of architectural tools; which is useful for developing a sequencing plan (CIO, 2001). This helps to measure future progress against the baseline. Developing a sequencing plan defines the strategy for moving from a baseline or “as-is” architecture to the target or “to-be” architecture. This will help the architecture focus on what is important to the business at present in order to deliver value early and often (Lapkin, 2007). CIO council describe baseline architecture as a comprehensive list of the enterprise software application, technology/hardware equipments and business processes. While the target architecture as a desired future state of the enterprise business functions, IT infrastructure and information needs. Furthermore, it is suggested that EA project should be developed in an evolutionary way through a series of releases; such that the implementation of each release builds on the previous ones which provide value to the enterprise and increase success rate (Wilbanks, 2008). In addition, while developing the EA a level of granularity should be agreed upon to avoid overrun in time, budget and dissatisfaction among stakeholders (TOG, 2010).

2.10.11 Governance

The architecture is directed by different stakeholders which require strong governace to address the challenges of communicating the EA artefacts in suitable ways and integrating the different views of the stakeholders consistently. EA governance processes involve policy development, strategic planning, risk management, and workforce management (Kailser et al., 2005) which must be well understood and followed by the architectural management team (Wang & Zhao, 2009). Creation of a governance structure for compliance process is essentail for a sucesseful EA program and should include senior management, business and IT representative (Kailser et al., 2005; Schekkerman, 2008). It comprises of two areas: governance of the architecture itself which are the management processes needed to define and maintain the architecture models and governance needed to ensure that the EA programs adhere to agreed policies, decisions, recommendations, contracts and guidelines (Xueying et al., 2008). Due to EA long-term development,a robust governance structures and processes is required for the EA program to be successful (Seppanenen, 2009). Furthermore suggested that an architecture management team which should contain stakeholders should be created and CIO (2001) recommends that the management team should be grouped into architecture review board, technical review board and project design authority while working in close relationship. Suggested governance mechanism that managers can work with on a daily basis which are decision-making structures: regulated and determined by laws, alignment processes are techniques used for securing the effective participation in governance decisions and execution, formal communication are well-designed ways of communicating governance processes which are being developed and its expected outcomes (Ross & Weill, 2005).

Authors

Best Practice

Ross et al.

Kaisler et al.

Van den Berg &Van Steenbergen

Jahani et al.

Schekkerman (2008)

Seppanen et al.(2009)

IAC

CIO (2001)

Scope of the EA

+

+

+

+

+

+

+

+

Executive support

+

+

+

+

+

+

+

+

Manage EA change

+

+

+

+

+

+

+

+

Develop effective communication plans

+

–

+

+

+

+

+

+

EA resources

+

+

+

+

+

+

+

+

Business Driven

+

+

+

+

+

+

+

Appropriate framework

+

+

+

+

+

+

+

Plan the EA program

+

+

+

+

+

–

+

+

Set up a measurement program

+

–

+

–

+

–

+

+

Develop EA

+

+

+

+

+

–

–

+

Governance

+

+

+

+

+

+

+

+

Table 1. EA Best Practices recommended by authors based on experience

+ indicates inclusion of best practice in their recommendation.

– indicates non-inclusion of best practice in their recommendation.

Conclusion