A METHOD TO ENHANCE EXISTING BUSINESS-IT ALIGNMENT APPROACHES

Enterprise engineering has recently emerged as a new discipline to address the intensified complexity and dynamics of the evolving enterprise by designing, aligning, and governing its development. Enterprise designers employ various approaches, frameworks, and methodologies to design and align various components in the enterprise. This paper takes a closer look at alignment between the business and IT components of an enterprise, and the need for a theoretical backing when combining multiple approaches during enterprise design. The main contribution of this paper is the development of a ‘method artefact’. The method artefact applies an existing model, called the business-IT alignment model, and is useful to enterprise designers when they need to enhance an existing business-IT alignment approach. As an additional contribution, the paper emphasises the role of an emerging research methodology, called ‘design research’, in developing the new method artefact. The paper demonstrates the use of the method artefact by enhancing the ‘foundation for execution’ approach with an element from the ‘essence of operation’ approach, and concludes with opportunities for further research.


INTRODUCTION
The Internet and the World Wide Web have shaped the social, cultural, and economic fibre in enterprises, providing opportunities for them to enter new business domains and creating networks of collaborating enterprises.Enterprise designers are required to seize new opportunities and solve problems that result from the extended co-evolving network, while complying with corporate governance rules and legislation [1,2].
Enterprise engineering (EE) emerged as a new discipline to address the intensified complexity and dynamics of the evolving enterprise by designing, aligning, and governing its development.EE consists of three subfields: enterprise ontology, enterprise governance, and enterprise architecture [3].One of the potential business benefits of EE is to design and align the entire enterprise [4].However, a strong theme within enterprise design and alignment is alignment between business components and IT components, called 'business-IT alignment'.Although a proliferation of frameworks emerged in the literature to facilitate business-IT alignment [5], a study by Lindström et al. [6] indicates that existing theoretical frameworks fail to address the main concerns of the chief information officer.And a study performed by OVUM [7] indicates that 66 per cent of enterprises had developed their own customised framework, with one third of the participants making use of two or more theoretical frameworks.Yet, when practitioners combine elements from various alignment approaches/methodologies/frameworks, there is a lack of theoretical backing for these combinations [8,9].Business-IT alignment knowledge is embedded in an expanding number of alignment approaches and frameworks, each with its own alignment intent, scope, and means for alignment.This variety impairs comparison of the different approaches and possible combined use.Previous work circumvented this problem by providing a common reference model -the business-IT alignment model (BIAM) [10,11] -for understanding and comparing existing alignment approaches.Although useful for comparison purposes, BIAM is a descriptive model.Prescriptive knowledge for applying BIAM in comparing and combining existing business-IT alignment approaches is absent.
The main contribution of this paper is the development of a method artefact to enhance an existing business-IT alignment approach with elements from another approach.Embedded as part of the method artefact, BIAM is used as a mechanism to compare an existing business-IT alignment approach with candidate enhancement approaches to assess approach compatibility.As an additional contribution, the paper emphasises the role of an emerging research methodology, called 'design research', in developing the method artefact.
The paper is structured as follows: Section 1 provides background on the topic of enterprise design and alignment.Section 2 defines the rationale for developing the new method artefact, while Section 3 provides a research methodology for constructing the main components of the method artefact.These components are detailed in Section 4. Section 5 demonstrates the method artefact by enhancing the 'foundation for execution' approach with an element from the 'essence of operation' approach.Section 6 concludes the paper and presents opportunities for follow-up research.

THE ENTERPRISE DESIGN AND ALIGNMENT CONTEXT
This section presents some of the kernel theories used to construct and evaluate the method artefact.Section 2.1 introduces essential concepts to describe and understand the enterprise as a system.Basic system concepts are extended in Section 2.2, emphasising the basic system design process that is used during the development of the method artefact.Section 2.3 introduces the concept of aligning different enterprise sub-systems, focusing on alignment between business and IT.Section 2.4 introduces the business-IT alignment model (BIAM), applied as part of the new method artefact to compare existing business-IT alignment approaches.Sections 2.5 and 2.6 introduce two business-IT alignment approaches (the foundation for execution approach and the essence of operation approach) that are used to evaluate the new method artefact.

The enterprise as a system
One of the core reasons why enterprise initiatives fail is a lack of coherence and consistency among various parts or sub-systems of the enterprise [1,12,13].Hoogervorst [1] states that coherence and consistency do not occur incidentally, but need to be designed; hence the requirement for intentional enterprise design.
Systems theory is a way of explaining how enterprises work, as well as prescribing designs for how they should work [2,14].According to Giachetti [14, p 9], a system is "a set of discernible, interacting parts or sub-systems that form an integrated whole that acts with a single goal or purpose".Every system has a boundary to encapsulate the interacting parts and sub-systems of concern.
An enterprise could be defined as "a complex, socio-technical system that comprises interdependent resources of people, information, and technology that must interact with each other and their environment in support of a common mission" [14, p 4]. Being a system, the enterprise can be demarcated into sub-systems.Although there may be several ways to define sub-systems for an enterprise system, Dietz [15] distinguishes between two prominent sub-systems; the organisation sub-system, and the information and communications technology (ICT) sub-system, which supports it.
Within the organisation sub-system, Dietz [15] encapsulates three aspect systems: the business-organisation, the intellect-organisation, and the document-organisation.Enterprise design needs to ensure consistency or alignment across all sub-systems -that is, consistency across the business-organisation, intellect-organisation, document-organisation, and ICT [1].Furthermore, the enterprise system designer needs to be knowledgeable about both the constructional and the functional facets of the constituting sub-systems.
Constructional knowledge is a prerequisite for building or maintaining a system.White-box models or representations are used to communicate the constructional knowledge of a system.An example of a white box model is the constructional decomposition model (also called a bill-of-material) of a car (the car being the system); here, a constructional decomposition model indicates that a car consists of a chassis, wheels, motor, and lamps [15].Functional knowledge is a prerequisite for using or controlling a system.Black-box models or representations are typically used to conceptualise the functions and behaviours of a system, void of constructional detail.An example of a black box model is the functional decomposition model of a car (the car being the system); here a functional decomposition model indicates that a car has a lighting system, power system, steering system, and a brake system.An understanding of the behaviour of the enterprise system would allow managers to control the enterprise.The functional notion of the enterprise is therefore the dominant notion used by managers [16].
Both the functional and the constructional notions of a system are required during enterprise design; this will be discussed in the next section.

Enterprise design
When designing the sub-systems of an enterprise, designers follow a design process.Noward, Culley & Dekoninck [17] analyse and compare twenty-three engineering design process models, and find that most models present a linear view of the design process.They favour the design process model of Gero [18], which highlights the iterative nature of design while incorporating functional and constructional notions of design.Gero [18] emphasises the process of developing a new object or object system within the context of a design state space.
Like Gero [18], Dietz [15] also suggests an iterative design process, constructional and functional notions of design, and the development of an object system.However, Dietz [15] does not refer to a design state space as the context for developing the object system, but rather refers to a using system to provide context.Reference to a using system (rather than design state space) is appropriate when the object system will be used by the using system.As an example ('Example 1' in Figure 1), an ICT system (the object system) is used by the organisation system (the using system).When a using system applies, the basic system design process model of Dietz [15] ('Basic System Design Process' in Figure 1) provides a conceptualisation of the design process.
The first design phase of the basic system design process (see 'Determining Requirements' arrow in Figure 1) starts with a constructional understanding of the using system to define the required function of the object system (the function represented by black box models).The second design phase (see 'Devising Specifications' arrow in Figure 1) starts with the function of the object system and concludes with the construction of the object system.Design (dotted 'Design' arrow in Figure 1) is an iterative alternation between analysis (Figure 1, 'Analysis') and synthesis (Figure 1, 'Synthesis') -that is, design is not a one-way process.The basic system design process highlights the construction-function-construction pattern evident in designing an object system within the context of a using system.
A second example ('Example 2' in Figure 1) will be discussed later, in Section 5.The basic system design process could be used to conceptualise the design and alignment of multiple supporting sub-systems within the enterprise system, as discussed in the next section.

Alignment of enterprise sub-systems
When designing the enterprise, the designer should ensure coherency and consistency between the sub-systems and facets of the enterprise [1, p xvi].Various authors provide different labels for coherency and consistency, such as 'structural fit' [19] and 'alignment' [20,21].Alignment thus refers to a certain state -the result of the design process.Alignment could be presented on two levels of scope [1,22]: enterprise alignment versus business-IT alignment.Enterprise alignment needs to ensure coherence and consistency among all enterprise sub-systems and facets, including norms, convictions, and culture.Enterprise alignment also needs to align the enterprise with the environmental system.Business-IT alignment has a narrower focus, emphasising alignment of the businessorganisation sub-system with the ICT sub-system via two sub-system layers (intellect- organisation and document-organisation).A business-IT alignment state thus implies that business and ICT are "integrated, in harmony, converged, linked, fused, synthesized" [23, p 102].
A previous study highlighted the problem of re-using the existing business-IT alignment knowledge base due to fragmentation in emerging disciplines and fields (e.g.enterprise engineering, enterprise architecture, and enterprise ontology) [11].It was found that business-IT alignment knowledge was mostly embedded in enterprise architecture frameworks and approaches, each with its own alignment intent, scope, and means for alignment that impaired approach comparison and possible combined use.A business-IT alignment model (BIAM) was developed inductively to circumvent the fragmentation problem, providing a common frame of reference to compare existing business-IT alignment approaches [11].The main components of BIAM are discussed in the next section.

The business-IT alignment model (BIAM)
BIAM (shown in Figure 2) is a descriptive model that contextualises an existing alignment approach by answering three main questions about a specific alignment approach: Question 1: Why should the enterprise use the proposed approach to align?Question 2: What should the enterprise align?Question 3: How should the enterprise align?[11] Figure 2: The BIAM (adapted from [11]) In answering the three questions through a conceptual mechanism, BIAM consists of four main components: • Component 1: An alignment belief/paradigm of creating value (the foundation ellipse in Figure 2) (answering question 1).

•
Component 2: Three alignment dimensions (the three panes of the block in Figure 2) to define the scope of alignment (answering question 2) in terms of three dimensions: design domains, enterprise scope, and concerns & constraints.

•
Component 3: Supporting alignment mechanisms and practices (the bottom triangle in Figure 2) to ensure alignment across the alignment dimensions (partially answering question 3).
In this research, BIAM was proposed as a key mechanism during the development of the method artefact (see Section 5).Later (in Section 6), when demonstrating the practical use of the method artefact, BIAM is used to contextualise two existing alignment approaches in terms of business-IT alignment.Sections 2.5 and 2.6 introduce two existing alignment approaches: the 'foundation for execution' approach, and the 'essence of operation' approach.

The foundation for execution approach
The foundation for execution approach provides a new business-IT alignment approach to prevent piece-meal and disjointed IT developments that result from new strategic initiatives [24].Contrary to other business-IT alignment approaches in which IT supports strategy [25,26], Ross et al. [24] maintain that management needs to make a strategic decision on the required operating model (OM) of the enterprise that would guide systematic development of the supporting ICT systems.
The OM is used to establish the "necessary level of business process integration and standardisation for delivering goods and services to customers" [ Another key artefact that is derived from the OM is called the core diagram.This provides a graphical representation of the enterprise vision -i.e.translating OM decisions into a visual representation of the processes, data, and technologies that need to be shared across the enterprise.Ross et al. [24] acknowledge that the core diagram provides limited architectural description knowledge of the enterprise, and suggest the Zachman framework for a comprehensive architectural description.Zachman [27] developed the Zachman framework for enterprise architecture (a six by six matrix) that provides a logical structure for classifying and organising the descriptive representations of the enterprise [28].According to Zachman [28], the six by six matrix depicts six communication interrogatives (what, how, when, who, where, and why) as columns, and six reification transformations (scope contexts, business concepts, system logic, technology physics, tool components, and operations instances) as rows.Later, in Section 6, we refer back to the Zachman framework when contextualising the foundation for execution approach in terms of BIAM.
The foundation for execution approach is primarily concerned with creating a vision for standardising processes and sharing data enterprise-wide, as required by the OM.Another business-IT alignment approach that is useful for enhancing the foundation for execution approach is the essence of operation approach, discussed next.

The essence of operation approach
Dietz [15], in his essence of operation approach, focuses on the essential construction and operation of the enterprise, also called enterprise ontology.Since Dietz [15] maintains that the organisation of an enterprise is a social system, and the active elements of a social system are human beings who operate on and communicate about things in the object world, the essence of the construction and operation of the enterprise needs to contain the communicative aspects of the enterprise.The essence of operation approach thus draws on the theory of communicative action of Habermas [29] to provide an explanation of how communication works and how communication is used to perform coordination acts and production acts in an enterprise.
According to Dietz [15], humans perform two kinds of acts within their position of authority and responsibility: production acts and coordination acts.Production acts render goods or services that are delivered to the environment of the enterprise, and may be either material (e.g.manufacturing a product) or immaterial (e.g. a decision to grant an insurance claim).Coordination acts, however, ensure that humans enter into and comply with commitments to each other in the performance of a production act.In performing coordination acts and production acts, humans apply three kinds of communicative acts that correspond with their human abilities: (1) datalogical acts due to their 'forma' ability, (2) infological acts due to their 'informa' ability, and (3) ontological acts due to their 'performa' ability.The distinct human abilities (performa, informa, and forma abilities) provide the opportunity to create three abstraction layers in representing the organisation of the enterprise.Dietz [15] thus represents the organisation of the enterprise as a heterogeneous social system that consists of a layered integration of three homogeneous social systems: the ontological, infological, and datalogical aspect systems (see left side of Figure 3).The three aspect systems are of the same category (that is, social systems) but differ in their kind of production: the ontological aspect system produces ontological acts, such as decisions and judgments; the infological aspect system produces infological acts, such as reproducing, deducing, reasoning, and computing; and the datalogical aspect system produces datalogical acts, such as storing, transmitting, copying, and destroying.
The distinction between different aspect systems enables one to focus on the essential or ontological aspect system in describing the essential operation of an enterprise system, irrespective of its realisation (i.e.integration with the other two aspect systems) or implementation (using technology to make the organisation operational).The three aspect systems thus only represent the organisation of the enterprise system, and exclude the implementation (incorporating technology) of the enterprise system.
Dietz [15] focuses on the essential or ontological aspect system, using ontological aspect models (OAMs) to represent the ontological knowledge of an enterprise.The right-hand part of Figure 3 shows OAMs to represent the ontological knowledge of an enterprise.In assisting the practitioner to develop the OAMs (right-hand part of Figure 3) in the right way, Dietz [15] developed a methodology called DEMO (design and engineering methodology for organisations).DEMO suggests that the OAMs are developed in a defined sequence.
The essence of operation approach is primarily concerned with creating the essential constructional view of the organisation of the enterprise system (also called the enterprise ontology) as a starting point for alignment with the ICT system.

RATIONALE FOR THIS STUDY
Although there is a need to combine several approaches when designing and aligning an enterprise [7,9,30], practitioners often combine elements various alignment approaches without theoretical backing for these combinations [8].Mingers & Brocklesby [30] state that mixing approaches may not be simple because of paradigm incommensurability.A combination of approaches may also be impractical, requiring a wide range of knowledge, skills, and flexibility on the part of the practitioners.Several possibilities exist for combining approaches, such as enhancement (enhancing an approach or methodology with techniques from another), combination (combining whole approaches or methodologies in an intervention), and selection (selecting whole approaches or methodologies appropriate to a particular situation) [30].Previous work identified the requirement to enhance a specific business-IT alignment approach (the foundation for execution approach, discussed in Section 2.5) due to practical problems in using the operating model [31].
This paper addresses the need for a method to enhance an existing business-IT alignment approach with elements from another approach.According to Mingers & Brocklesby [30], enhancement of an existing approach requires similarity in the underlying approach paradigms.The next section presents the research methodology (design research) for developing the required method.

RESEARCH METHODOLOGY
Design science, as a problem-solving research approach, has its roots in engineering and the sciences of the artificial [32].Simon [32, p 55] differentiated design science from other paradigms: "Whereas natural sciences and social sciences try to understand reality, design science attempts to create things that serve human purposes".Design research uses design as a method for investigation [33], aiming to create "solutions to specific classes of relevant problems by using a rigorous construction and evaluation process" [34, p 471].
The fundamental principle of design research is that "knowledge and understanding of a design problem and its solution are acquired in the building and application of an artefact" [35, p 82]. Useful knowledge (in the form of an artefact) could be divided into two categories: descriptive knowledge and prescriptive knowledge.A method artefact, according to Gregor & Hevner [36, p 46], is prescriptive, providing "the instructions for performing goal-driven activities".This paper focuses on the development of a method artefact.
Applying the design cycle of Vaischnavi & Kuechler [37], Figure 4 demonstrates the design process for developing the method artefact.The cycle starts with the awareness of a problem (e.g. the need to enhance an existing business-IT alignment approach with elements from another alignment approach), followed by a suggestion (e.g.suggested development of a method artefact that incorporates BIAM as a mechanism).The method artefact is developed during development, followed by evaluation using a practical demonstration.Evaluation results are discussed during the conclusion step.Circumscription is an important process in design research, as it creates an understanding that could only be gained from the construction-act, often leading to additional iterations of the design cycle.The next section presents the constructional components of the method artefact developed during the development step ('Development' in Figure 4) of the design cycle.

A NEW APPROACH-ENHANCING METHOD
The theoretical foundations of the new method artefact, called the approach enhancement method (AEM), are the basic system design process [15] (discussed in Section 2.2), and the BIAM [11] (defined in Section 2.4).
The logic of the basic system design process was applied during the development of the AEM (see 'Example 2' in Figure 1), where the AEM provides a method for developing a set of enhancements (the object system) that could be used by an existing alignment approach (the using system).The construction-function-construction pattern of the basic system design process was applied during the development of the AEM (see the 'Construction/ Function/Construction' rectangles in Figure 5), resulting in an eight-step process: 1. Understand the construction of an existing alignment approach, using a BIAM contextualisation of the existing alignment approach.2. Identify deficiencies evident in the existing alignment approach.3. Determine functional requirements to address the deficiencies evident in the existing alignment approach.4. Suggest an enhancing approach that may be appropriate for rendering some of the expected functions for required enhancements.5. Understand the construction of the enhancing approach, using a BIAM contextualisation of the enhancing approach.6. Compare the existing approach and enhancing approach for approach compatibility.If the approaches are not compatible, return to Step 4. 7. Select constructional elements from the enhancing approach to be included as enhancements.8. Determine constructional requirements for the set of approach enhancements.
In accordance with Howard et al. [17], the design process ends with design specifications (constructional requirements), but excludes implementation.

Developing the method-artefact
There is a need to enhance an existing business-IT alignment approach with elements from another alignment approach.
It is suggested that a methodartefact be developed, incorporating BIAM as a mechanism to compare existing approaches.

Develop the method-artefact.
Evaluate the method-artefact, demonstrating its use to enhance the foundation for execution approach.
Interpret the method-artefact demonstration results.

Figure 5: Process steps of the approach enhancement method (AEM)
The next section provides a practical demonstration of the AEM and demonstrates the role of BIAM.

DEMONSTRATION OF THE APPROACH ENHANCEMENT METHOD
Although the AEM could be useful to extend a business-IT alignment approach that is custom-developed for a specific enterprise, this section demonstrates the extension of a theoretical alignment approach.The theoretical 'foundation for execution' approach (described in Section 2.5) is extended with an element from the 'essence of operation' approach (described in Section 2.6), according to the eight steps of the AEM (detailed in Section 5).

Step 1: Understand the construction of an alignment approach (using BIAM)
A BIAM-contextualisation of the foundation for execution approach was performed to contextualise the approach of the four BIAM components [11].A summary of the contextualisation is provided in the first column of Table 2.

Step 2: Identify approach deficiencies
An experimentation process (using a survey for data collection) was used to assess the practicality of the operating model (OM) and its derivative (the core diagram) [31].It was found that research participants experienced difficulty in defining a current-state OM and core diagram for an existing enterprise.Although the construction of both artefacts (the OM and the core diagram) was problematic, the core diagram depends on the OM, translating the process standardisation or integration requirements of the OM into the core diagram components.Since the core diagram is a derivative of the OM, the focus was restricted to the identified deficiencies of the OM.
Using the contextualisation of the foundation for execution approach and its related OM, it was evident that an OM method-deficiency existed for identifying opportunities (1) to share data and (2) to re-use processes across several business units [38].Given that many enterprises have already seized the opportunity of sharing data [1,39,40], the demonstration focused on addressing the method-deficiency of the OM -that is, the OM failed to guide the practitioner in identifying process re-use opportunities at an enterprise.

Step 3: Determine functional requirements to address the deficiencies
The constructional analysis of the foundation for execution approach (and its related OM) helped to identify the functional requirements needed to address the method-deficiency related to process re-use identification.In agreement with Howard et al. [17], a creative or generative element was used to define a list of seven requirement categories for identifying process re-use opportunities at an enterprise (Table 1).

Table 1: Requirements for addressing deficiencies pertaining to opportunities to identify process re-use at enterprises, based on de Vries et al. [38]
No.

Category Requirement detail R1 User(s) of the practices and related mechanisms
Any EA practitioner who wants to use the OM specified by Ross et al. [24] and needs to collaborate with other stakeholders in defining the required level of process standardisation/replication.

R2 Generality
The practices and mechanisms should be generic in their application to different types of industries.An EA practitioner should be able to apply the practices and mechanisms to profitdriven or to not-for-profit/government enterprises within any industry, in combination with the foundation for execution approach.

R3 Process categories included
The practices and mechanisms may be applied to all processes in the enterprise; however, practices and mechanisms will be most effective when applied to the primary activities of an enterprise.

R4 Current architecture capabilities
The practices and mechanisms need to take current work of enterprise architecture, business architecture, and process architecture into account, but also need to provide sufficient detail if none of these architectures has been defined or documented.

R5 Process representation
The practices and mechanisms should encourage consistent process representation to ensure re-use.The extent of re-use includes the following: 1.It should be possible to add process measures if required for the purpose of performance measurement or process improvement.2. The process representations should support end-to-end views of processes.3. Process representations should not hamper the transition from the third to the fourth levels of architecture maturity -i.e. they should allow for modular process design.4. The representations that are used to communicate process replication opportunities should be understandable to business users (from the contextual and conceptual viewpoints).

R6 Replication identification
The mechanisms and practices should enable the identification of operationally similar organising entities.

R7 Feasibility analyses
The mechanisms and practices should not suggest the means for assessing or measuring the feasibility of process replication or No.

Category
Requirement detail rationalisation.Feasibility analyses (e.g.operational, cultural, technical, schedule, economic, and legal feasibility [41]) that may be associated with process rationalisation solutions are therefore excluded.

Step 4: Suggest an enhancing approach to address expected functions for enhancements
The essence of operation approach of Dietz [15] was chosen as a candidate enhancing approach, since it had a strong focus on enterprise operation and included techniques to represent processes at a concise and essential level.

6.5
Step 5: Understand the construction of the enhancing approach (using BIAM) A BIAM-contextualisation of the essence of operation approach was performed to contextualise the approach of the four BIAM components [11].A summary is provided in the second column of Table 2.

Table 2: Comparison of two alignment approaches [11]
Foundation for execution approach

Essence of operation approach
Similarities/Differences

Paradigm of creating value
Value is created when enterprises digitise their operational processes.Before digitising their processes, managers need to have a vision (future view) of how the company should operate, as articulated in an OM.The OM is used as a guide in the systematic development of the foundation for execution.
The paradigm of value creation is that alignment of ICT systems with the enterprise system requires a design process, which requires constructional knowledge of the using system (the enterprise system) to derive functions for the object system (the ICT system).The approach reduces the complexity of the constructional knowledge of the enterprise, by providing an implementation-independent view of enterprise operation and construction, called enterprise ontology, and represented by ontological aspect models (OAMs).

SIMILAR
Both approaches state the requirement to decide on or understand the operation of the enterprise.

DIFFERENT
The foundation for execution approach requires a decision about enterprise operation to guide the development of ICT systems, as articulated in the OM, whereas the essence of operation approach provides the means to understand the essence of operation and construction.Dietz [15] takes a layered systems approach to defining design domains.The heterogeneous enterprise system consists of at least two sub-systems: the organisation system and an ICT system.The organisation system consists of the layered integration of three aspect systems.

The dimensions for alignment
In terms of concerns, the aspect systems distinguish between three different concerns: business, intellect, and document.For the BIAM enterprise scope dimension, the ontological aspect models

DIFFERENT
Although referring to the Zachman framework, the foundation for execution approach is not concerned with the detail of architecture description.In contrast, the main contribution of the essence of operation approach centres on an architecture description, based on systems theory.Although both the Zachman approach and the essence of operation approach intend to create an enterprise ontology, they differ substantially in how they define design domains.

Essence of operation approach
Similarities/Differences enterprise).

DIFFERENT
The OM is primarily normative (providing guidance) for creating a foundation for execution, but is also descriptive, since each of the four stereotypical OMs has a set of descriptive characteristics.
The IAM is descriptive in representing the constructional knowledge of the enterprise.

SIMILAR
The OM and IAM address a common descriptive facet: processes from a contextual perspective.

Alignment approach classifiers (1) Version of architecture
Focus on future state architecture, which is also used to define architecture principles.
Focus on future state, i.e. conceiving the essence of the organisation system that will realise a new business.

SIMILAR
Both focus on the future state architecture.
(2) Starting point for alignment Top-down approach (starting with the executive perspective, and emphasising the executive perspective) A top-down approach is followed for architecture development, i.e. starting with the enterprise as the using system, and deriving requirements for the ICT system as the object system.

SIMILAR
Both follow a top-down alignment approach.
(3) Alignment frequency Continuous, incremental alignment, building the foundation one project at a time.
Favours a continuous, systematic design according to the basic system design process.

SIMILAR
Both favour a continuous alignment approach.
(4) Changing/dynamic nature of components Aims at reducing architectural complexity by rationalising data and processes according to the OM requirements, thus limiting duplicated efforts in managing the changing and dynamic nature of architecture components.
Aims at reducing architectural complexity by extracting the ontological construction of the enterprise (independent of realisation or implementation), "hence reducing the difficulty in understanding enterprises" [1].

DIFFERENT
Although both aim at reducing complexity, the foundation for execution approach focuses on data and process rationalisation, whereas the essence of operation approach reduces the difficulty in understanding enterprises.

Step 6: Compare approaches for compatibility
The detailed BIAM-contextualisations of the foundation for execution approach (in Step 1) and the essence of operation approach (in Step 5) facilitated comparison between the two.Table 2 provides a summary that compares the two alignment approaches of the main BIAM 123 components: (1) paradigm of creating value, (2) dimensions for alignment, (3) alignment mechanisms and practices, and (4) alignment approach classifiers.
Although Table 2 indicates differences between the foundation for execution approach and the essence of operation approach, they could complement one another.The foundation for execution approach is primarily normative, focusing on guiding the development of ICT systems, whereas the essence of operation approach is primarily descriptive, representing the constructional knowledge of the enterprise [11].

Step 7: Select constructional elements from the enhancing approach
As indicated in Table 2, both the operating model (associated with the foundation for execution approach) and the interaction model (associated with the essence of operation approach) address a common facet: processes from a contextual perspective.The interaction model (one of the constructional elements associated with the essence of operation approach) could have the potential to address the requirements relating to process representation and replication identification of Table 1 (R5 and R6) [11].

Step 8: Determine constructional requirements for enhancements
The set of enhancements had to address the method-deficiency of the operating model, enabling the practitioner to identify process re-use opportunities at an enterprise.In agreement with Howard et al. [17], a creative and generative element was used to define the constructional requirements for the enhancements: 1.The set of enhancements had to ensure ease-of-use and cognition.
2. The enhancements had to incorporate the appropriate use of the interaction model (from the essence of operation approach) to address functional requirements relating to process representation and replication identification of Table 1 (R5 and R6). 3. The enhancements had to incorporate a method, and indicate a sequence of execution -i.e. a method with phases and phase-steps.4. In providing additional guidance to practitioners, applicable mechanisms and practices had to be defined for each phase-step. 5. Since every enterprise differs in context, additional motivations, considerations, and implications had to be defined for applying the mechanisms and practices appropriately.
Based on the functional requirements (identified in Step 3) and the constructional requirements listed above, a set of enhancements was constructed and packaged as a process re-use identification framework (PRIF) [11].Since detailed construction and implementation does not form part of the AEM, the components of PRIF will not be discussed as part of the AEM demonstration.

CONCLUSIONS AND FUTURE WORK
Enterprises often need to combine several approaches in dealing with the richness of the real world.Yet when practitioners combine elements from various alignment approaches, there is a lack of theoretical backing for these combinations.This article has acknowledged the fragmentation that exists within the business-IT alignment knowledge base and that hampers the combined use of alignment approaches or their associated elements.As a solution, the article has suggested the development of a method artefact called the approach enhancement method (AEM).Presented as a scientific contribution, the AEM is useful to researchers and practitioners when an existing business-IT alignment approach needs to be enhanced with elements from another approach.
The AEM was demonstrated by enhancing an existing theoretical business-IT alignment approach (the foundation for execution approach) with an element (the interaction model) from another approach (the essence of operation approach).This paper applied a single iteration of the design cycle prescribed by Vaishnavi & Kuechler [37] to develop the AEM.The act of demonstrating the AEM led to a process of reflection, identifying additional extension possibilities that could initiate additional iterations of the design cycle.An example of an extension possibility is that the AEM could be more prescriptive about the process of searching for alternative enhancement approaches and selecting the most appropriate enhancement approach.More guidance may also be required to direct the practitioner in evaluating approach compatibility when BIAM is used as an approach comparison tool.
Although a single demonstration of the AEM provides an example of its use, Gill & Hevner [42] suggest rigorous demonstration of its usefulness, including factors such as ease of use, ease of learning, and cost-benefit in using the artefact.Apart from usefulness, they also recommend evaluation of other characteristics that promote the evolution of the artefact.Since this paper focused on a theoretical evaluation only, it is proposed that industry participants be involved in evaluating the AEM in practice.

Figure 1 :
Figure 1: The basic system design process, based on Dietz [15]

Figure 3 :
Figure 3: The three aspect systems of enterprise organisation and the ontological aspect models, based on Dietz [15, p 140]