versão On-line ISSN 2224-7890
versão impressa ISSN 1012-277X
S. Afr. J. Ind. Eng. vol.24 no.2 Pretoria Jan. 2013
M. de Vries
Department of Industrial Engineering University of Pretoria, South Africa marne. firstname.lastname@example.org
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.
Ondernemingsontwerp het onlangs ontwikkel as 'n nuwe dissipline om die intensiteit van die ondernemingsdinamika en kompleksiteit te adresseer deur middel van ontwerp, belyning en leiding tydens ondernemingsontwikkeling. Ondernemingsontwerpers gebruik verskillende benaderings, raamwerke, en metodologieë om verskeie komponente van die onderneming te belyn en te ontwerp. Dié artikel ondersoek die belyning van die besigheidskomponente en inligtingstegnologie-komponente, asook die behoefte aan 'n teoretiese onderbou vir die kombinering van veelvuldige benaderings gedurende ondernemingsontwerp. Die kernbydrae van die artikel is die ontwikkeling van 'n 'metodeartefak'. Die metode-artefak inkorporeer 'n bestaande model, die besigheidsinligtingstegnologie belyningsmodel, en is bruikbaar wanneer ondernemingsontwerpers 'n bestaande besigheids-inligtingstegnologie belyningsbenadering wil uitbrei. As addisionele bydrae, beklemtoon die artikel die rol van 'n groeiende navorsingsmetodologie, genaamd 'ontwerpnavorsing', met die ontwerp van die nuwe metode-artefak. Die artikel toon die gebruik van die metode-artefak wanneer die 'foundation for execution' benadering uitgebrei word met 'n element van die 'essence of operation' benadering, en sluit af met geleenthede vir verdere navorsing.
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 . One of the potential business benefits of EE is to design and align the entire enterprise . 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 , a study by Lindström et al.  indicates that existing theoretical frameworks fail to address the main concerns of the chief information officer. And a study performed by OVUM  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.
2. 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.
2.1 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  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  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  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 . 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 .
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 .
Both the functional and the constructional notions of a system are required during enterprise design; this will be discussed in the next section.
2.2 Enterprise design
When designing the sub-systems of an enterprise, designers follow a design process. Noward, Culley & Dekoninck  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 , which highlights the iterative nature of design while incorporating functional and constructional notions of design. Gero  emphasises the process of developing a new object or object system within the context of a design state space.
Like Gero , Dietz  also suggests an iterative design process, constructional and functional notions of design, and the development of an object system. However, Dietz  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  ('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.
2.3 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'  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 business-organisation 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) . 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 . The main components of BIAM are discussed in the next section.
2.4 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? 
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).
- Component 4: Alignment approach classifiers (the callout in Figure 2) that influence the selection of appropriate alignment mechanisms and practices (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.
2.5 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 . Contrary to other business-IT alignment approaches in which IT supports strategy [25, 26], Ross et al.  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" [24, p 44]. The OM, therefore, has two main dimensions: (1) business process standardisation, and (2) business process integration. Based on the two main dimensions, Ross et al.  defined four general types of operating model, each exhibiting certain characteristics. Ross et al. argue that the selection of an appropriate OM is paramount, since it "articulates a vision of how the company will operate" [24, p 44].
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.  acknowledge that the core diagram provides limited architectural description knowledge of the enterprise, and suggest the Zachman framework for a comprehensive architectural description. Zachman  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 . According to Zachman , 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.
2.6 The essence of operation approach
Dietz , in his essence of operation approach, focuses on the essential construction and operation of the enterprise, also called enterprise ontology. Since Dietz  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  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 , 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  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  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  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.
3. 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 from various alignment approaches without theoretical backing for these combinations . Mingers & Brocklesby  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) . 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 .
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 , 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.
4. RESEARCH METHODOLOGY
Design science, as a problem-solving research approach, has its roots in engineering and the sciences of the artificial . 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 , 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 , 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.
5. 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  (discussed in Section 2.2), and the BIAM  (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. , the design process ends with design specifications (constructional requirements), but excludes implementation.
The next section provides a practical demonstration of the AEM and demonstrates the role of BIAM.
6. 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).
6.1 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 . A summary of the contextualisation is provided in the first column of Table 2.
6.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) . 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 . 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.
6.3 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. , 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).
6.4 Step 4: Suggest an enhancing approach to address expected functions for enhancements
The essence of operation approach of Dietz  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 . A summary is provided in the second column of Table 2.
6.6 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 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 .
6.7 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) .
6.8 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. , 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) . 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.
7. 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  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  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.
 Hoogervorst, J.A.P. 2009. Enterprise governance and enterprise engineering, Springer. [ Links ]
 Rebovich, G. & White, B.E. 2011. Enterprise systems engineering, Boca Raton, CRC Press. [ Links ]
 Barjis, J. 2011. Enterprise modeling and simulation within enterprise engineering, Journal of Enterprise Transformation, 1(3), pp 185-207. [ Links ]
 Kappelman, L.A., et al. 2010. Enterprise architecture: Charting the territory for academic research, in The SIM guide to enterprise architecture, L.A. Kappelman, Editor. Boca Raton, CRC Press, pp 96-110. [ Links ]
 Schekkerman, J. 2004. How to survive in the jungle of enterprise architecture frameworks, 2nd edition, Victoria, Trafford Publishing. [ Links ]
 Lindström, A., et al. 2006. A survey on cio concerns - do enterprise architecture frameworks support them?, Information Systems Frontiers, 8(2), pp 81-90. [ Links ]
 Blowers, M. 2012. Hybrid enterprise architecture frameworks are in the majority, [accessed 12 April 2012], available from: http://ovum.com/2012/03/22/hybrid-enterprise-architecture-frameworks-are-in-the-majority/. [ Links ]
 Dumay, M., Dietz, J.L.G., & Mulder, J.B.F. 2005. Evaluation of DEMO and the language-action perspective after 10 years of experience, in The lanaguage action perspective on communication modelling, 10th international working conference., G. Goldhuhl, M. Lind, and S. Haraldson, Editors. Kiruna, pp 77-106. [ Links ]
 Munro, I. & Mingers, J. 2002. The use of multimethodology in practice - results of a survey of practitioners The Journal of the Operational Research Society, 53(4), pp 369-378. [ Links ]
 De Vries, M. 2010. A framework for understanding and comparing enterprise architecture models, Management Dynamics, 19(2), pp 17-29. [ Links ]
 De Vries, M. 2012. A process reuse identification framework using an alignment model. Unpublished PhD thesis, University of Pretoria. [ Links ]
 Galliers, R.D. & Baets, W.R. 1998. Information technology and organisational transformation, Chichester, Wiley. [ Links ]
 Kotter, J.P. 1995. Leading change: Why transformation efforts fail, Harvard Business Review, 71(2), pp 59-67. [ Links ]
 Giachetti, R.E. 2010. Design of enterprise systems, Boca Raton, CRC Press. [ Links ]
 Dietz, J.L.G. 2006. Enterprise ontology, Berlin, Springer. [ Links ]
 Hitchins, D.K. 2003. Advanced systems thinking, engineering and management, Boston: London, Artech House. [ Links ]
 Howard, T.J., Culley, S.J., & Dekoninck, E. 2008. Describing the creative design process by the integration of engineering design and cognitive psychology literature, Design Studies, 29, pp 160-180. [ Links ]
 Gero, J.S. 2004. The situated function-behaviour-structure framework, Design Studies, 24(4), pp 373-391. [ Links ]
 Lawrence, P. & Lorsh, J. 1967. Organisation and environment, Boston, Harvard Business School Press. [ Links ]
 Powell, T.C. 1992. Organisational alignment as competitive advantage, Strategic Management Journal, 13, pp 119-134. [ Links ]
 Luftman, J. 2003. Competing in the information age: Align in the sand, Oxford, Oxford University Press. [ Links ]
 Lapalme, J. 2011. 3 schools of enterprise architecture, IT Professional, 13(6), pp 1-7, available from: http://ieeexplore.ieee.org/xpl/tocresult.jsp?asf_arn=null&asf_iid=5185486&asf_pun=null&asf_in=null&asf_rpp=null&asf_iv=null&asf_sp=null&asf_pn=2. [ Links ]
 Luftman, J. & Kempaia, R. 2008. Key issues for IT executives 2007, MIS Quarterly Executive, 7(2), pp 99-112. [ Links ]
 Ross, J.W., Weill, P., & Robertson, D.C. 2006. Enterprise architecture as strategy: Creating a foundation for business execution, Boston, Harvard Business School Press. [ Links ]
 Rosser, B. 2004. Sell the value of architecture to the business, G00123412, USA: Gartner Research. [ Links ]
 Lapkin, A. 2005. Business strategy defines enterprise architecture value, G00129604, USA: Gartner Research. [ Links ]
 Zachman, J.A. 1996. The framework for enterprise architecture: Background, description and utility, [accessed 9 June 2009], available from: http://www.aeablogs.org/eakd/files/The_Framwork_for_EA_Background_Description_and_Utility.pdf. [ Links ]
 Zachman, J.A. 2012. John zachman's concise defintion of the zachman framework, [accessed 17 February 2012], available from: http://www.zachman.com/about-the-zachman-framework. [ Links ]
 Habermas, J. 1981. Theorie des kumminikatives handelns, Frankfurt, Suhrkamp Verlag. [ Links ]
 Mingers, J. & Brocklesby, J. 1997. Multimethodology: Towards a framework for mixing methodologies, Omega, 25(5), pp 489-509. [ Links ]
 De Vries, M. & Van Rensburg, A.C. 2009. Evaluating and refining the 'enterprise architecture as strategy' approach and artefacts, South African Journal of Industrial Engineering, 20(1), pp 31-43. [ Links ]
 Simon, H.A. 1996. The sciences of the artificial, 3rd edition, Cambridge, MIT Press. [ Links ]
 Kuechler, W. & Vaishnavi, V. 2008. The emergence of design research in information systems in north america, Journal of Design Research, 7(1), pp 1-16. [ Links ]
 Winter, R. 2008. Design science research in europe, European Journal of Information Systems, 17, pp 470-475. [ Links ]
 Henver, A.R., March, S.T., Park, J., & Ram, S. 2004. Design science in information systems research, MIS Quarterly, 28(1), pp 75-105. [ Links ]
 Gregor, S. & Hevner, A. 2013. Positioning and presenting design science research for maximum impact, in press, MIS Quarterly, 37(2), pp 337-355, available from: http://misq.org/positioning-and-presenting-design-science-research-for-maximum-impact.html. [ Links ]  Vaishnavi, V. & Kuechler, W. 2004/5. Design research in information systems, [accessed 11 December 2009], available from: http://desrist.org/design-research-in-information-systems. [ Links ]
 De Vries, M., Van der Merwe, A., Gerber, A., & Kotzé, P. 2010. Refining the operating model concept to enable systematic growth in operating maturity, in Proc. 24th SAIIE conference, C. Schutte, Editor. Glenburn Lodge, Gauteng, SAIIE, pp 32-46. [ Links ]
 Smith, H. & Fingar, P. 2003. Business process management: The third wave, Florida, Meghan-Kiffer Press. [ Links ]
 O'Kane, B., Radcliffe, J., & White, A. 2012. Hype cycle for master data management, G00227133, USA: Gartner Group. [ Links ]
 Whitten, J.L. & Bentley, L.D. 2007. Systems analysis and design for the global enterprise, 7th edition, New York, McGraw-Hill/Irwin. [ Links ]
 Gill, T.G. & Hevner, A. 2011. A fitness-utility model for design science research, in Proceedings of the Design Science Research in Information Systems and Technology (DESRIST 2011), Milwaukee: WI. [ Links ]