CONSTRUCTING EVOLVABLE ENTERPRISE IMPLEMENTATIONS

Philip HuysmansDepartment of Management Information Systems, University of Antwerp, Prinsstraat 13, B-2000 Antwerp, Belgium

Keywords: Enterprise ontology, Normalized systems, Enterprise architecture.

Abstract: Contemporary organizations are operating in increasingly volatile environments. Hence, organizations must beagile in order to be able to quickly adapt to changes in its environment. This may be a complex process, sincea change to one organizational unit may affect other units. Given the increasing complexity of organizations,it has been argued that organizations should be purposefully designed. Enterprise architecture frameworksprovide guidance for the design of organizational structures. Unfortunately, current enterprise architectureframeworks have a descriptive, rather than a prescriptive nature and do not seem to have a strong theoreticalfoundation. In software engineering literature, the Normalized Systems approach has recently been proposedto provide such deterministic design principles for the modular structure of software. The Normalized Systemsapproach is based on the systems theoretic concept of stability to ensure the evolvability of information sys-tems. In our PhD research, we explore the feasibility of extending the Normalized Systems design principlesto the field of enterprise architecture. Our results show that such approach is feasible and illustrate how thesystems theoretic concept of stability can be used on the organizational level.

1 INTRODUCTION

In today’s economy, innovation plays an increasinglyimportant role in the strategy of organizations. Sinceorganizations nowadays have to compete on a globallevel, it is important that organizations are able to gen-erate and exploit innovations at a steady pace to seeksustainability of their business (Van de Ven and An-gle, 2000). There is consensus in literature that in-formation technology (IT) is an important enabler forinnovation (Brynjolfsson and Saunders, 2010). Giventhe importance of innovation to organizations, it is im-portant that managers understand and are able to ef-fectively manage the innovation process. It has indeedbeen noted that “[a]t a time when so much attention isgiven to innovation and entrepreneurship, it is ratherpathetic that a deep understanding of the process islacking. It is no wonder that firms and governmentshave difficulty trying to stimulate (and manage) inno-vation when its fundamental processes are so poorlyunderstood.” (Teece, 1987, p. 3). Although substan-tial progress has been made in this field, it remains re-markable that almost 25 years later, much innovationin organizations is still dependent on heuristic knowl-edge of employees, and is not based on methods ortheories that explain and provide guidance in this pro-cess. As a result, the innovation process is frequentlyconsidered a black box in which it remains unclear

how a certain input results in the observed outcome(Van de Ven and Angle, 2000; Aghion and Tirole,1994; Fagerberg, 2005).

Innovation can take various forms. In our re-search, we are concerned with the ability to change or-ganizational elements (e.g., structures, processes andpeople). The recent research efforts in the enter-prise architecture domain are very relevant in this re-gard. The goal of the enterprise architecture domainis to construct organizations that are able to conducttheir business in a more efficient and effective man-ner. Several enterprise architecture frameworks havebeen proposed in literature that try to make the com-plexity of organizations more manageable by the useof a systematic approach. Most of these frameworksacknowledge the importance of aligning the IT infras-tructure with the enterprise architecture (Zachman,1987; The Open Group, 2003; Chan et al., 1997). AnIT architecture which is aligned with the enterprise ar-chitecture contributes to diverse business goals, suchas a reduced time to market, the entering of new mar-kets, and support for improved business processes(Kazman and Bass, 2005).

Enterprise architecture frameworks are currentlyfaced with two important challenges. First, a short-coming of many enterprise architecture frameworksis that they have a descriptive, rather than prescriptivenature (Hoogervorst, 2009). From an innovation man-

521Huysmans P. (2010).CONSTRUCTING EVOLVABLE ENTERPRISE IMPLEMENTATIONS.In Proceedings of the 5th International Conference on Software and Data Technologies, pages 521-531DOI: 10.5220/0003047605210531Copyright c© SciTePress

agement point-of-view, this means that these frame-works are unable to open the black box of the innova-tion process within the organization. Although suchframeworks are able to describe the original and therevised structure of the organization, it remains un-clear why the applied changes resulted in a desirableoutcome for the organization. This insight is essentialto be able to repeat the process in the future. Hence,enterprise architecture frameworks should allow forrepeatability and reproducibility. Repeatability refersto whether the approach would lead to the same re-sults if it was repeated in the same context. Repro-ducibility refers to whether the approach would leadto the same results if it was repeated in a different con-text (e.g., in a different organization or with differentpeople).

A second challenge is that organizations are com-peting in increasingly volatile environments. In suchenvironments, it is important that organizations canquickly adapt to changes in their environment. It hasbeen noted that in such contexts, no long-term com-petitive advantages can be obtained, and that organi-zations need to strive towards realizing a successionof short-term competitive advantages (Teece et al.,1997; Eisenhardt and Martin, 2000). Hence, even iforganizations succeed to innovate with IT, they willneed to ensure that the IT and enterprise architectureis flexible enough to adapt to a changing environment.This requires that models created by enterprise archi-tecture frameworks are evolvable. Evolvability is animportant property of an architecture. As mentionedby Garlan and Perry: “software architecture can ex-pose the dimensions along which a system is expectedto evolve. By making explicit the load-bearing wallsof a system, system maintainers can better understandthe ramifications of changes, and thereby more accu-rately estimate the cost of modifications.” (Garlan andPerry, 1995).

2 RESEARCH GOALS

In our research, we work towards (parts of) a methodto guide the implementation of an organization in anevolvable structure. Scientific approaches are objec-tively developed, tested, and verified. Consider forexample the second challenge addressed in the in-troduction: the volatility of contemporary markets.Given this volatility, we believe it is better to fo-cus on the evolvability of organizational structures,instead of optimizing a given structure against cur-rent requirements. Therefore, we will select exist-ing scientific concepts such as systems theoretic sta-bility to assess the quality of proposed structures.

We will base our method on approaches which sharethis perspective. More specifically, our approach willbe based on Normalized Systems, which introducedsystems theoretic evolvability and stability in IT ar-chitectures. According to the Normalized Systemsapproach, IT evolvability is hindered by combina-torial effects (Mannaert and Verelst, 2009). Com-binatorial effects occur when implementing changesrequire increasing effort as the IT system grows.Normalized Systems ensures that combinatorial ef-fects in software systems can be avoided by adher-ing to its four design principles. Such systems ex-hibit systems theoretic stability towards a set of an-ticipated changes. Anticipated changes can be imple-mented without causing combinatorial effects. How-ever, these changes are formulated at the softwarelevel. In this research, we argue that combinatorialeffects affect the organizational level as well. Whena change needs to be applied to organizational ele-ments, such as processes or people, implementationcan be hindered by the dependencies on other orga-nizational elements. Therefore, in order to attain or-ganizational evolvability, these combinatorial effectsshould be avoided. In order to avoid combinatorialeffects, relevant organizational elements should beidentified. Guidance on how these elements should becombined in order to implement an evolvable organi-zation needs to be provided. Ideally, such guidance isdistilled into principles, which need to be adhered towhen implementing an organization. In our research,we consider these principles as the most important as-pect of an enterprise architecture. Consequently, theuse of an enterprise architecture aids the white-boxview on organizational change and facilitates the im-plementation of innovations.

Therefore, our research concerns the design of(parts of) an enterprise architecture which guides theimplementation of an organization which is stableagainst anticipated changes.

3 RELATED WORK

On the practical level, our research topic can be po-sitioned within the field of enterprise architectures.On the scientific level, we build upon the Normal-ized Systems and Enterprise Ontology theories. Inthis section, we introduce the relevant aspects of theseapproaches for our research.

3.1 Enterprise Architecure

In order to be able to comprehend and manage thecomplexity of modern organizations, enterprise ar-

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

522

chitecture frameworks have been introduced. Theseframeworks usually distinguish between the businesssystem and the information system. The business sys-tem consists of elements such as goals, people, pro-cesses, data and events. These elements are usuallyplaced on a horizontal axis. A core model providesan overview of these elements on an abstract level.Such a model describes the scope of the enterprisearchitecture, while abstracting away the the concreteorganizational elements (Ross et al., 2006).

By specifying conceptual models for the elements,requirements for the supporting information systemare formed. The integration between the conceptualmodels should facilitate the translation of a singlechange in the outside world to all the different aspectsof the organization. As such, the models are translatedfrom abstract business concepts to concrete informa-tion system artefacts. The vertical axis usually spec-ifies certain layers or steps in which this translationoccurs. Despite the common goal of enterprise ar-chitectures, many different frameworks are available.Various authors (e.g. (Kozina, 2006; Leist and Zell-ner, 2006; Op t Land, 2008)) have compared theseframeworks and identified differences and similari-ties. The GERAM framework (Generalized Enter-prise Reference Architecture and Methodology) wascreated to provide a reference framework onto whichthe individual frameworks could be mapped. Giventhe broad scope covered by these frameworks andthe multitude of frameworks, it is logical that not ev-ery framework contains all elements present in otherframeworks. Should an enterprise architect require touse all available elements, several (complementary)frameworks can concurrently be used, or a particu-lar framework can be extended (as reported by, e.g.,(Pereira and Sousa, 2004)).

However, by combining or extending existingframeworks, the issue of integration becomes evenmore complex. While most frameworks reduce the in-herent complexity of an organization by offering sep-arate views, it is not always clear how these viewsrelate to or affect each other. The proposed integra-tion or mapping methods are mostly based on refine-ment or reification, and focus on the vertical dimen-sion. While some frameworks offer dedicated con-structs for combining models (e.g. the process viewin ARIS), it is not clear how this integration affectsthe ability of the models to change independently.If a change in a certain model affects other modelsit is combined with, a combinatorial effect occurs.While originally used to describe evolvability in soft-ware, combinatorial effects also seem to affect evolv-ability on the Enterprise Architecture level. Anal-ogously with combinatorial effects on the software

level, this implies that organizations would becomeless evolvable as they grow. While the issue of inte-gration has been acknowledged by other authors (e.g.,(Lankhorst, 2005)), it has, to our knowledge, not yetbeen studied based on system theoretic concepts suchas stability.

3.2 Theoretical Foundation

Normalized Systems. The basic assumption of theNormalized Systems approach is that informationsystems should be able to evolve over time, andshould be designed to accommodate change. To gen-uinely design information systems accommodatingchange, they should exhibit stability towards require-ments changes. In systems theory, stability refers tothe fact that bounded input to a function results inbounded output values, even as t→ ∞. When appliedto information systems, this implies that no changepropagation effects should be present within the sys-tem; meaning that a specific change to an informa-tion system should require the same effort, irrespec-tive of the information system’s size or the point intime when being applied. Combinatorial effects occurwhen changes require increasing effort as the systemgrows. They need to be avoided in stable systems.Normalized Systems are therefore defined as infor-mation systems exhibiting stability with respect to adefined set of changes (Mannaert and Verelst, 2009),and are as such defying Lehman’s law of increasingcomplexity (Lehman, 1980) and avoiding the occur-rence of combinatorial effects.

The Normalized Systems approach proposes a setof four design principles that act as design rules toidentify and circumvent most combinatorial effects(Mannaert and Verelst, 2009). The first principle, sep-aration of concerns, implies that every change driveror concern should be separated from other concerns.This theorem allows for the isolation of the impact ofeach change driver. The second principle, data ver-sion transparency, implies that data should be com-municated in version transparent ways between com-ponents. This requires that this data can be changed(e.g., additional data can be sent between compo-nents), without having an impact on the componentsand their interfaces. The third principle, action ver-sion transparency, implies that a component can beupgraded without impacting the calling components.This principle can be accomplished by appropriateand systematic use of, for example, polymorphismor a facade pattern. The fourth principle, separationof states, implies that actions or steps in a workflowshould be separated from each other in time by keep-ing state after every action or step. This suggests an

CONSTRUCTING EVOLVABLE ENTERPRISE IMPLEMENTATIONS

523

asynchronous and stateful way of calling other com-ponents.

The design principles show that software con-structs, such as functions and classes, by themselvesoffer no mechanisms to accommodate anticipatedchanges in a stable manner. The Normalized Systemsapproach therefore proposes to encapsulate softwareconstructs in a set of five higher-level software ele-ments. These elements are modular structures thatadhere to these design principles, in order to providethe required stability with respect to the anticipatedchanges (Mannaert and Verelst, 2009). From the sec-ond and third principle it can straightforwardly bededuced that the basic software constructs, i.e., dataand actions, have to be encapsulated in their desig-nated construct. As such, a data element representsan encapsulated data construct with its get- and set-methods to provide access to their information in adata version transparent way. So-called cross-cuttingconcerns, for instance access control and persistency,should be added to the element in separate constructs.The second element, action element, contains a coreaction representing one and only one functional task.Four different implementations of an action elementcan be distinguished: standard actions, manual ac-tions, bridge actions and external actions. In a stan-dard action, the actual task is programmed in the ac-tion element and performed by the same informationsystem. In a manual action, a human act is requiredto fulfil the task. The user then has to set the state ofthe life cycle data element through a user interface,after the completion of the task. A process step canalso require more complex behaviour. A single taskin a workflow can be required to take care of otheraspects, which are not the concern of that particu-lar flow. Therefore, a separate workflow will be cre-ated to handle these concerns. Bridge actions createthese other data elements going through their desig-nated flow. When an existing, external application isalready in use to perform the required task, the actionelement would be implemented as an external action.These actions call other information systems and settheir end state depending on the external systems’ re-ported answer. Based upon the first and fourth prin-ciple, workflow has to be separated from other actionelements. These action elements must be isolated byintermediate states, and information systems have toreact to states. To enable these prerequisites, threeadditional elements are identified. A third elementis thus a workflow element containing the sequencein which a number of action elements should be exe-cuted in order to fulfill a flow. A consequence of thestateful workflow elements is that state is required forevery instance of use of an action element, and that

the state therefore needs to be linked to or be part ofthe instance of the data element serving as argument.A trigger element is a fourth one controlling the states(both regular and error states) and checking whetheran action element has to be triggered. Finally, the con-nector element ensures that external systems can in-teract with data elements without allowing an actionelement to be called in a stateless way.

Enterprise Ontology. In Enterprise Ontology, anorganization is modeled to represent the essential or-ganizational processes. Enterprise Ontology has astrong theoretical foundation and further builds uponthe results from theories from philosophy, sociologyand language, such as Habermas’ theory of Commu-nicative Action (Habermas, 1984) and the Language-Action Perspective (Flores and Ludlow, 1980). Enter-prise Ontology assumes that communication betweenhuman actors is a necessary and sufficient basis for atheory of organizations (Dietz, 2006). It aims to de-velop high-level and abstract models of the construc-tion and operation of organizations—independent ofthe actual implementation—by focusing on the com-munication patterns between human actors. Thesecommunication patterns are represented in a univer-sal transaction pattern. Enterprise Ontology considerstwo actors in a transaction: an initiator, who requeststhe transaction, and an executor, who fulfills the trans-action. The transaction pattern specifies the essentialactions performed by these actors (essential acts), andtheir results (essential facts).

The basic transaction pattern consists of the fivestandard acts which occur in a successful scenario(i.e., request, promise, execute, state and accept) (Di-etz, 2006, p. 90). These five acts are shown in the cen-tre of Figure 1. In the order-phase, the initiator actorfirst requests the creation of a fact. The executor actorthen promises to fulfil this request. In the execute-phase, the executor actually performs the necessaryactions to create the fact in the execute act. In theresult phase, the executor first states the successfulcompletion of the fact. Finally, the initiator acceptsthis statement. Consider this transaction in the caseof a simple product delivery process. In a first pro-cess step, the customer requests the product. Oncethis request is adequately specified, the request coor-dination fact is created. Second, the supplier promisesto deliver the product according to the agreed terms.This creates the promise coordination fact. The thirdprocess step is the actual delivery. This results in theproduction fact “Product X has been delivered”. Inthe fourth process step, the supplier states that the de-livery has been completed. If the customer is satisfiedwith the delivery, he will accept the delivery in thefifth process step. Once the accept coordination fact is

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

524

Figure 1: Graphical representation of the Enterprise Ontology Transaction Pattern.

created, the transaction is considered to be completed.In the above example, it is not specified how, for

example, the request was made. This could be face-to-face (in a retail store), or by using an online webform. The execution of this example could be com-pleted by manually delivering the product, or by send-ing it through a complicated logistic chain. Enter-prise Ontology abstract from these concrete imple-mentations, and represent only the essential businessactions. Therefore, Enterprise Ontology models area good candidate to use as an enterprise architecturecore model.

4 METHODOLOGY

This research uses the design science methodology.Regarding the research project’s goal to introduce aprescriptive framework for enterprise architectures,only a design science research methodology is suitedto provide the required research setting as it is pri-marily aimed at solving problems by developing andtesting artefacts, rather than explaining them by de-veloping and testing theoretical hypotheses. The de-sign science research tradition focuses on tackling ill-

structured problems — in this research the lack of sci-entific foundations within the engineering of organi-zational artefacts — in a systematic way (Holmstromet al., 2009). The search for a solution to these prob-lems using design science is often based on provenapproaches in other related fields. Various authors in-deed indicate that the use of theories of related fieldsshould be an essential part of a design science ap-proach (Klahr and Simon, 1999; Simon, 1996; Pefferset al., 2007). Moreover, these theories should be ap-plicable in practice. Both the aspects of practical us-ability and theoretical foundation are required for anapproach in order to be usable in a design science con-text. On the one hand, a well-founded theory whichdoes not offer practical implications for the design ofartefacts is of limited practical use. On the other hand,design guidelines which are not verifiable do not con-tribute to the science of design. The Normalized Sys-tems approach is well suited for this purpose, since itexpresses established design experience through prin-ciples which are proven to be necessary. Moreover,the correlation of Normalized Systems design princi-ples with more general theories such as systems the-ory and modularity, indicates its aptness for extensionto other research fields.

The research deliverable can unambiguously be

CONSTRUCTING EVOLVABLE ENTERPRISE IMPLEMENTATIONS

525

positioned within the design science classificationscheme suggested by March and Smith (March andSmith, 1995). March and Smith identify 4 differentresearch outputs (i.e., construct, model, method andinstantiation) and 4 different research activities (i.e.,build, evaluate, theorize and justify). This paper fo-cuses on the build-phase of a method artefact. In ac-cordance with Simon, building a (part of a) method isactually studying the artificial as a method is a manmade object designed to meet certain desired goals(Simon, 1996). This confirms the selection of thedesign science methodology over a behavioral sci-ence methodology. According to Hevner (Hevneret al., 2004, p.79), a method “can range from for-mal, mathematical algorithms that explicitly definethe search process to informal, textual descriptions of“best practice” approaches, or some combination.”.Winter (Winter, 2008) also mentions the paucity ofdesign science research aimed at constructing meth-ods. In this sense, this study is concerned with theonly modestly researched area of Method Engineer-ing. In summary, this research project’s main deliv-erable is a method, mainly based on the NormalizedSystems approach, providing guidelines to purpose-fully design enterprise architectures. We will attemptto implement an enterprise core model which is evolv-able. We will use Enterprise Ontology models to de-fine the core model, and use Normalized Systems as abasis to guide the implementation process.

The applied research method exhibits a researchtrajectory, as illustrated by Figure 2, which mimicsthe “Generate/Test cycle” suggested by Simon (Si-mon, 1996). A similar process is proposed by Pefferset al. (Peffers et al., 2007). In this research trajec-tory, we begin by defining and motivating the prob-lem based on literature or observations. This is thefirst step in Figure 2. Therefore, the research entrypoint is problem-centered (Peffers et al., 2007). Inthis research, we focus on the inhibition of the re-quired enterprise agility caused by the lack of sci-entific foundations when constructing organizationalartefacts. This problem is supported by a literaturereview which shows lack of attention to combinato-rial effects. Section 3.1 elaborates on this problemidentification. Next, we identify approaches from re-lated fields which can aid in constructing a solutionfor the identified problem. This is the second stepin Figure 2. In order to introduce more determinismin the construction of enterprise architecture frame-works, the Enterprise Ontology and Normalized Sys-tems approaches provide valuable insights. We intro-duce these approaches and motivate their selection inSection 3.2. We can already present some preliminaryresults of our approach by showing the implementa-

Figure 2: Research design.

tion of the core model using Normalized Systems el-ements. The method for the artefact construction isdescribed using a simple example from an e-businesscontext in Section 5. This is the third step in Figure 2.We explain the reasoning behind the different steps indetail and illustrate the resulting artefact and its use.This description will focus on the correct constructionof a single construct instance. In subsequent researchsteps, we will extend this method to include additionalorganizational elements.

Evaluating the proposed guidelines will occurby applying the guidelines on different problem do-mains. These problems domains will be purposefullysampled, controlling for different industries and or-ganizational dimensions. Different industries will beincluded, such as banking, government and manu-facturing. In addition, the considered organizationalaspects will differ along their administrative dimen-sion, ranging from operational order and accountingto management reporting processes. The methodsconstructed will be evaluated using two approaches.First, through the multiple iterations the method willbe tested and altered to better suit the research ob-jective of enhancing determinism. This approach canbe labeled as case study research. The cases studiedduring initial iterations will mainly consist of ratherpedagogical, theoretical cases. Further iterations in-clude more complex cases, based upon real-life or-ganizations in order to enhance the generalization ofour results. As mentioned earlier, these cases will bepurposefully sampled to assure validity. Secondly, tofirmly evaluate the proposed methods, they will fi-

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

526

nally be applied to real-life cases to assess their prac-tical applicability. This kind of evaluation is basedon the action research methodology (Baskerville andWood-Harper, 1996) because the researcher activelycooperates within the case.

5 PRELIMINARY RESULTS

Currently, we can present the implementation of theEnterprise Ontology transaction pattern according toour approach. An implementation of a completeEnterprise Ontology model would provide a basisfor an evolvable implementation of an organization.Evidently, additional organizational elements (suchas operational aspects, financial aspects, human re-sources) need to be added. However, once we canconstruct an organizational implementation which isfree of combinatorial effects, these elements can beadded analogously to the addition of cross-cuttingconcerns in Normalized Systems.

5.1 The Basic Transaction Pattern

We start by mapping the basic transaction pattern.The basic transaction pattern consists of the processsteps request, promise, execute, state and accept. InNormalized Systems, this transaction pattern processis represented by a flow element. A flow element isdriven by precisely one data element, the life cycledata element. Consider a transaction T01. In orderto define a Normalized Systems flow, we thus needa T01 data element. The completion of the differentacts in the transaction process is represented by thecreation of ontological facts. In Normalized Systems,these facts are represented by the states which occurin the flow element, being the life cycle states of thecorresponding data element. To reach these states, astate transition is required. A state transition is real-ized by an action element. The successful completionof that action element results in the defined life cyclestate. In order to define the control flow of the pro-cess, we therefore need to specify the trigger states,state transitions and transaction actions. Regardingthe request coordination fact, this implies that the T01flow element, and thus also the corresponding T01data element, should reach the state Requested. Thismeans that upon initiation of a T01 transaction, a newT01 data element is instantiated trough its default con-structor, resulting in the life cycle state Initial. Thegenuine act of requesting is encapsulated in the ac-tion element Request. The concerns of creating thedata element and handling the request are separatedas they can clearly evolve independently from each

other. The request could, for example, contain addi-tional information that needs to be processed. Sincewe are currently only regarding the successful flowof the transaction, we do not yet need any branching.The state transition can be expected to always resultin the end state Requested. The resulting NormalizedSystems flow is shown in Figure 3, and schematicallyrepresented in Table 1.

While all state transitions are defined as action el-ements, their different nature can mean that they needto be implemented differently. Consider the examplewith the product delivery transaction. In the promisestep, the executor needs to communicate whether therequest of the initiator will be handled. If this act re-quires a human action, e.g., a manager has to decide,the Promise action element would be implemented asa manual action. However, the promise process stepcan also require more complex behaviour. When forexample the product first needs to be reserved in thewarehouse, the Promise action element would be im-plemented as a bridge action triggering a flow elementon another data element, e.g., a Part element. Whenan existing application is already in use to performthese reservations, the Promise action element wouldbe implemented as an external action.

5.2 The Execution Act

Besides the coordination acts, we also need to providean implementation for the production act Execute. Atthis point, an issue surfaces as the Normalized Sys-tems theory prescribes that a flow is concerned withprecisely one data element (Mannaert and Verelst,2009; Van Nuffel et al., 2009a). If the execution ofthe production act does not require any actions to beperformed on other data elements, the production actwill be designed as an action element on the samedata element. The implementation of the productionact will then determine whether it is a manual actionor a standard action. Otherwise a second alternativeis appropriate, applying a bridge action. These op-tions are, however, not interchangeable as only oneoption can be chosen depending on the kind of per-formed business transaction. Some common exam-ples will exemplify the two scenarios. First, consideran employee requesting a day off, which in Enter-prise Ontology terminology is defined as “Grant Ap-plication for Leave A”. The production act is the de-cision of the manager to grant the day off. The man-ager simply verifies the application based on the avail-able information and takes a decision, thus only con-sulting data of the underlying life cycle data elementLeaveApplication. This production act is thereforeconsidered a manual action. The manager probably

CONSTRUCTING EVOLVABLE ENTERPRISE IMPLEMENTATIONS

527

Table 1: Specification of the basic transaction pattern flow element.

Workflow name Basic Transaction PatternData element T01-basicStart state Action name End state Failed state

Initial Request RequestedRequested Promise PromisedPromised Execute ExecutedExecuted State Stated

Stated Accept Accepted

Figure 3: Graphical representation of the basic transaction pattern flow.

selects either “Accept” or “Reject” in a GUI, trigger-ing a state transition of LeaveApplication. It is how-ever possible that such a decision is automated. Con-sider for instance the case in which a person wants tosubscribe to a newsletter by initiating the transaction“Start newsletter subscription N”. Adding the personto the distribution list does probably not need to beapproved by a manager, and will be automatically ex-ecuted. In this case, the production act of adding theperson to the distribution list is designed as a standardaction.

Second, if additional actions concerned with otherdata elements are required to fulfill the execution ofthe transaction, a bridge action has to implemented.Consider for instance the execution step of our prod-uct delivery example. When this product has to beproduced before it can be deliverd, additional actionsmay be necessary. Producing a particular product im-plies more than just the assembly: raw materials haveto ordered, received and reserved, the product has tobe scheduled in the production planning, etcetera. Itis clear that these are different concerns, and shouldthus be separated. Compliant with the NormalizedSystems theory, this kind of behavior is implementedby using a bridge action.

5.3 The Cancelation Patterns

Various extensions of the basic transaction patternhave already been developed. Currently, we will dis-cuss the addition of cancelation patterns. A cancela-tion occurs when an actor changes his mind concern-ing an already completed coordination act. For ex-ample, the iniator can decide that he no longer wantsa certain product to be delivered, and cancel his or-

der. For the receiving actor, a cancelation consistsof two main issues: deciding whether or not to al-low a cancel request and handling the cancelation it-self. The first issue actually consists of initially re-ceiving the cancel request, then deciding whether ornot to allow the requested cancelation, and third po-tentially to notify the initiator of the rejected cancelrequest. As such, based on separation of states andseparation of concerns, these three concerns will beseparated. First, upon arrival of a cancel request, adedicated CancelRequest data element will be cre-ated. This implies that for every life cycle data ele-ment that can be cancelled, a related CancelRequestdata element instance will be created if such a requestarrives. For example, for a life-cycle data elementcalled Order, a corresponding OrderCancelRequestdata element will be created. Second, an action ele-ment AcceptCancelation will implement the deci-sion whether or not to accept. Third, in case of anrejected request, the initiator will probably have to benotified. This functionality is represented by a bridgeaction Refuse executing the notification in the wayas discussed in (Van Nuffel et al., 2009b). In caseof an allowed cancelation, the CancelTransactionstandard action element will initiate the cancelationhandling which will be explained next. The Nor-malized Systems specification for the workflow rep-resenting the cancel request issue is shown in Ta-ble 2 and Figure 4. In case of an allowed cance-lation, CancelTransaction standard action elementwill initiate the handling itself explained hereafter.

If the cancelation is allowed, it may be neces-sary to partly or completely roll back the transaction.Given the divergence of business contexts, a roll backcan imply different actions given the state of the trans-

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

528

Table 2: Specification of the cancelation pattern flow element.

Workflow name Transaction CancelationData element T01-CancelRequest

Start state Action element End state Failed stateInitial CheckValidity CancelRequestValid

CancelRequestValid AcceptCancelation Allowed not-Allowednot-Allowed Refuse Refused

Allowed CancelTransaction Canceled

Figure 4: graphical representation of the cancelation pattern.

actions. Therefore, the cancelation process will be de-signed using multiple scenarios implemented as sep-arate action elements on the same life cycle data ele-ment. Consider in our product delivery example thescenario where various parts are ordered to completethe assembly of a product. In case the parts have notyet been received, an order cancelation can be sub-mitted to the parts supplier. In case the parts are al-ready received and reserved, they should be releasedand made available for future assemblies. Thus, thescenario and constituent action elements are depen-dent on the life cycle data element’s state when thecancelation request is initiated.

Since a cancelation can occur regardless of thecurrent state of the transaction, it is modelled in theEnterprise Ontology transaction pattern as a separateentry point, as can be seen in Figure 1. However, theNormalized Systems theorems do not allow that thestate of the main flow is simply altered by any otherflow because a flow element actively interfering withanother flow element is considered a so-called GOTOstatement. In accordance with the seminal work ofDijkstra (Dijkstra, 1968), Normalized Systems doesnot allow this kind of statements, and therefore pro-hibits such a direct state transition by another flow.

We outline the solution for adding cancelation pat-terns consistent with Normalized Systems theorems:

• A cancelRequest data attribute is added to thedata element operating the flow.

• A cancel can be initiated in multiple ways. Theparticular situation should be assigned to thevalue of the cancelRequest data attribute by the

CancelTransaction standard action element.

• The engine operating the respective flow elementchecks the cancelRequest data attribute. If thisfield is set, the current state of the flow will besaved in the so-called parking state field. The reg-ular state field of the workflow will be set to “can-cel requested”.

• An action element will subsequently be triggeredto decide which cancelation flow—i.e., sequenceof action elements on the corresponding life cycledata element—has to be triggered as the cancela-tion scenario will differ according to the life cyclestate as also illustrated by the cancelation patternsin Enterprise Ontology. Therefore, this action el-ement will use the value of the so-called parkingstate field, uniquely describing the life cycle stateof the corresponding data element when the can-cel request was communicated.

This implies that a cancelation is handled as a se-quence of action elements on the same life cycle dataelement. This is in line with the observation that re-questing, promising, executing, stating, declining, orcancelling a fact addresses the same concern. How-ever, the sequence of actions about the cancel re-quest itself are separated in their designated elements.It should be noted that we present a generic can-celation pattern. The possibility of triggering dif-ferent cancelation flows, based on the value of thecancelRequest data attribute, allows us to imple-ment the four different Enterprise Ontology cancela-tion patterns.

CONSTRUCTING EVOLVABLE ENTERPRISE IMPLEMENTATIONS

529

6 DISCUSSION ANDCONCLUSIONS

In this paper, we outlined the approach taken in ourPhD research. We use the design science methodol-ogy to apply the insights of existing theories, i.e., Nor-malized Systems and Enterprise Ontology, to the fieldof enterprise architecures. We discussed the relevanceof our research problem, our motivation, the relatedwork, the methodology, and presented some prelim-inary results. We already have developed an imple-mentation of the core model of our enterprise archi-tecture which is free of combinatorial effects, calledthe NSBT. Currently, we are working on the evalua-tion of the NSBT in various case studies. Next, wewill describe the method to add additional concernsto this core model, in order to be able to implementother organizational elements.

While we may not be able to implement all en-terprise architecure aspects, this research project hassignificant contributions. A first contribution is thatwe introduce the concept of combinatorial effects onthe level of enterprise architectures. We further il-lustrate how the systems theoretic concept of stabil-ity can be applied to the design of enterprise archi-tectures. This requires the elimination of combina-torial effects, which will lead to more evolvable or-ganizations. As a result, we offer a view on enter-prise agility that has a strong theoretical foundation.A second contribution is that we demonstrate the fea-sibility of constructing an enterprise architecture corediagram based on existing scientific approaches. Byexpressing the core diagram in Normalized Systemselements, we extended the Normalized Systems ap-proach to the organizational level. Using EnterpriseOntology models as the basis for the core diagramfurther demonstrates the feasibility of constructing anenterprise architecture framework based on scientifictheories. This illustrates how theories from relevantfields can be applied in a new setting by using a de-sign science approach.

REFERENCES

Aghion, P. and Tirole, J. (1994). Opening the blackbox of innovation. European Economic Review,38(3/4):701–710.

Baskerville, R. L. and Wood-Harper, A. T. (1996). A criti-cal perspective on action research as a method for in-formation systems research. Journal of InformationTechnology, 11(3):235–246.

Brynjolfsson, E. and Saunders, A. (2010). Wired for Inno-vation: How Information Technology is Reshaping theEconomy. The MIT Press, Cambridge, MA.

Chan, Y. E., Huff, S. L., Barclay, D. W., and Copeland,D. G. (1997). Business strategic orientation, informa-tion systems strategic orientation, and strategic align-ment. Information Systems Research, 8(2):125.

Dietz, J. L. (2006). Enterprise Ontology: Theory andMethodology. Springer, Berlin.

Dijkstra, E. (1968). Go to statement considered harmful.Communications of the ACM, 11(3):147–148.

Eisenhardt, K. M. and Martin, J. A. (2000). Dynamic capa-bilities: What are they? Strategic Management Jour-nal, 21(10/11):1105–1121.

Fagerberg, J. (2005). Innovation: A guide to the literature.In Fagerberg, J., Mowery, D. C., and Nelson, R. R.,editors, The Oxford handbook of innovation. OxfordUniversity Press, New York, NY.

Flores, F. and Ludlow, J. (1980). Doing and speaking in theoffice. In Fick, G. and Sprague, R. H., editors, Deci-sion Support Systems: Issues and Challenges, pages95–118. Pergamon Press, New York, NY.

Garlan, D. and Perry, D. E. (1995). Introduction to the spe-cial issue on software architecture. IEEE Transactionson Software Engineering, 21(4):269–274.

Habermas, J. (1984). The Theory of Communicative Ac-tion: Reason and Rationalization of Society, vol-ume 1. Beacon Press, Boston, MA.

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).Design science in information systems research. MISQuarterly, 28(1):75–105.

Holmstrom, J., Ketokivi, M., and Hameri, A.-P. (2009).Bridging practice and theory: A design science ap-proach. Decision Sciences, 40(1):65–87.

Hoogervorst, J. A. P. (2009). Enterprise Governance andEnterprise Engineering (The Enterprise EngineeringSeries). Springer, 1st edition.

Kazman, R. and Bass, L. (2005). Categorizing businessgoals for software architectures. Technical report,Software Engineering Institute. CMU/SEI-2005-TR-021.

Klahr, D. and Simon, H. A. (1999). Studies of scientific dis-covery: Complementary approaches and convergentfindings. Psychological Bulletin, 125(5):524–543.

Kozina, M. (2006). Evaluation of aris and zachman frame-works as enterprise architectures. Journal of Informa-tion and Organization Sciences, 30(1).

Lankhorst, M. M. (2005). Enterprise architecturemodelling–the issue of integration. Advanced En-gineering Informatics, 18(4):205 – 216. EnterpriseModelling and System Support.

Lehman, M. (1980). Programs, life cycles, and laws of soft-ware evolution. Proceedings of the IEEE, 68:1060–1076.

Leist, S. and Zellner, G. (2006). Evaluation of current archi-tecture frameworks. In SAC ’06: Proceedings of the2006 ACM symposium on Applied computing, pages1546–1553, New York, NY, USA. ACM.

Mannaert, H. and Verelst, J. (2009). Normalized Systems—Re-creating Information Technology Based on Lawsfor Software Evolvability. Koppa, Kermt, Belgium.

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

530

March, S. T. and Smith, G. F. (1995). Design and naturalscience research on information technology. DecisionSupport Systems, 15(4):251–266.

Op t Land, M. (2008). Applying Architecture and Ontologyto the Splitting and Allying of Enterprises. PhD thesis,TU Delft.

Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chat-terjee, S. (2007). A design science research method-ology for information systems research. Journal ofManagement Information Systems, 24(3):45–77.

Pereira, C. M. and Sousa, P. (2004). A method to definean enterprise architecture using the zachman frame-work. In SAC’04: Proceedings of the 2004 ACM sym-posium on Applied computing, page 13661371, NewYork,NY,USA. ACM.

Ross, J. W., Weill, P., and Robertson., D. C. (2006). Enter-prise Architecture as Strategy – Creating a Founda-tion for Business Execution. Harvard Business SchoolPress, Boston, MA.

Simon, H. A. (1996). The Sciences of the Artificial. MITPress, Cambridge, Massachusetts, third edition.

Teece, D. J., editor (1987). The Competitive Challenge:Strategies for Industrial Innovation and Renewal.Ballinger Publishing Company, Cambridge, MA.

Teece, D. J., Pisano, G., and Shuen, A. (1997). Dynamiccapabilities and strategic management. Strategic Man-agement Journal, 18(7):509–533.

The Open Group (2003). The open group architectureframework (togaf) version 8.1. Technical report.

Van de Ven, A. H. and Angle, H. L. (2000). An Introduc-tion to the Minnesota Innovation Research Program.Oxford University Press, New York, NY.

Van Nuffel, D., Mannaert, H., De Backer, C., and Verelst, J.(2009a). Deriving normalized systems elements frombusiness process models. In Boness, K., Fernandes,J. M., Hall, J. G., Machado, R. J., and Oberhauser,R., editors, Proceedings of the Fourth InternationalConference on Software Engineering Advances (IC-SEA 2009), pages 27–32, Los Alamitos, USA. IEEEComputer Society.

Van Nuffel, D., Mannaert, H., De Backer, C., and Verelst, J.(2009b). Deriving normalized systems elements frombusiness process models. Software Engineering Ad-vances, International Conference on, 0:27–32.

Winter, R. (2008). Guest editorial - design science researchin europe. European Journal of Information Systems,17(5):470–475.

Zachman, J. A. (1987). A framework for information sys-tems architecture. IBM Syst. J., 26(3):276–292.

CONSTRUCTING EVOLVABLE ENTERPRISE IMPLEMENTATIONS

531