Demonstrating Approach Design Principles during the Development

of a DEMO-based Enterprise Engineering Approach

Thomas van der Meulen

1,2

, Marné de Vries

and Aurona Gerber

1,3

Department of Industrial Engineering, University of Pretoria, Pretoria, South Africa

Engineering Department, Bertie van Zyl (Pty) Ltd, Pretoria, South Africa

CAIR, CSIR Meraka as well as Department of Informatics, University of Pretoria, Pretoria, South Africa

Keywords: Enterprise Engineering, Design Principles, Approach Design.

Abstract: Enterprise engineering (EE) aims to address several phenomena in the evolution of an enterprise. One

prominent phenomenon is the inability of the enterprise as a complex socio-technical system to adapt to

rapidly-changing environments. In response to this phenomenon, many enterprise design approaches (with

their own methodologies, frameworks, and modelling languages) emerged, but with little empirical evidence

about their effectiveness. Furthermore, research indicates that multiple enterprise design approaches are used

concurrently in industry, with each approach focusing on a sub-set of stakeholder concerns. The proliferating

design approaches do not necessarily explicate their conditional use in terms of contextual prerequisites and

demarcated design scope; and this also impairs their evaluation. Previous work suggested eleven design

principles that would guide approach designers when they design or enhance an enterprise design approach.

The design principles ensure that researchers contribute to the systematic growth of the EE knowledge base.

This article provides a demonstration of the eleven principles during the development of a DEMO-based

enterprise engineering approach, as well as a discussion to reflect on the usefulness of the principles.

1 INTRODUCTION

Enterprise engineering (EE) studies enterprises from

an engineering perspective (Albani and Dietz, 2010)

and addresses the need for a comprehensive view of

the enterprise (Giachetti, 2010; Hoogervorst, 2009;

Kappelman, 2010; Van Tonder and Roodt, 2008). A

recent study focused on defining the domain of the

EE discipline — i.e., identifying the phenomena and

core problems of interest that require research within

the discipline (De Vries, Gerber, and Van der Merwe,

2015). Survey participants of the study highlighted a

prominent phenomenon, namely the inability of an

enterprise, as a complex socio-technical system, to

adapt to rapidly-changing environments (De Vries,

Gerber, et al., 2015). The research also highlighted

the need for appropriate methodologies and

architecture description (using typologies and

modelling languages). Yet, numerous approaches

(including methodologies, frameworks, and

modelling languages) already exist (De Vries, Van

der Merwe, and Gerber, 2015). From a practical

viewpoint, enterprises usually apply a combination of

methodologies to cover several design domains

(Blowers, 2012). The diversity of modelling

languages is not surprising if we recognise that

enterprise stakeholders have different concerns,

which need to be addressed via multiple enterprise

design approaches to deal with the full richness of the

real world (Espejo and Reyses, 2011; Mingers and

Brocklesby, 1997).

The proliferation of enterprise design approaches

however impairs the systematic growth of the EE

knowledge base, since many design approaches do

not necessarily explicate their conditional use,

contextual prerequisites, and demarcated design

scope. Drawing from existing theory on theoretical

enterprise design approaches (De Vries, Van der

Merwe, et al., 2015) and eight components for design

theory in IS (Gregor and Jones, 2007), design

research was used to develop eleven approach design

principles (ADPs) to guide the approach developer

(De Vries, 2016). Although the study applied a focus

group discussion to validate the principles, the

principles had not been applied to a real scenario.

Additional demonstration was needed to further

evaluate the usefulness of the eleven ADPs.

Meulen, T., Vries, M. and Gerber, A.

Demonstrating Approach Design Principles during the Development of a DEMO-based Enterprise Engineering Approach.

DOI: 10.5220/0006382204710482

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 3, pages 471-482

ISBN: 978-989-758-249-3

471

The purpose of this article is to demonstrate the

use of a generic set of ADPs during the development

of a new approach, called the DEMO-based

enterprise engineering approach (DEEA), which had

been applied at a real enterprise. In addition, we

discuss the usefulness of the ADPs.

The article is structured as follow: section 2

provides background on a real enterprise and its need

for a new enterprise design approach, as well as a

summary of eleven ADPs that should guide the

development of new enterprise design approaches.

Section 3 presents the research methodology that was

used to evaluate the ADPs by demonstrating their use.

The demonstration of the ADPs and interview results

are discussed in section 4, followed by a summary of

the results and opportunities for ADP improvement in

section 5. We conclude the article in section 6.

2 BACKGROUND

The main approach developer of DEEA identified the

need to guide enterprise evolution at an agricultural

enterprise, called ZZ2. Management at ZZ2

encourages an open systems approach (evident on the

ZZ2 web site (www.zz2.biz, Vision), which

encourages farmers or other role players to

continuously adapt plans as necessitated by the

dynamic agricultural environment. Based on

discussions with employees, it was evident that ad

hoc and unintegrated designs created frustration,

since the current ad hoc approach failed to identify

and address enterprise design concerns in a holistic

way (Van der Meulen, 2017). The new approach had

to improve the quality of design, which according to

Gause & Weinberg’s (1989), can be defined as the

extent of identifying and addressing relevant

stakeholder requirements for the to-be system.

Van der Meulen (2017) considered a number of

enterprise design approaches to replace the ad hoc

nature of enterprise design with a more holistic,

comprehensive and integrated design process.

Hoogervorst’s (2009) approach was selected as a

good candidate, due to its holistic way of eliciting

stakeholder concerns and related design principles

that would govern the evolution of enterprise design

domains. In addition, requirements are translated into

constructional specifications for the organisation

domain in the form of DEMO models, which are,

according to Dietz (2006), coherent, comprehensive,

consistent and concise.

2.1 Need for an Enhanced Approach

At the start of the study, Hoogervorst’s (2009)

approach was considered as an appropriate approach

for application at ZZ2. Yet, during the

implementation of the approach, especially the

generic enterprise development framework (GEDF)

of Hoogervorst (2016), practical implementation

tools and supporting software were absent. A study

was initiated, using action design research and

guidelines from Sein et al. (2011), to develop the

DEEA (Van der Meulen, 2017). The developer of

DEEA also applied the ADPs of De Vries (2016) to

explicate DEEA’s conditional use in terms of

contextual prerequisites and demarcated design

scope.

2.2 Approach Design Principles

Drawing from existing theory on theoretical

enterprise design approaches (De Vries, Van der

Merwe, et al., 2015) and eight components for design

theory in IS (Gregor et al., 2007), design research was

used to develop eleven approach design principles

(ADPs).

The term design approach features in almost

every principle statement and relates to an enterprise

design approach, designed by an approach developer,

with the intent of guiding the evolution of an

enterprise system or sub-system.

We distinguish between an approach and a

methodology by referring to the four-tier inheritance

structure defined by Iivari, Hirschheim, and Klein

(2001), i.e. paradigms, approaches, methodologies

and techniques.

Furthermore, De Vries (2016) states that an

enterprise design approach is based on a particular

conceptualisation of the enterprise; is designed to

create value for the enterprise; focuses on designing

particular design domains or sub-systems; highlights

particular concerns that may be neglected in other

approaches; and incorporates several mechanisms

and practices that will enable value-creation for the

enterprise.

This section summarises the principles as defined

by De Vries (2016) in terms of a statement and

rationale. The rationale is stated in terms of the main

focus of the ADPs, namely to guide the approach

developer in explicating the conditional use of a

newly-developed approach in terms of its contextual

prerequisites and demarcated design scope (De

Vries, 2016).

The practical components of each ADP (i.e. the

ADP implications and measures) are only presented

AEM 2017 - 1st International Workshop on Advanced Enterprise Modelling

472

in section 4 when we demonstrate their use during the

development of a new enterprise design approach,

called DEEA.

Principle A: Explicit Concept of the Enterprise

Statement: A design approach should indicate how an

enterprise is perceived or conceptualised.

Rationale: Different analogies are used to

conceptualise the enterprise, such as machines,

biological systems, and psychic prisons (De Vries,

Van der Merwe, et al., 2015), which may also differ

from one industry to the next. By explicating the

enterprise conceptualisation(s) the approach author

also acknowledges the limitations of a particular

conceptualisation, as indicated by Morgan (2006).

Principle B: Explicit Phenomenon

Statement: A design approach should provide

evidence for a phenomenon or class-of-problems, i.e.

similar kinds of problems.

Rationale: Phenomena “that are not fully understood

cannot be properly addressed and improved”

(Hoogervorst, 2016, p. 49). Although numerous

approaches may already exist to address a well-

understood phenomenon, there is still a lack of

knowledge about approach performance (De Vries,

Gerber, et al., 2015).

Principle C: Explicit Paradigm of Value Creation

Statement: A design approach should state a

paradigm of value-creation as a testable proposition

for addressing an existing phenomenon or class-of-

problems.

Rationale: Creating testable propositions for existing

and new approaches provides a starting point to

extend the existing EE knowledge base. From a

practitioner’s perspective, the value-creation

paradigm clarifies the intended value of the approach.

Principle D: Explicit Means (Ways) of Demarcating

and Representing Design Scope

Statement: A design approach should clearly define

and motivate the way to demarcate design scope

(enterprise scope, design domains, and

concerns/requirements) relevant to the approach.

Rationale: Demarcation of design scope (enterprise

scope, design domains, concerns/requirements) is

contextual and depends on the intentions (paradigm

of value-creation) of the observer/ analyst (Espejo et

al., 2011; Giachetti, 2010). Thus, acknowledging that

demarcation of design scope will inevitably differ

from one approach author to the next, the approach

author should stipulate the method or theoretical

grounds used for demarcation, which encourages

reflection about the demarcation rigour.

We clarify definitions for enterprise scope, design

domains and concerns.

The enterprise scope provides a dimension to

demarcate the scope of design for a specific approach,

by referring to the internal structures of the enterprise

— e.g., business units, lines of business, departments,

programmes and projects — and the external legal

entities, such as government, partners and suppliers.

The demarcation of design domains depends on

the approach author’s intentions or paradigm of

value-creation. For example, Hoogervorst (2009, p.

134) maintains that the demarcation/delineation of

domains reveals “functional or constructional system

facets for which design activities are required”.

Concerns acknowledge a third way of

demarcating enterprise design scope. Approach

authors highlight particular concerns or areas of

concern/requirements that should be addressed

during enterprise design. For example, Parmenter

(2010) highlights six areas of concern for enterprise

design: financial asset utilisation, operational

performance, customer satisfaction, employee

satisfaction, community engagement, and learning

and growing.

Principle E: Well-demarcated and Well-defended

Design Scope

Statement: A design approach should define and

defend the intended design scope to achieve the

intended value-creation.

Rationale: The new approach should demarcate an

appropriate scope to achieve the intended value-

creation, and relate to existing theory that focuses on

a similar scope.

Principle F: Representations of Design Scope

Statement: A design approach should clearly define

and motivate notation standards that are used to

adequately describe/represent the design scope.

Rationale: Multiple languages and notation standards

already exist to represent different perspectives or

design domains of the enterprise. Yet existing

notation standards are usually based on a particular

notion about the nature of the enterprise and its sub-

systems. The approach author should defend why the

selected language and notation standard is

appropriate within his/her conceptualisation of the

enterprise. A new conceptualisation or notion of the

enterprise may require deviation from existing

notation standards. As an example, the Business

Process Modelling Notation (BPMN) standard may

be used to depict the business organisation domain.

Yet, Dietz (2006) criticizes BPMN for being too

Demonstrating Approach Design Principles during the Development of a DEMO-based Enterprise Engineering Approach

473

implementation-specific and motivates the need for

representing the essence of enterprise operation by

suggesting a new notation standard, i.e. the Design

and Engineering Methodology for Organisations

(DEMO).

Principle G: Approach Form and Function

Statement: A design approach should clearly define

the constructs and features of the approach.

Rationale: The basic design process for any artefact,

including a new design approach, requires both

functional design and constructional design (Dietz

and Hoogervorst, 2007). For a design approach, the

paradigm of value creation represents its function,

whereas constructional parts represent the form. An

artefact, such as a new design approach, can only be

maintained and tailored in future if both its function

and construction/form is known (Dietz et al., 2007).

The four components of EECM provide a meta-model

of typical constructs of existing design approaches.

The third component (mechanisms and practices)

also highlights ten different kinds of constructs that

may form part of an approach.

Principle H: Justificatory knowledge

Statement: A design approach must provide

explanatory knowledge that links the paradigm of

value-creation with its constructional components.

Rationale: The justificatory knowledge provides an

explanation of why an artefact is constructed as it is,

and why it works. Pointers to some kernel theories

would provide researchers and practitioners with

information that would be useful when comparing or

combining approaches. It may also be possible that

new theories are formulated, which cannot be traced

to kernel theories.

Principle I: Approach Mutability

Statement: A design approach should clearly state

possibilities for tailoring the approach, within the pre-

defined design scope.

Rationale: Since the design approach may not have

been demonstrated for multiple instances within the

pre-defined design scope, the designer needs to

identify possibilities for tailoring the approach.

Design approaches need to address the dynamic

nature of the enterprise and its environment, which is

also a key concern within the EE discipline (De Vries,

Gerber, et al., 2015).

Principle J: Principles of implementation

(conditional)

Statement: A design approach may incorporate

guidance for implementing the approach.

Rationale: This principle is conditional, since the

designer needs to consider the pre-defined design

scope and decide whether additional advice would

add value, e.g. additional advice may be required if

the approach has been designed for the health

industry. Even for other industries, the designer may

need to provide additional advice to indicate how the

approach should be used in specific contexts.

Principle K: Expository Instantiation (Optional)

Statement: A design approach may incorporate an

instantiation.

Rationale: This principle is optional. A realistic

implementation of an approach contributes to the

identification of potential problems in its design, also

demonstrating its worth. Even though the designer

should have implemented the approach to evaluate its

utility, the implementation results do not necessarily

form part of the construction of the design approach.

3 RESEARCH METHODOLOGY

Design research acknowledges the development of

principles as a valid form of knowledge contribution

(Hevner et al., 2004). Previous research applied the

first three phases of the design research (DR) cycle of

Peffers, Tuunanen, Rothenberger, and Chatterjee

(2008), i.e. (1) identify the problem, (2) define the

objectives of the solution, and (3) develop the

solution, which was a set of eleven ADPs. The ADPs

were also validated via a focus group discussion.

This article focuses on the subsequent steps of

Peffer et al.’s (2008) DR cycle, namely

(4) demonstration, i.e. finding a suitable context for

demonstrating the ADPs, and (5) evaluation, i.e.

evaluating the usefulness of the ADPs.

In terms of demonstration, an approach

developer, who was not the developer of the ADPs,

applied the ADPs when he developed a new

approach, called DEEA. He documented the

application of the ADPs as part of a Masters

dissertation. For evaluation, the ADP’s developer

followed the guidelines of Marshall and Rossman

(2011) to perform an in-depth 3-hour interview with

the user of the ADPs. The interview was structured to

inquire about every ADP, especially how the

implications and measures were interpreted and

applied by the APD user. The interview allowed for

additional inquiry where the ADP user applied a

different interpretation than was intended (see

Section 4.4). Finally, the interview feedback,

presented per ADP, was sent to the interviewee for

validation and additional inputs.

AEM 2017 - 1st International Workshop on Advanced Enterprise Modelling

474

The next section presents DEEA in terms of the

eleven ADPs, i.e. demonstrating how the ADP’s

implications and measures were applied during the

development of DEEA. In addition, we provide

feedback per ADP regarding the use of its

implications and measures, based on the interview

feedback from the interviewee.

4 DEMONSTRATION OF

PRINCIPLES

This section presents each principle in terms of the

ADP implications and measures, followed by their

application during the development of DEEA and

interview feedback from the approach developer.

During the interview feedback, the approach

developer had to reflect on the usefulness of the

particular ADP, highlighting opportunities for further

improvement.

4.1 Principle A: Explicit Concept of the

Enterprise

Implications:

• Provide a description of the enterprise, using

analogies.

• Provide a motivation, also referring to

supporting theory, for using the particular

enterprise conceptualisation.

Measures: No additional measures.

Principle Application

Since DEEA was based on Hoogervorst’s approach,

his conceptualisation of the enterprise was also

adopted, namely that the enterprise resembles an

organised complexity, which should be purposefully

designed. DEEA also adopted the notion that an

enterprise is a heterogeneous system that consists of

many sub-systems in accordance with Dietz (2006).

Furthermore, the sub-systems are often constructed as

to support one another, e.g. ICT systems are

constructed to support the operation of the enterprise.

Interview Feedback

The interviewee indicated that the ADP implications

were sufficient. However, he commented that one of

the prerequisites for applying a particular approach is

that management had to appreciate the enterprise

conceptualisation, which would ensure buy-in and

active participation. As an example, management at

ZZ2 also adopted a systems notion of the enterprise.

More so, they used a similar conceptualisation of an

enterprise object system that needs to be constructed

in support of a using system. Hoogervorst’s

conceptualisation of the enterprise correlated with

ZZ2’s paradigm of an organised complexity, which

would also allow buy-in from ZZ2.

Furthermore, an entomologist at ZZ2 referred to

Aristotle’s belief that even nature is teleological,

since nature serves ends (see Lloyd (1968)), which

compares well with the notion of an object system

that serves a using system.

4.2 Principle B: Explicit Phenomenon

Implications:

• Produce sufficient evidence that an existing

phenomenon or class-of-problems exists, but

that it is inadequately addressed by existing

theory or theory application.

Measures: No additional measures.

Principle Application

The study was initiated by identifying a problem

instance at ZZ2, which was then validated as a class-

of-problems from a theoretical viewpoint. The

problem instance at ZZ2 is that the enterprise

developed in an ad hoc way to accommodate the

dynamic environment of the agricultural industry. An

industrial engineer that practiced in an agricultural

environment for more than nine years stated: “I do not

even want to begin thinking about putting this

company into circles and rectangles”. Due to its

dynamic nature, the agricultural enterprise cannot be

represented with the same rigour than a nuclear power

station or a financial department.

This problem instance features as a class-of-

problems in literature. Since the farming industry is

dependent on many variables such as temperature,

rainfall, wind, soil diseases and other natural or

political factors, it becomes a very complex

environment to implement system standardisation or

design techniques with the intent of gaining more

control (Nuthall, 2011). Geng, Ren, and Wang (2007)

state that it is difficult to implement IT solutions in

the agricultural environment, since there is a lack of

standard measures. In addition, produce is diverse and

difficult to handle. Wolfert et al. (2010) state that

agricultural companies need to constantly innovate to

be able to survive in the complicated and dynamic

agri-food environment.

According to the developer of DEEA, current

theory existed to provide some design guidance

within a dynamic agricultural environment. Whereas

systems engineering was too generic to provide

design guidance for an enterprise, Hoogervorst’s

(2009, 2016) approach acknowledges enterprise

Demonstrating Approach Design Principles during the Development of a DEMO-based Enterprise Engineering Approach

475

dynamics and focuses on holistic enterprise design

and representation of organisation construction in a

coherent, comprehensive, consistent and concise way

(Van der Meulen, 2017). Yet, an application of

Hoogervorst’s approach indicated practical gaps. An

approach was required to facilitate ease-of-

understanding when eliciting enterprise requirements

from employees with an agricultural background. In

addition, requirements and enterprise designs had to

be traceable and documented in an unambiguous way.

Interview Feedback

Although the approach developer adhered to the ADP

implications, the implications focuses too much on

the identification of a class-of-problems. The

implications should rather focus on the identification

of a problem instance, prior to its generalisation as a

class-of-problems.

4.3 Principle C: Explicit Paradigm of

Value Creation

Implications:

• State the intended paradigm of value-creation in

terms of a testable proposition, which may be in

the form ‘If approach X is instantiated, then it

will achieve the intended value, or it will be

better in some way than other approaches’.

Measures: No additional measures.

Principle Application

If DEEM is instantiated, then it will:

• Generate a concept of the enterprise in an

integrated manner for a particular design

scope of interest,

• Address stakeholder concerns from a

holistic point of view,

• Ensure ease-of-understanding for

employees with an agricultural background

during enterprise requirements elicitation,

and

• Represent enterprise requirements and

conceptual to-be construction in an

unambiguous way.

Interview Feedback

The ADP implications are sufficient.

4.4 Principle D: Explicit Means (Ways)

of Demarcating and Representing

Design Scope

Implications:

• Define the way to demarcate design domains

(e.g., using systems theory or demarcation

heuristics).

• Define the way to demarcate concerns per

design domain (e.g., using generic areas of

concerns from theory or using heuristics to

identify concerns).

Measures: No additional measures.

Principle Application

• Way to demarcate design domains: DEEA

applied the basic systems design process

delineated in Dietz (2006) to define domains

that have supportive relationships, e.g. the

information domain (i.e. the object system)

supports the organisation domain (i.e. the using

system).

• Way to demarcate concerns per design domain:

DEEA applied Hoogervorst’s (2016) heuristics,

embedded in the generic system development

framework, to elicit areas of concern and

enterprise requirements.

Interview Feedback

Although the approach developer was able to define

the means of demarcation, as stipulated under

Principle Application, he initially defined DEEA’s

design domains, rather than their means of

demarcation. The ADP should explain the phrase

“means of demarcating”.

4.5 Principle E: Well-Demarcated and

Well-defended Design Scope

Implications:

• Identify the overall scope of the approach —

i.e., focusing on inside-the-boundary

complexities versus outside-the-boundary

complexities.

• Identify the scope of the approach in terms of

design domains that will be addressed by the

approach.

• Identify the scope of the approach in terms of

areas of concern for different stakeholders that

will be addressed.

• Use additional ways of scoping to define the

context for which the approach is intended —

e.g., a specific industry.

AEM 2017 - 1st International Workshop on Advanced Enterprise Modelling

476

• Indicate the actual implementation scope used to

demonstrate the approach.

• Identify the role players, especially the main

users of the approach.

Measures:

• Is the scope described in such a way as to relate

to existing theory that covers a similar design

scope?

• Is the scope described in such a way as to know

whether an application context falls within the

scope of the approach?

Principle Application

• Overall scope of the approach: DEEA focuses

on inside-the-boundary complexities rather than

outside-the-boundary complexities.

• Design domains scope: DEEA provides a

method to design three design domains, i.e.

organisation, information and infrastructure.

The rationale and demarcation of the designs are

discussed in Van der Meulen (2017).

• Areas of concern: DEEA is not prescriptive on

the areas of concern that should be addressed,

but rather applies the generic system

development framework to identify enterprise-

specific areas of concern.

• Industry: DEEA should be applicable to

different industries, but has only been evaluated

within the agricultural industry.

• Other means of scope demarcation: DEEA

applies the system life cycle model of

Kossiakoff et al. (2011) and only incorporates

the concept development stage. In future, DEEA

may have to be extended for the other stages as

well.

• Role players: DEEA should be used by

enterprise engineers and their design teams.

Although other stakeholders may contribute

towards the identification of areas of concerns

and requirements, they are not users of DEEA.

Interview Feedback

The ADP implications and measures are sufficient.

4.6 Principle F: Representations of

Design Scope

Implications:

• Define notation standards that are used to

describe design domains.

• Motivate any deviation from existing standards.

Measures: No additional measures.

Principle Application

DEEA applied the following notation standards per

design domain:

• Organisation design domain: DEMO’s aspect

models.

• Information design domain: Entity relationship

models.

• Infrastructure design domain: Process flows

with concept technologies and wire frames to

model concept interfaces and concept

technologies.

Interview Feedback

The ADP implications are sufficient.

4.7 Principle G: Approach Form and

Function

Implications:

• Define the overall structure and organisation of

the approach.

• Define the mechanisms and practices explicitly,

stating their form (conceptual parts) and

function, ensuring that their interpretation is

clear.

• Define how the mechanisms and practices are

related to one another.

• Define the roles involved when using the

mechanisms and practices.

Measures:

• Are the structures described comprehensively

enough to be useful and transferable?

• Did you validate the interpretation of the

mechanisms and practices (their form and

function) with appropriate research

participants?

• For each mechanism or set of practices, is it

clear which roles are involved?

Principle Application

• Structure and organisation of the approach:

DEEA is organised into two main parts,

introduction and constructs. The introduction

part describes the function, scope, users and

prerequisites of DEEA, whereas the constructs

part presents the mechanisms and practices that

form part of DEEA.

• Mechanisms and practices: DEEA incorporates

a method that consists of three main steps,

illustrated in Figure 1: (1) Analyse Needs, (2)

Determine Starting Point, and (3) Design a

Design Domain. The documented DEEA also

presents additional mechanisms, namely a code

Demonstrating Approach Design Principles during the Development of a DEMO-based Enterprise Engineering Approach

477

book, requirements database, DEMO aspect

models, entity relationships models, flow

diagrams and wire frames (See Van der Meulen

(2017).

• Relationships of mechanisms and practices: The

relationships of the mechanisms and practices

are graphically portrayed in Van der Meulen

(2017).

Roles involved when using the mechanisms and

practices: DEEA is not prescriptive on the roles

that are involved, since it has not been tested

with a dedicated EE team. Yet, DEEA could be

further enhanced in future to prescribe roles.

Interview Feedback

• The ADP implications and measures are

sufficient. However, more guidance should be

provided to ensure that the structure addresses

the ADPs.

Figure 1: Reduced illustration of DEEA.

4.8 Principle H: Justificatory

Knowledge

Implications:

Define kernel theories on which the approach and its

components are based, and on how they are related to

different components of the approach.

Measures: No additional measures.

Principle Application

The components of DEEA are based on existing

theoretical works, which are discussed in Van der

Meulen (2017). Prominent works include: the system

life cycle model of Kossiakof et al. (2011), the

generic system development framework of

Hoogervorst (2016) and DEMO of Dietz, as

presented in Perinforma (2015). DEMO has its roots

in the theory of communicative action of

Habermas (1984), the speech act theory of Searle

(1969) and systemic ontology of Bunge (1979).

Interview feedback

The ADP implications are sufficient.

4.9 Principle I: Approach Mutability

Implications:

Define foreseeable changes — i.e., approach

constructs that will change, and the kinds of change

that would be required.

Measures:

• Are conditions for changes described?

• Is it clear which parts could possibly change and

to what they could change?

• Are possibilities for tailoring the approach

defined to enable extension of the approach in

future?

Principle Application

DEEA provides various scenarios for enterprise

design, as well as the associated method tailoring. In

addition, advice is offered regarding DEEA’s

extension beyond the concept development stage of

Kossiakof’s life cycle development model (Van der

Meulen, 2017).

Interview feedback

The ADP implications are sufficient.

4.10 Principle J: Principles of

Implementation (Conditional)

Implications:

• Define tailoring advice.

• Define advice regarding introduction into real-

life settings.

Measures:

Does the advice for implementing the approach cover

different settings within the scope, or is it at least clear

about the scope to which it applies?

Principle Application

DEEA does not provide additional advice on

implementation, since the discussion on alternative

tailoring scenarios was deemed sufficient.

Interview feedback

The interviewee commented that ADP I and J seem

to overlap. An alternative interpretation of ADP J is

that an approach user manual should be constructed

to guide the approach user and improve the usability

AEM 2017 - 1st International Workshop on Advanced Enterprise Modelling

478

of the newly-designed approach.

4.11 Principle K: Expository

Instantiation (Optional)

Implications:

• Report on a real-life implementation of the

approach.

Measures:

• Does the implementation cover a case within the

scope, and is it covering the main mechanisms

and practices of the approach?

• Is the implementation specific enough to be

illustrative?

Principle Application

A real-life demonstration of DEEA is presented in

Van der Meulen (2017) to design the concept for a to-

be post-harvest system. The demonstration covers a

case in scope, covers all mechanisms and practices

and provides a realistic demonstration of DEEA.

Interview feedback

The ADP implications and measures are sufficient.

5 RESULTS SUMMARY

According to the interviewee, the ADPs were useful

in terms of their implications and measures. Yet, he

indicated that 5 of the 11 principles could be further

enhanced, namely ADPs A, B, D, G and J. Section 5.1

summarises the interview results, whereas section 5.2

presents opportunities for further enhancement of the

ADPs.

5.1 Summary of Interview Results

Principle A: Explicit Concept of the Enterprise

The approach developer indicated that the ADPs do

not highlight the necessity for stating prerequisites for

using a particular approach.

Principle B: Explicit Phenomenon

The ADP implications should focus on the

identification of a problem instance, prior to its

generalisation as a class-of-problems.

Principle D: Explicit Means (Ways) of Demarcating

and Representing Design Scope

The approach developer initially defined DEEA’s

design domains, rather than their means of

demarcation. The ADP should explain the phrase

“means of demarcating”.

Principle G: Approach Form and Function

More guidance should be provided to ensure that the

approach structure addresses the ADPs.

Principle J: Principles of implementation

(conditional)

ADP I and J seem to overlap. An alternative

interpretation of ADP J is that an approach user

manual should be constructed to guide the approach

user and improve the usability of the newly-designed

approach.

5.2 Opportunities for Improvement

Based on the feedback from the approach developer,

the following suggestions are made to improve the

ADPs.

Principle A: Explicit Concept of the Enterprise

Refer to ADP E and ADP G, which address the

approach developer’s feedback.

Principle B: Explicit Phenomenon

Implications should focus on the identification of a

problem instance, prior to its generalisation as a

class-of-problems. The implications may be adapted

as follows:

Implications:

• Produce evidence that a problem instance exists

at a real enterprise. The problem instance should

be an enterprise engineering type of problem.

• Produce sufficient evidence that the problem

instance also features as an existing

phenomenon or class-of-problems in literature,

but that it is inadequately addressed by existing

theory or theory application.

Measures: No additional measures.

Principle D: Explicit Means (Ways) of Demarcating

and Representing Design Scope

The ADP should explain the phrase “means of

demarcating”.

Implications:

• Define the way to demarcate design domains.

As an example, the basic systems design process

delineated in Dietz (2006) may be used as the

means to define design domains that have

supporting relationships, e.g. the ICT

domain/class-of-systems supports the

organisation domain/class-of-systems.

• Define the way to demarcate concerns per

design domain (e.g., using generic areas of

Demonstrating Approach Design Principles during the Development of a DEMO-based Enterprise Engineering Approach

479

concerns from theory or using heuristics to

identify concerns). As an example, Hoogervorst

(2016) provides a heuristic, linked to the generic

system development framework, to elicit

enterprise-specific areas of concern and

enterprise requirements.

Measures: No additional measures.

Principle E: Well-demarcated and Well-defended

Design Scope and Using Scope

The principle description should be extended to

include the phrase “and using scope”. In addition, the

implications should also be adapted to reflect the

extension.

Implications:

• Identify the overall scope of the approach —

i.e., focusing on inside-the-boundary

complexities versus outside-the-boundary

complexities.

• Identify the scope of the approach in terms of

design domains that will be addressed by the

approach.

• Identify the scope of the approach in terms of

areas of concern for different stakeholders that

will be addressed.

• Use additional ways of scoping to define the

context for which the approach is intended —

e.g., a specific industry.

• Indicate the actual implementation scope used to

demonstrate the approach.

• Identify the role players, especially the main

users of the approach.

• Specify the using scope by defining

prerequisites. An example of a prerequisite is

that the approach should only be considered for

implementation if management has a similar

conceptualisation of the enterprise than

delineated in the approach.

Measures:

• Is the scope described in such a way as to relate

to existing theory that covers a similar design

scope?

• Is the scope described in such a way as to know

whether an application context falls within the

scope of the approach?

Principle G: Approach Form and Function

We suggest that ADP G should mandate inclusion of

an approach component that explicitly states

prerequisites for applying the newly-developed

approach, also providing an example of a

prerequisite. In addition, more guidance should be

provided to ensure that the approach structure

addresses the ADPs. The implications and measures

may be adapted as follows:

Implications:

• Define the overall structure and organisation of

the approach and ensure to address the relevant

ADPs.

• A suggested structure is depicted in Table 1,

also relating to the ADPs that should be

addressed. The principles that are omitted (H

and K), should not be incorporated as structural

parts of the newly-designed approach.

• The overall structure should incorporate the

approach function (i.e. Introduction part) and

form (i.e. Mechanisms and practices part).

Table 1: Suggested structure for a design approach.

Structural parts ADPs

Introduction

Objectives and intended value A, B, C

Scope D, E, F

Users E

Prerequisites E

Mechanisms and practices G

Approach tailoring I

User guidance (conditional) J

• Define the mechanisms and practices explicitly,

which encapsulates the approach form. The

mechanisms and practices should also be

detailed in terms of their form (conceptual parts)

and function, ensuring that their interpretation is

clear.

• Ensure that mechanisms and practices are

sufficient to address the objectives and intended

value of the approach.

• Define how the mechanisms and practices are

related to one another.

• Define the roles involved when using the

mechanisms and practices.

Measures:

• Are the structures described comprehensively

enough to be useful and transferable?

• Did you validate the interpretation of the

mechanisms and practices (their form and

function) with appropriate research

participants?

• For each mechanism or set of practices, is it

clear which roles are involved?

Principle J: Principles of implementation

(conditional)

We suggest that ADP J highlights additional advice

for implementation, rather than providing advice on

AEM 2017 - 1st International Workshop on Advanced Enterprise Modelling

480

tailoring the approach. The implications may be

adapted as follows:

Implications:

• Define advice regarding introduction into real-

life settings.

• Compile a user manual for using the newly-

designed approach, including examples.

Measures:

Does the advice for implementing the approach cover

different settings within the scope, or is it at least clear

about the scope to which it applies?

6 DISCUSSIONS AND

CONCLUSIONS

Previous work applied design research to develop

eleven ADPs which needed additional demonstration

and evaluation (De Vries, 2016). The ADPs were

developed to guide the approach developer in

explicating the conditional use of a newly-developed

approach in terms of its contextual prerequisites and

demarcated design scope (De Vries, 2016). The

ADPs thus primarily have an academic value to

encourage systematic growth of the EE knowledge

base.

This article presented a demonstration of the

ADPs, since they were used during the development

of a new approach, called the DEMO-based

enterprise engineering approach (DEEA). In addition,

we evaluated the usefulness of the ADPs, using an in-

depth interview to inquire about every ADP,

especially how the ADP user interpreted and applied

the ADP implications and measures.

The ADPs currently have an academic focus,

ensuring that new/enhanced enterprise design

approaches are explicated in terms of their

demarcated design scope, contextual prerequisites

and their conditional use. In terms of the stated

academic focus, the evaluation feedback was positive

and useful to suggest a number of opportunities for

extending the current ADPs. However, when an

approach developer identifies a

phenomenon/problem that may be addressed by

developing a new design approach, the ADPs alone

will not provide sufficient guidance for the

development endeavour. Thus, although the approach

developer of DEEA applied the ADPs during

approach development, he also required additional

guidance, e.g. using guidelines from Sein et al. (2011)

on action design research, to develop DEEA.

Future applications of the extended ADPs will

further increase the rigour of the ADPs. It is possible

that developers of new approaches, such as

ambidextrous BPM, will identify valid reasons for

adapting the existing ADPs or identifying additional

ADPs.

De Vries and Berger (2016) also provide

additional guidance on appropriate research methods

for enterprise approach design, highlighting action

design research, whereas Venable et al. (2016)

provide guidance for evaluating design science

research.

ACKNOWLEDGEMENTS

The authors would like to thank the management of

ZZ2 for the opportunity to demonstrate and use

DEEA within the enterprise and their consent for

documenting the findings. We would like to convey

our gratitude towards Johannes Grobler who

supported the project for redesigning the post-harvest

system from the start.

REFERENCES

Albani, A., Dietz, J. L. G. 2010. Preface. In Albani, A. and

Dietz, J. L. G. (Eds.), Advances in Enterprise

Engineering IV. Berlin, Heidelberg: Springer.

Blowers, M. 2012. Hybrid enterprise architecture

frameworks are in the majority. Retrieved from

http://ovum.com/2012/03/22/hybrid-enterprise-

architecture-frameworks-are-in-the-majority/

Bunge, M. A. 1979. Treatise on basic philosophy, Vol. 4: a

world of systems. Dortrecht: Reidel Publishing

Company.

De Vries, M. 2016. Guiding the development of enterprise

design approaches. South African Journal of Industrial

Engineering, 27(3), 12-22. Retrieved from

http://sajie.journals.ac.za/pub

De Vries, M., Berger, S. 2016. An action design research

approach within enterprise engineering. Systematic

Practice and Action Research. doi:10.1007/s11213-

016-9390-7

De Vries, M., Gerber, A., Van der Merwe, A. 2015. The

enterprise engineering domain. In Aveiro, D., Pergl, R.,

and Valenta, M. (Eds.), Advances in Enterprise

Engineering IX (pp. 47-63). Switzerland: Springer.

De Vries, M., Van der Merwe, A., Gerber, A. 2015.

Extending the enterprise evolution contextualisation

model. Enterprise Information Systems, doi:

10.1080/17517575.2015.1090629,

http://www.tandfonline.com/doi/pdf/10.1080/1751757

5.2015.1090629.

Dietz, J. L. G. 2006. Enterprise ontology. Berlin: Springer.

Dietz, J. L. G., Hoogervorst, J. A. P. 2007. Enterprise

ontology and enterprise architecture - how to let them

evolve into effective complementary notions. GEAO

Journal of Enterprise Architecture, 1.

Demonstrating Approach Design Principles during the Development of a DEMO-based Enterprise Engineering Approach

481

Espejo, R., Reyses, A. 2011. Organisational systems.

Berlin Heidelberg: Springer-Verlag.

Gause, D. C., Weinberg, G. M. 1989. Exploring

requirements: quality before design. New York: Dorset

House Pub.

Geng, S., Ren, T.-z., Wang, M.-h. 2007. Technology and

Infrastructure Considerations for E-Commerce in

Chinese Agriculture. Agricultural Sciences in China,

6(1), 1-10. doi:http://dx.doi.org/10.1016/S1671-

2927(07)60010-8

Giachetti, R. E. 2010. Design of enterprise systems. Boca

Raton: CRC Press.

Gregor, S., Jones, D. 2007. The anatomy of a design theory.

J Assoc Inf Syst, 8(5), 312-335.

Habermas, J. 1984. The theory of communicative action:

Reason and the realization of society. Boston: Beacon.

Hevner, A. R., March, S. T., Park, J., Ram, S. 2004. Design

science in information systems research. MIS

Quarterly, 28(1), 75-105. Retrieved from

http://wise.vub.ac.be/thesis_info/design_science.pdf

Hoogervorst, J. A. P. 2009. Enterprise governance and

enterprise engineering. Diemen: Springer.

Hoogervorst, J. A. P. 2016. On the realization of strategic

success: A paradigm shif needed: Enterprise

governance and enterprise engineering as essential

concepts. Antwerp: Antwerp Management School.

Iivari, J., Hirschheim, R., Klein, H. K. 2001. A dynamic

framework for classifying information systems

development methodologies and approaches. Journal

of Management Information systems, 17(3), 179-218.

Kappelman, L. A. 2010. The SIM guide to enterprise

architecture. Boca Raton: CRC Press.

Kossiakoff, A., Weet, W. N., Seymour, S., Biemer, S. M.

2011. Systems engineering principles and practice (2nd

ed.). New Jersey: John Wiley & Sons.

Lloyd, G. E. R. 1968. Aristotle: the Growth and Structure

of his Thought. Cambridge: Cambridge University

Press.

Marshall, C., Rossman, G. B. 2011. Designing qualitative

research (5

ed.). California: Sage Publications.

Mingers, J., Brocklesby, J. 1997. Multimethodology:

towards a framework for mixing methodologies.

Omega, 25(5), 489-509.

Morgan, G. 2006. Images of organisations. Thousand

Oaks: Sage Publications.

Nuthall, P. L. 2011. Farm business management: analysis

of farming systems: CABI.

Parmenter, D. 2010. Key performance indicators:

developing, implementing and using winning KPI's

(2nd ed.). Hoboken: John Wiley & Sons.

Peffers, K., Tuunanen, T., Rothenberger, M., Chatterjee, S.

2008. A design science research methodology for

information systems research. Journal of MIS, 24(3),

45-77.

Perinforma, A. P. C. 2015. The essence of organisation 2.0.

Netherlands: Sapio.

Searle, J. R. 1969. Speech acts, an essay in the philosophy

of language. Cambridge MA: Cambridge University

Press.

Sein, M., Henfredsson, O., Purao, S., Rossi, M., Lindgren,

R. 2011. Action design research. Management

Information Systems Quarterly, 35(1), 37-56.

Van der Meulen, T. (2017). Towards a Useful DEMO-

based Enterprise Engineering Methodology,

Demonstrated at an Agricultural Enterprise.

Unpublished., University of Pretoria.

Van Tonder, C. L., Roodt, G. 2008. Organisation

development: theory and practice. Pretoria: Van Schaik

Publishers.

Venable, J., Pries-Heje, J., Baskerville, R. 2016. FEDS: A

framework for evaluation in design science research.

European Journal of Information Systems, 25(1), 77-

89. Retrieved from http://www.palgrave-

journals.com/ejis/journal/v25/n1/full/ejis201436a.html

Wolfert, J., Verdouw, C. N., Verloop, C. M., Beulens, A. J.

M. 2010. Organizing information integration in agri-

food—A method based on a service-oriented

architecture and living lab approach. Computers and

Electronics in Agriculture, 70(2), 389-405.

doi:http://dx.doi.org/10.1016/j.compag.2009.07.015

AEM 2017 - 1st International Workshop on Advanced Enterprise Modelling

482