[Lecture Notes in Business Information Processing] Enterprise Information Systems Volume 190 || Blueprint of a Semantic Business Process-Aware Enterprise Information Architecture:

Blueprint of a Semantic Business Process-AwareEnterprise Information Architecture:

The EIAOnt Ontology

Mahmood Ahmad(B) and Mohammed Odeh

Software Engineering Research Group, Faculty of Environment and Technology,University of the West of England, Coldharbour Lane, Bristol BS16 1QY, UK

[email protected], [email protected]

Abstract. A robust design of enterprise information resources and theiroptimal usage can significantly enhance the information management(IM) capability of an enterprise. Enterprise Information Architecture(EIA) is a critical success factor for this objective and needs to be busi-ness process-aware in order to add value to the firm’s IM capabilityand to obtain dynamic views of information through extended knowl-edge of business processes. We present the generic Enterprise Informa-tion Architecture Ontology (EIAOnt) that lays the foundation for theEIA design activity to use additional business information by incorpo-rating the business process knowledge. We also present an approachthat semantically derives EIA from Enterprise business process archi-tecture (BPA) using Riva BPA methodology. A semantic representationof EIA through EIAOnt Ontology suggests a step forward to bridge thegap between business process architecture and enterprise informationarchitecture.

Keywords: Enterprise information architecture · Semantic informationarchitecture · Semantic information integration

1 Introduction

1.1 Enterprise Information Architecture (EIA)

The design of Information architecture (IA) is an established activity that hasbeen recognised to have a central importance for information system develop-ment community since 1980s. Brancheau and Wetherbe defined in [1] that infor-mation architecture ‘. . . is a high level map of the information requirements of anorganisation. It is a personnel-, organisation- and technology-independent pro-file of major information categories used within the enterprise.’ Among morerecent definitions, Godinez et al. [2] define Information Architecture as ‘[Thedescription of] principles and guidelines that enable consistent implementationof information technology solutions, how data and information are both governed

c© Springer International Publishing Switzerland 2014S. Hammoudi et al. (Eds.): ICEIS 2013, LNBIP 190, pp. 520–539, 2014.DOI: 10.1007/978-3-319-09492-2 31

Blueprint of a Semantic Business Process-Aware Enterprise 521

and shared across the enterprise, and what needs to be done to gain business-relevant trusted information insight.’ (p. 28). The Enterprise Information Archi-tecture (EIA), is ‘the framework that defines the information-centric principles,architecture models, standards, and processes that form the basis for makinginformation technology decisions across the enterprise’. [2].

Enterprise Information Architecture is an integral part of Enterprise Archi-tecture of modern enterprise. Enterprise Architecture is regarded as ‘. . . a com-prehensive description of all of the key elements and relationships that make upan organisation.’ [3]. Enterprise architecture (EA) attempts to provide struc-ture to the whole organisation where information is found from strategic level tobusiness to information resources, hence a structured EA approach (for exam-ple, see Fig. 1) is essential to architect enterprise-wide information for a success-ful information system (IS) and a sound technology infrastructure. Enterpriseinformation resources are structured in EIA that is in close proximity with busi-ness architecture (including business process architecture) and business strategy(Fig. 1). EIA is relevant to EA so much so that some EIA researchers have foundit easy to design the whole enterprise architecture (EA), such as [4].

1.2 Components of EIA

The Enterprise Information Architecture (EIA) has following components [2,5]:

– Information Entities, attributes and relationships– Enterprise Data Models, Entity-Relationship diagrams

Fig. 1. Enterprise architecture. Note that the EIA elements contain entities as well asprocesses in this slightly modified view.

522 M. Ahmad and M. Odeh

– Models of Information value chain, such as Information flow diagrams– Information views for stakeholders– Traceability of EIA Components– Business domain knowledge (Ontologies, taxonomies and metadata etc.)

Critical issues relating to the design of EIA include requirements for informationquality, storage and retrieval, searchability, findability and accessibility, informa-tion security [6]. While these issues are related to EIA from within InformationManagement domain (Fig. 1), the knowledge of these issues has a positive impacton the design of EIA components itself and provides credibility to the EIA designprocess.

1.3 Motivation for this Research

Classically, the EIA design activity consisted of building a map of a firm’s infor-mation resources and business functions based on time-consuming managerialinterviews. The subsequent time requirements led to an increasing lack of interestfrom the strategic management in this vital design effort. However, a consistentemphasis on the vitality of IA (Information Architecture) design in relation to afirm’s business processes and information resources has remained the case [7–10]in the business information management research community. Recent researchhas identified that the information management capability of an enterprise has asignificant contribution towards development of its capabilities in customer man-agement, process management and performance management, [11,12]. The Infor-mation Management (IM) Capability may be defined as the ability to providedata and information within the desired accuracy and time scale for a given enter-prise business process. This implies that the design of information architecture(IA) is of pivotal importance for developing the IM capability. The enhancementimplied by this ability develops customer management (CM) capability that gen-erates opportunities to develop customer relationships both as consumers andinnovation partners. The IM capability can also contribute towards developingand redesigning business processes for carrying out the activities of an enterprise,reflecting on the Process Management (PM) capability of the enterprise, [11].

A number of factors motivate this work which provides ontological founda-tion of a business process-oriented EIA of an enterprise. Firstly, in organisationsthat deal with information as a commodity and/or as a service, it is suggestedthat organizations that use their business information successfully can be asmuch as 27% more effective. This requires a fresh look into information strategywith a goal to achieve optimal information usage [13]. Secondly, a vast major-ity of contemporary IA design practice has lacked the knowledge of businessprocess information due to: (a) the lack of appropriate technologies to capturebusiness process knowledge, and (b) the continuing lack of interest from man-agement to invest in EIA design and hence the absence of a comprehensive EIAdesign that can support not only any business process reengineering (redesign)effort but this EIA could also support the design of new business processes.Thirdly, recent research in two independent areas has provided impetus for this


research. One is in the areas of Business process architecture (BPA) method-ologies and business process modeling technologies such as Business ProcessModeling Notation (BPMN), [14], which has facilitated the structured defini-tion and representation of business processes. The other is the advancement ofresearch in knowledge representation (KR) mechanisms and the advancementof Semantic Web (SW) technologies [15,16]. The use Ontologies (Sect. 2.1) asKR mechanisms in Enterprise Information Systems (EIS) can be instrumentalin representation of information resources and other areas related to informationmanagement. And finally, classical IA design approaches identified informationcategories and processes with the help of long manager interviews. This resultedin lack of management interest in IA design approaches [1,8,9,17,18] and com-prehensive methodologies like Information Engineering (IE) [7] and its derivedforms like IBM’s Business Systems Planning (BSP) and Strategic Data Planning(SDP), [19].

This paper presents a blueprint of such an approach that bridges this gapbetween business architecture and enterprise information architecture usingsemantic technologies. Section 2 discusses the related work in classical and con-temporary attempts to BPA-oriented EIA. Section 3 details the concepts andrelationships of the EIAOnt ontology for the EIA elements and discusses ratio-nale behind chosing these concepts. Section 4 discusses the proposed approachthat semantically derives EIA entities and processes of the enterprise from BPAontological artefacts. Section 5 demonstrates the current work through a case-study in cancer-care domain while identifying some adjustments for the par-ent framework that conceptualises the BPA methodology. Section 6 discussesissues in this approach that we currently face with some possible remedies, andSection 7 concludes this paper with directions for further work.

2 Related Work

2.1 Non-semantic Approaches to IA Design

Non-Semantic approaches to IA design include enterprise data model approachby [18], long-range information architecture and ends/means analysis approaches[17], critical success factors approach [20], Information Engineering (IE) basedapproaches [7] such as IBM’s Business System Planning (BSP) and strategicdata modeling (SDM). These approaches relied upon long time-consuming inter-views which heavily contributed to a lack of interest in IA design activity bythe strategic enterprise managers. Among these approaches, the enterprise datamodel approach and the IE-based approaches were business process-centric; how-ever, the IE-based approaches lacked appeal due to the absence of technologicaladvances of today [8,9], which could reduce the astronomical time requirementsfor EIA design.

More recently, the EIA is seen as a part of the overall enterprise architecture(EA) of an enterprise and is also mentioned as data architecture. Examples ofthese approaches include Zachman’s Information Systems Architecture (ISA)


[21,22], the Architecture Development Model (ADM) by TOGAF [23], the four-layer Process-Driven Architecture (PDA) model [24] and the CiESAR model [25].

The TOGAF’s data architecture is based on business entities (list of thingsimportant to the business), Entity-Relationship Diagrams, logical data modeland data flow diagrams, which constitute four out of 30 cells within Zachman’sISA [21] as identified in Figure. With the advent of knowledge-based techniquessuch as conceptual modelling and meta-data techniques like ontologies, datatransforms into Enterprise Information Architecture (EIA) using informationvocabularies such that the information model describes the information item(or information entity as we name it) that represents a data item (or entity).However, the EIA is still not completely informed by the business process archi-tecture as it lacks a complete knowledge of business elements such as that ofbusiness processes and the knowledge of interdependence within these elements.In a critical investigation, TOGAF has also been found to have failed to providea sound and appropriate basis for its designs for enterprise engineering [26].

2.2 Ontologies and Ontology Engineering Methodologies

Ontology is ‘a formal explicit specification of a shared conceptualization’, [27].It is a knowledge representation (KR) mechanism that represents knowledgeof a domain that is consensual (shared and agreed between stakeholders) andmachine-understandable (has a formal basis), [28]. It is different from aknowledge-base (KB) in that a knowledge-base provides some concrete knowl-edge of the domain whereas ontology presents the vocabulary of the domainand the concepts and their inter-relationships. The Web Ontology LanguageOWL [29] is the current standard for development of Ontologies, and has threesub-categories, OWL Lite, (for designers of classification and simple constraints)OWL-DL (for maximum expressiveness using description logics) and OWL Full(for maximum expressiveness and syntactic freedom of the Resource DescriptionFramework language RDF).

Some of state-of-the-art methodologies in Ontology Engineering areMETHONOTOLOGY [30], CYC Method [31], DILIGENT (Pinto, Tempich etal. 2010), TOVE [32], FOIS [33], Ontology Development 101 [34], Ontology basedon Lexicon [35] and BORO [36] among others.

2.3 Semantic EIA Design Methodologies

Semantic approaches to EIA design include the use of Resource-Event-Action(REA) Ontology in TOGAF [23], however, its EIA is based only business dataand not on a thorough business information analysis. Genre and OntologiesBased Information Architecture Framework (GOBIAF, [37]) is based on infor-mation need interviews and this approach is also not based on knowledge ofbusiness entities and processes. The Field-Actions approach by [38] uses fieldactions for incorporating business process information and uses HL7 ontologybut it lacks derivation of fully derived information model of an organization.


The Design and Engineering Methodology for Organizations (DEMO)Methodology (Dietz 2006) was developed to bridge the gap between businessprocesses and information systems using Language/Action (or L/A) Perspec-tive, which ‘assumes that communication is a kind of action in that it createscommitments between the communicating parties’, (Dietz 1999). The DEMOmethodology is rooted in χ-theory and provides an integration of three aspectsof organisations, namely: B-organisation (business), I-organization (information)and D-organization (document). However, this methodology also limits itselfto translate information entities, attributes and relationships from χ-theory toEnterprise Information Architecture (Gomes 2011).

The Toronto Virtual Enterprise (TOVE) Ontology project has developed aset of integrated ontologies for the modelling of both commercial and publicenterprises [32]. The Ontologies suite of TOVE is divided into three groups:Core, Derivative and Enterprise Ontologies. These Ontologies are designed inKnowledge Interchange Format (KIF) and use Resource Ontology as the corelevel and use Information Resource Ontology as the derivative ontology [39].These ontologies have been designed in line with requirements of product manu-facturing organizations and cannot be converted into OWL-DL format becausethe KIF uses First-Order logic (FOL) as compared to Description Logics (DL)in OWL-Description Logics which uses only a part of FOL.

3 The Enterprise Information Architecture (EIAOnt)Ontology

We present an Ontology, namely the EIAOnt Ontology, for Enterprise Infor-mation Architecture (EIA) on the theoretical basis set by [40] using Bunge-Wand-Weber (BWW) Ontology. The artefacts of the EIAOnt Ontology consistof concepts that represent information entities (IEs), information- and EIA-related processes, their sub-concepts and the relationships that exist within andbetween these concepts.

3.1 Need and Scope

In order to deal with the issues of semantic heterogeneity of information thatoriginates from diverse resources, ontologies can provide a structured approachto represent knowledge of basic concepts that are common across a varietyof domains [41]. These ontologies are extensible and for particular domains,these act as metadata vocabularies. The EIAOnt ontology is considered as ageneric ontology for EIA design within the Enterprise Architecture domain andis designed to construct a sharable knowledge of EIA design terms and con-cepts within the enterprise, hence it forms a much needed component within theEnterprise Architecture to ensure a business process-aware EIA.

The scope of the EIAOnt Ontology is defined by its use within various Enter-prise Architecture domains. As EIA is only one of the four architectures withinthe EA domain, the EIAOnt Ontology is limited in its scope to conceptualise


EIA elements. On one hand, this Ontology is based on the knowledge of vitalplace of Information within the enterprise and hence it is aware of EIA’s rolewithin Information Management department as well as Business Strategy enter-prise. On the other hand, the EIAOnt is generic and can provide easy interfacewith domains of business process knowledge, knowledge of business strategy andgoals, knowledge of Information Management requirement such as data qual-ity, availability and information security to construct a semantic structure forEnterprise with sound theoretical base. We have used the methodology by [34] todevelopment EIAOnt ontology for a generic Enterprise Information Architectureidentifying concepts and relationships for a business process-oriented EIA.

3.2 Conceptualisation of EIA Entities

In order to establish a clear understanding of what qualifies to become an EIAentity (hereinafter called an ‘information entity’), we delve into philosophies thatdefine entities and classify them.

Entities in Bunge-Wand-Weber Ontology. Bunge, in his philosophicalstudy of the world systems, Mario Bunge [42,43] presented ontological founda-tion of real world systems that was adopted by [44] to present a formal model ofobjects (things that physically exist in the real world). According to Bunge’s phi-losophy [42], the world is made up of two kinds of things, namely concrete things- also called entities or substantial individuals - and conceptual things, which donot have a physical existence. Because Bunge’s model of objects deals only withreal world systems, it presents the ontological representation for only concretethings (or substantial individuals) and not for conceptual things. According tothe representation mapping rules defined by [45], this implies that every BWW-Thing or entity can be modelled as an object in an object-oriented modellinglanguage like UML. However, in software design, not every object is substantial,or in other words, not every information system object physically exists nor itis always a BWW-Thing. This view is also shared by [27] that “For AI systems,what ‘exists’ is that which can be represented” [46].

Critics of Bunge’s ontology and Weber’s model of objects, such as [47], havethe view that BWW model provides an inappropriate foundation for conceptualmodel of business information systems. However, in their ontological model ofinformation systems, Wand and Weber [40] have argued that ‘all objects arethings, but only some types of things are objects’, which establishes (with exam-ples) that conceptual entities can also be modeled using the BWW ontology.In their discussion, they have referred to BWW-Thing as their ‘object’ andby ‘things’ they mean concrete as well as conceptual things, and have selectedINVENTARY ITEM, CUSTOMER ORDER, CUSTOMER ACCOUNT, CUS-TOMER REPAYMENT and INVENTARY REPLENISHMENT as illustrativeexamples of ‘things’ from a Customer Order and Payment System whereby nonecan be regarded as a BWW-Thing as none has a physical existence. Therefore,this ontological model can facilitate the analysis of things and other artifacts ofa business information system.


Entities in Top-Level Classification by John F. Sowa. John F. Sowa[48] represented the top-level classification of things by an Ontology lattice.This Ontology lattice classifies entities with primitive categorisation of Indepen-dent, Relative, Physical, Mediating, Abstract, Continuant (entities that endurein time) and Occurrent (that never fully exist at any instant; instead they unfoldwith time; for example processes or events). Objects or physical entities (BWW-Things) are represented as independent physical continuants (IPCs). Althoughthis classification elaborates abstract sub-categories such as situation, structure,reason and purpose (or goals), yet it lacks classification of conceptual entities likePAYMENT, which belongs to none of these abstract sub-categories. The entityPAYMENT is, in Sowa’s ontological lattice terms, a conceptual (or Abstract)continuant and does not belong to any of the above sub-categories. For enter-prise information modeling purposes, this ontology needs to add the notion ofAbstract Continuant (AC) for conceptual entities.

Abstract Derived Entities (ADEs). The concept of Abstract Derived Enti-ties (ADEs) within the data abstraction model is different from derived datatypes (sometimes referred to as derived entities) in the object-oriented designand programming paradigm. Instead, an ADE refers to ‘a data object present inan abstract data model that may be referenced by other entities in the abstractdata model as though it were a relational table present in a physical datasource.’, [49]. An example of an ADE is AGE which is an ADE correspond-ing to the DATE OF BIRTH conceptual entity. The ADEs are conceptual enti-ties that are derived from the primitive (or non-derived) conceptual or concreteentities.

3.3 Conclusion - What are Entities in EIAOnt Ontology?

The BWW model in [40] facilitates the formal base for both concrete and con-ceptual entities which exist side by side in enterprise information models. Inorder to suggest the derivation of EIA information entities from business processarchitecture, we firstly propose that all business entities should be conceptual-ized using the InformationEntity concept. Conceptual and concrete things aremodeled in EIAOnt Ontology as ConceptualEntity and ConcreteEntity sub-categories respectively (Fig. 2). As an ADE is always a conceptual entity, theAbstractDerivedEntity, as subconcept of the ConceptualEntity concept con-ceptualizes ADEs in the EIAOnt ontology with the help of boolean propertiesisConcreteEntity and isADE set to suitable values.

3.4 Categorization of EIA Processes

Processes in the EIAOnt ontology represent EIA processes, generally described bythe EIAProcess concept. This concept is sub-categorised into six sub-concepts: IEProcess, IECRUDProcess, IEMP and IESP, depicted in Fig. 3.The IECRUDProcess concept is further sub-categorised into IECreateProcess,


Fig. 2. Concept hierarchy for the InformationEntity concept in the EIAOnt ontology.

Fig. 3. Process concept and sub-concepts in the EIAOnt ontology.

IEReadProcess, IEUpdateProcess and IEDeleteProcess sub-concepts, individualsof which represent respectively the Create, Read, Update and Delete processes foran InformationEntity individual. Figure 3 elaborates how InformationEntityconcept is linked to EIA processes.

Once the enterprise information system has the knowledge of business entitiesand business processes, corresponding to every InformationEntity individualwhich was originally a business entity, there can be assigned one individualof each of the three process subConcepts of the EIAProcess concept, namelyIEProcess, IEMP and IESP concepts. The IEMP process is used to manage thecorresponding InformationEntity instance such that it supervises the comple-tion of IEProcess instances of the corresponding InformationEntity instance.


The IESP process concept is used to maintain a strategic view of both IEProcessand IEMP instances that correspond to a particular InformationEntity instance.This strategic view can be in the form of producing entity analytics to assess theuse of IEs in information system of the enterprise. When an InformationEntitydirectly corresponds to a business entity, its corresponding IESP instance cancontribute to compilation of business analytics if and when required. Some of theindividuals of each of the IEProcess, IEMP and IESP concepts corresponding tothis particular InformationEntity individual may be directly derived from theirrelevant counterparts in the business process architecture. The instances of theseEIA process concepts can trace back to the corresponding InformationEntityinstances in instantiated EIAOnt ontology with the help of properties that aredefined in the complete meta-model of entities and processes. The EIAOnt ontol-ogy also provides conceptualisation of separate processual links with the enter-prise management and enterprise strategy through EIAManagementProcess andEIAStrategyProcess concepts.

3.5 Traceability of EIA Concepts

The TraceabilityMatrix concept of EIAOnt ontology is used to establish trace-ability among EIA elements. Traceability determines whether and to what extentEIA information elements such as entities and processes can be traced backwithin information value chain of the enterprise. Traceability can provide infor-mation for:

– InformationEntity individual that was originally a business entity– Business entities correspond to a InformationEntity individual– InformationEntity individuals corresponding to a particular business entity– IEProcess individuals corresponding to an InformationEntity individual– IECRUDProcess individuals corresponding to an InformationEntity individ-

ual– IEMP individuals corresponding to a given InformationEntity individual– IESP individuals corresponding to a given InformationEntity individual– IEMP individuals corresponding to a EIAManagementProcess individual– IESP individuals corresponding to a given EIAStrategyProcess individual

This information is collectedby individuals of TraceabilityMatrix conceptwhichrepresent various traceability matrices, e.g. traceability matrix for business entityvs InformationEntity individuals and traceability matrix for InformationEntityvs IEProcess individuals etc.

3.6 Information Views

The Enterprise Information Architecture is expected to contain both static anddynamic views for information. Static views include structures of information ele-ments such as logical data models, data standards, metadata and taxonomies.Dynamic views include a business process model, an information work flow model


and a data flow model that describes the transitions and states of informationduring its lifecycle [50]. In EIAOnt Ontology, information views are conceptu-alised as the EIADiagram concept. The instances of this concept may be diagramsthat are useful in depicting data and information flow from one location in theinformation system (or enterprise) to the other. Traditionally, data flow diagrams(DFDs) and entity-relationship (ER) diagrams, originate from system analysis(SA) activity when designing the enterprise information models. UML Diagramsalso provide both high and low-level diagrams for information modelling. Infor-mation Flow Diagrams (IFDs) provide high level view of information flow fromone point to the other.

Business process models (BPMs) provide representation of business processesand their associations that an enterprise performs. BPMs belong to BusinessProcess Architecture (BPA) of the enterprise. However, these should be acces-sible to EIA architects, particularly for a business process-aware EIA designsuggested in this research.

4 Semantic Derivation of Enterprise IA from BusinessProcess Architecture

4.1 Business Process Architecture and the BAOnt Ontology

The approach presented in this paper derives the EIA elements from the funda-mental elements of business process architecture of an enterprise modelled usingthe Riva BPA methodology [51]. The Riva methodology concentrates on thebusiness of the enterprise and collects essential business entities (EBEs) withoutwhich the enterprise will cease to perform its function. It extracts from thesebusiness entities a set of units of work (UoWs), each of which leads to a businessprocess at the operational (case processes - CPs), managerial (case managementprocesses - CMPs) and strategic (case strategy processes - CSPs) levels respec-tively. Their names indicate the very nature of the tasks they carry out for aparticular EBE of UoW. The CMP and CSP, however, can be used by businessmanagers and/or CIOs to induce changes in BPA for the corresponding enti-ties corresponding to any new decisions made at the enterprise level. This needsto be carried out using enterprise information systems which rely on the EIA,hence highlighting the need for the EIA elements to be directly derivable fromthe BPA.

The BPAOnt ontology [52] in their BPAOntoSOA Framework capture thisontological representation of BPA as semantically enriched BPA. The BPAOntontology was developed in OWL [29] and contains all the above concepts andrelationships among these concepts, which makes a good starting point for thedesign of the EIA. The BPAOntoSOA Framework starts with crude BP modelsof an enterprise modelled using Role-Activity Diagrams (RADs) or more recentBP modelling languages like BPMN [53]. The business information that causesthe development of BPA of an enterprise can originate from some other sourcessuch as business documents etc, but this does not affect the EIA derivationprocess.


4.2 EIA Semantic Derivation from BPA

As the effort of developing the semantically enriched BPA is a one-off activ-ity for an enterprise corresponding to the developed business process architec-ture, and needs only minor adjustment corresponding to business change, anEnterprise Information Architecture that holds direct additional knowledge ofbusiness processes helps improving the automation of the EIA design process.Thus, it reduces the time requirements for interviews and questionnaires in thesense that the knowledge of business entities and processes is already capturedthrough a semantically enriched BPA. However, this time-saving is more relaiz-able once the process of semantically enriched BPA development is automated byeither accessing machine-readable business process models and workflows or byusing natural language processing techniques to analyse business documents andextract business process architectural elements. The EIAOnt ontology has beendesigned in OWL [29] using the approach by [34] and is based on IA concepts by[5,50] and [4,18], and forms a major component of semantic EIA derivation app-roach presented in this work. Fundamental EIA elements are EIA entities andEIA processes which are conceptualised as InformationEntity and EIAProcessconcepts respectively in the EIAOnt Ontology. The EIA derivation methodology(shown in Fig. 4) consists of a three-step approach for EIA derivation:

Fig. 4. Proposed approach for semantic derivation of EIA from BPA using the EIAOntontology.


1. The first step of this approach derives initial set of EIA entities and processesfrom the EBE and process instances of the BPAOnt ontology by instantiat-ing the BPAOntoSOA Framework for a particular enterprise. The semanticderivation of the EIA entities includes which EBEs qualify to become EIAentities and classifies each of them into concrete and conceptual entities. Thesemantic derivation also includes derivation of EIA processes from processconcepts of BPA, and also captures the associated relationships among processinstances, which are taxonomic (whole-part) and/or non-taxonomic.

2. The second step of this derivation uses the instances of the EIA informationentity and process concepts of the EIAOnt ontology to search for relatedconcepts in external domain ontologies. This also includes identifying thetaxonomic and non-taxonomic relationships among new and existing case-study entities and processes. The search for related entities and processesmay also result in formation of new external domain ontologies or updatingenriching external ontologies through a structured process of searching andcataloguing EIA information entities and processes.

3. Finally, more complex EIA elements such as EIA traceability matrices, EIAdiagrams (such as Information flow diagrams and/or Entity-Relationship dia-grams) and EIA information views are to be derived. As the name suggests,the EIA traceability matrices provide traceability information for informationentities (IEs) corresponding to EBEs in BPA, IEs vs EIA Processes.

5 Case Study - Cancer Care and Registration

We demonstrate our new approach by applying it to one sub-process of theCancer Care and Registration (CCR) process of King Abdullah Cancer Cen-tre in Jordan, used by [52]. The CCR case-study includes the sub-processes ofthe Patient General Reception, Hospital Registration, Cancer Detection, CancerTreatment and Patient Follow-up. Of these, we use Patient General Receptionsub-process (Fig. 5) that models the process of a patient’s general reception atthe Cancer Care Centre.

5.1 CCR BPA Elements

The EBEs and UoWs generated by the instantiated by BPAOntoSOA Frameworkare listed in Table 1. The output of CCR BPA is described as BPAOnt-CCR inFig. 4. The units of work are listed in bold. Corresponding to every UoW listed,the Riva BPA methodology generates an instance of CP concept and one instanceof CMP concept. Before identifying EIA elements, we propose to complete theBPAOntoSOA framework by adding an instance of the CSP concept for everyunit of work.

5.2 CCR EIA Elements

The BPA elements generated by BPA (Table 1) form the basis for the EIAentities and processes in this derivation approach. Use of SWRL rules [54] can


Fig. 5. Patient general reception sub-process in CCR case-study.

identify which EBEs qualify to become EIA entities. The EBEs, which are seman-tically derived as EIA entities, are classified as concrete or conceptual entities.This basic classification is useful because it can facilitate the decision-makingprocesses within business information system, e.g. supply chain and delivery ofa printed book or an electronic book (ebook) version and decide upon cost ofdelivery accordingly. In the CCR context, EMERGENCY UNIT is a physicalentity and has a location, whereas DATABASE is a conceptual entity.

The EIA derivation function generates the CRUD (Create, Read, Update andDelete) processes for every EIA entity and are sub-concepts of EIAProcess con-cept in EIAOnt Ontology. The CPs and CMPs also form an initial set of EIA (non-CRUD) processes. Once relationships between these concepts are establishedand traceability among these elements is determined, the EIA design functionthen moves on to search in external domain and process ontologies, using auto-mated ontology search processes to look for related entities and processes. Thisis possible only when domain specific knowledge for a particular business exists,e.g. cancer care domain knowledge for CCR case-study. Otherwise, the EIAdesign process can then develop new domain specific knowledge as its by-product.This search may result in significant increase in the number of EIA entities and


Table 1. BPA elements for the patient general reception sub-process in the CCRcase-study.

EBEs or UoWs

Patient General Reception

Receptionist (General)

Patient

Medical Records

Appointment

Patient File

Emergency Unit

Cancer detection unit

Database

Patient details

Case Processes (CPs)

Handle Patient general reception

Handle a patient medical record

Case Management Processes (CMPs)

Manage the flow of patient general reception

Manage the flow of patient medical record

processes. The traceability for these newly found EIA elements should establishmany-to-many relationships between EIA entities and the initial set of EIA enti-ties which were originally EBEs in BPA. Many-to-many relationships also existbetween EIA processes and the EIA entities they access, use and/or modify.Table 2 lists the set of EIA entities and processes in the case-study sub-processafter searching for related entity and process concepts in the NCI Thesaurus [55]and the Medical Ontology by Advance Genome Clinical Trials (ACGT) project[56]. The IEMP processes are the processes for CMPs in the BPA that manageCPs, and the IESP processes correspond to CSPs. We have noted that entitiesin these ontologies are not classified into concrete and conceptual entities andwe therefore recommend constructing a new ontology using this classificationfor EIA entities. The complete EIA for CCR is referred to an EIAOnt-CCR inFig. 4.

6 Discussion

A number of issues can be significant for a complete and correct derivationof an EIA. Firstly, we note that this approach significantly depends upon thecorrectness and completeness of the Riva BPA elements identified by instanti-ating [52]’s BPAontoSOA framework. The starting point of the BPAOntoSOAframework is, however, the business process models of the case-study enterprise


Table 2. Count of EIA elements derived from BPA for patient general reception sub-process in CCR case-study after look-up in ACGT medical ontology for entities.

EIA Element Count

EIA Entities 10

Entities derived from BPA 8

Entities searched from domain ontologies 2

Concrete entities 5

Conceptual entities 5

EIA Processes 41

EIA Processes 3

CRUD Processes 32

IE Management Processes - IEMPs 3

IE Strategy Processes - IESP 3

EIA Traceability Matrices 4

that were originally developed through on-site interviews in a previous research[57]. We suggest that the input for BPA development needs to be business doc-uments and business use cases and not necessarily BP models. This, however,should not affect the correctness and validity of EIA as the needed BPA ele-ments are instances of the BPAOnt concepts, and hence it will generate an EIAcorresponding to these BPA elements.

Secondly, although this approach causes EIA design to be heavily dependentupon the business process architecture, yet this becomes a strength and not aweakness of the approach because our proposed EIA is more business process-aware and it is more responsive to business process change if it includes a changemanagement mechanism that tracks any changes in BPA and makes correspond-ing adjustments to EIA architectural elements. Changes in BPA translate intochanges in Riva BPA business entities, processes or relations between its unitsof work. The change management mechanism of the EIA should capture thesechanges and initiate EIA ‘change processes’ to assess the impact of these changesand implement them. Thus, future information requirements, that are not yetexpressed in process models will need to emerge from a review of BPA models(driven by strategic management), followed by change in EIA. This limitation ordependence should be seen as an opportunity to review business process archi-tecture. Future information requirements that do not need change in processmodels may be met through change management processes acting independentlyof BPA.

Thirdly, the EIA derivation process needs to identify whole-part relationshipsamong the EIA entities derived from BPA and also for the entities searchedfrom external domain ontologies. We may call this refactoring of EIA entities.For instance, there are 10 RECEPTIONIST EBE instances in the BPA. Thisleads the information architect to define one RECEPTIONIST instance with


a variable place of deployment. Furthermore, the RECEPTIONIST entity maybe a sub-entity of a PERSON entity of which PATIENT is another sub-entity.The whole-part relationship may be added to the information about EIA entitiesusing OWL properties and SWRL rules (SWRL 2004).

Fourthly, in order to ensure the correctness of EIA derivation approach,human input from information architect (IA) may be essential at certain stagesof EIA derivation. For example, the IA’s input may be required when refactoringof EIA entities and processes is carried out. This may be carried out throughspecial-purpose dialogue boxes, which may render the above derivation processsemi-automated rather than being fully automated, hence further work for fur-ther evolution of the current work.

Finally, limitations of such an approach to derive EIA from BPA emergefrom those of BPA methodology. This approach is critically dependent upon theRiva methodology as the underlying BPA methodology. This is because the RivaBPA methodology is systematic and focuses on business entities and process ina way that brainstorms all entities and units of work that lead to processes,thus identifying the business components along its natural fault-lines and henceproviding a comprehensive (initial) set of EIA entities and processes.

7 Conclusion and Future Work

We have presented a new generic approach for semantically deriving the Enter-prise Information Architecture of an enterprise from its Business Process Archi-tecture. We have also demonstrated results of this derivation using a real andvalidated case study based on Cancer Care and Registration in Jordan, namelythe CCR case-study. Moreover, we have identified some shortcomings in the cur-rent BPAOntoSOA framework algorithm with respect to the extraction of EBEsfrom business processes and hence the reflection on the inclusion of case strat-egy process (CSP) in the BPAOnt ontology for a given BPA case. Currently,this approach is limited to the derivation of the fundamental EIA elementssuch as EIA entities and processes, and the traceability matrices that ensureforward/backward traceability from/to these elements. This approach is to beextended to generate more advanced EIA elements such as information viewsand information flow diagrams while exploiting the dynamic relations withinthe BPA’s units of work and the traceability of EIA entities and EIA processesthat access these entities. Further research includes the generalisation of thisapproach to a validated Semantic Framework, with maximum automaticity, forderiving the design of an enterprise information architecture from the given busi-ness process architecture of that enterprise.


References

1. Brancheau, J.C., Wetherbe, J.C.: Information architectures: methods and practice.Inform. Process. Manag. 22(6), 453–463 (1986)

2. Godinez, M., Hechler, E., Koenig, K., Lockwood, S., Oberhofer, M., Schroeck, M.:The Art of Enterprise Information Architecture: A Systems-Based Approach forUnlocking Business Insight. IBM Press, Boston (2010)

3. Hermon, P.: Developing an Enterprise Architecture. White Paper, Business ProcessTrends (2003)

4. Evernden, R., Evernden, E.: Information First: Integrating Knowledge and Infor-mation Architecture for Business Advantage. Elsevier Butterworth Heinemann,Oxford (2003)

5. Mosley, M.: Challenging EIM issues ahead. www.eiminstitute.com/library/eimi-archives, April 2010

6. Martin, A., Dmitriev, D., Akeroyd, J.: A resurgence of interest in informationarchitecture. Int. J. Inf. Manag. 30(1), 6–12 (2010)

7. Martin, J.: Information Engineering - Book I: Introduction. Prentice-Hall, Engle-wood Cliffs (1989)

8. Teng, J.T.C., Kettinger, W.J.: Business process redesign and information architec-ture: exploring relationships. DATABASE Adv. 26(1), 30–42 (1995)

9. Kettinger, W.J., Teng, J.T.C., Guha, S.: Information architectural design in busi-ness process reengineering. Int. J. Inf. Technol. 11, 27–37 (1996)

10. Chaffey, D., White, G.: Business Information Management, 2nd edn. Pearson Edu-cation Limited, Harlow (2011)

11. Mithas, S., Ramasubbu, N., Sambamurthy, V.: How information management capa-bility influences firm performance. MIS Q. 35(1), 237–256 (2011)

12. Sauer, C., Willcocks, L.: Establishing the business of the future: the role of organ-isational architecture and informational technologies. Eur. Manag. J. 21(4), 497–508 (2003)

13. Capegemini: How to make your business information count: generate a perfor-mance improvement of 27 percent by becoming an intelligent enterprise. http://www.uk.capgemini.com/sites/default/files/resource/pdf/-How to Make YourBusiness Information Count.pdf (2010). Accessed 14 April 2013

14. OMG: Business process model and notation. http://www.bpmn.org/ (2012).Accessed 27 Sept 2013

15. Berners-Lee, T., Hendler, J., Lassila, O.: The semantic web. Sci. Am. 284(5), 28–34(2001)

16. Hendler, J.: Agents and the semantic web. IEEE Intell. Syst. 16(2), 30–37 (2001)17. Wetherbe, J.C., Davis, G.B.: Developing a long-range information architecture. In:

Proceedings of National Computer Conference, Anaheim, Calefornia, pp. 261–269.ACM, New York, 16–19 May 1983

18. Brancheau, J.C., Schuster, L., March, S.T.: Building and implementing an infor-mation architecture. SIGMIS Database 20(2), 9–17 (1989)

19. Goodhue, D.L., Kirsch, L.J., Quillard, J.A., Wybo, M.D.: Strategic data planning:lessons from the field. MIS Q. 16(1), 11–34 (1992)

20. Rockart, J.F.: Chief executives define their own data needs. Harvard Bus. Rev.57(2), 81–89 (1979)

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

www.eiminstitute.com/library/eimi-archives

www.eiminstitute.com/library/eimi-archives

http://www.uk.capgemini.com/sites/default/files/resource/pdf/-How_to_Make_Your_Business_Information_Count.pdf



http://www.bpmn.org/


22. Sowa, J.F., Zachman, J.A.: Extending and formalizing the framework for informa-tion systems architecture. IBM Syst. J. 31(4), 590–616 (1992)

23. TOGAF: Phase C. information systems architecture - data architecture. http://pubs.opengroup.org/architecture/togaf8-doc/arch/ (2012). Accessed 1 Feb 2012 at17:47 Hrs

24. Strnadl, C.F.: Aligning business and IT: the process-driven architecture model.Inf. Syst. Manag. 23(4), 67–77 (2006)

25. CEiSAR: Enterprise modelling. White Paper. http://www.ceisar.com/ (2008).Accessed 6 July 2011

26. Dietz, J.L.G., Hoogervorst, J.A.P.: A critical investigation of TOGAF - basedon the enterprise engineering theory and practice. In: Albani, A., Dietz, J.L.G.,Verelst, J. (eds.) EEWC 2011. LNBIP, vol. 79, pp. 76–90. Springer, Heidelberg(2011)

27. Gruber, T.R.: A translation approach to portable ontology specifications. Knowl.Acquis. 5(2), 199–220 (1993)

28. Gasevic, D., Djuric, D., Devedzic, V.: Model Driven Architecture and OntologyDevelopment. Springer, Heidelberg (2006)

29. Smith, M.K., Welty, C., McGuinness, D.L. (eds.): OWL web ontology languageguide. http://www.w3.org/TR/owl-guide/ (2004). Accessed 29 Sept 2009

30. Fernandez-Lopez, M., Gomez-Perez, A., Juristo, N.: Methontology: from ontolog-ical art towards ontological engineering. In: Proceedings of AAAI Spring Sympo-sium, Menlo Park, California, pp. 33–40. AAAI Press (1997)

31. Lenat, D.B.: CYC: a large-scale investment in knowledge infrastructure. Commun.ACM 38(11), 33–38 (1995)

32. Fox, M.S., Barbeceanu, M., Gruninger, M.: An organisation ontology for enterprisemodelling: preliminary concepts for linking structure and behaviour. Comput. Ind.29, 123–134 (1995)

33. Guarino, N.: Formal ontology, conceptual analysis and knowledge representation.Int. J. Hum.-Comput. Stud. 43(5/6), 625–640 (1995)

34. Noy, N., McGuiness, D.L.: Ontology development 101: a guide to creating yourfirst ontology. Technical report SMI-2001-0880 (2001)

35. Breitman, K.K., Leite, J.C.S.P.: Ontology as a requirements engineering product.In: Proceedings of 11th IEEE International Requirements Engineering Conference.IEEE Computer Society (2003)

36. Partridge, C.: The role of ontology in semantic integration. In: 2nd Workshop onthe Semantics of Enterprise Integration, OOPSLA, pp. 1–10 (2002)

37. Kilpelainen, T.: Genre and ontologies based business information architectureframework (GOBIAF). Master’s thesis, University of Jyvaskyla, Finland (2007)

38. Pascot, D., Bouslama, F., Mellouli, S.: Architecturing large integrated complexinformation systems: an application to healthcare. Knowl. Inf. Syst. 27(1), 115–140 (2011)

39. Grunninger, M.: Enterprise modelling. In: Bernus, P., Nemes, L., Schmidt, G. (eds.)Handbook on Enterprise Architecture. International Handbooks on InformationSystems, pp. 515–541. Springer, Heidelberg (2003)

40. Wand, Y., Weber, R.: An ontological model of an information system. IEEE Trans.Softw. Eng. 16(11), 1282–1292 (1990)

41. Doerr, M., Hunter, J., Lagoze, C.: Towards a core ontology for information inte-gration. J. Digit. Inf. 4(1), 1–22 (2003)

42. Bunge, M.: Treatise on Basic Philosophy: Ontology I: The Furniture of the World.Springer, D. Reidel, Netherlands (1977)

http://pubs.opengroup.org/architecture/togaf8-doc/arch/

http://pubs.opengroup.org/architecture/togaf8-doc/arch/

http://www.ceisar.com/

http://www.w3.org/TR/owl-guide/


43. Bunge, M.: Treatise on Basic Philosophy: Ontology II A World of Systems. D.Reidel, Dordrecht (1979)

44. Wand, Y.: 21. In: A Proposal for a Model of Objects, pp. 537–559. Addison-Wesley,Reading (1989)

45. Evermann, J., Wand, Y.: Ontology based object-oriented domain modelling: fun-damental concepts. Requir. Eng. 10, 146–160 (2005)

46. Guarino, N., Oberle, D., Staab, S.: 1. In: What is an Ontology?, 2nd edn. Springer,Heidelberg (2009)

47. Allen, G.A., March, S.T.: A critical assessment of the bunge-wand-weber ontologyfor conceptual modeling. In: Workshop on Information Technologies and Systems,Milwaukee, WI, 9–10 December 2006, pp. 1–6

48. Sowa, J.F.: Knowledge Representation: Logical, Philosophical and ComputationalFoundations. Brooks/Cole, Pacific Grove (2000)

49. Dettinger, R.D., Stevens, R.J., Tenner, J.W.: Method and system for process-ing abstract derived entities defined in a data abstraction model. US PatentUS2006/0020582 A1, 26 January 2006

50. Fisher, M.: 1. In: Developing an Information Model for Information- andKnowledge-based Organisations. Facet Publishing, London (2004)

51. Ould, M.A.: Business Process Management: A Rigorous Approach. British Com-puter Society, Swindon (2005)

52. Yousef, R., Odeh, M., Coward, D., Sharieh, A.: BPAOntoSOA: a generic frameworkto derive software service oriented models from business process architectures. In:Second International Conference on Applications of Digital Information and WebTechnologies, 2009. ICADIWT ’09, London, UK, pp. 50–55 (2009)

53. Yousef, R., Odeh, M., Coward, D., Sharieh, A.: Translating RAD business processmodels into BPMN models: a semi-formal approach. Int. J. Web Appl. 3(4),187–196 (2011)

54. Horrocks, I., Patel-Schneider, P., Boley, H., Tabet, S., Grosof, B. N., Dean, M.:SWRL: a semantic web rule language combining OWL and RuleML. http://www.w3.org/Submission/SWRL/, May 2004

55. Ceusters, W., Smith, B., Goldberg, L.: A terminological and ontological analysisof the NCI thesaurus. Methods Inf. Med. 44, 498–507 (2005)

56. Cocos, C., Brochhausen, M., Bonsma, E., Martin, L.: Design principles of theACGT master ontology: examples and discussion. Technical report Deliverable 7.7, UPM, Madrid, Spain (2008)

57. Aburub, F.A., Odeh, M., Beeson, I., Pheby, D., Codling, D.: Modeling healthcareprocesses using role activity diagramming. Int. J. Model. Simul. 28(2), 147–155(2008)

http://www.w3.org/Submission/SWRL/

http://www.w3.org/Submission/SWRL/

Documents

[Lecture Notes in Business Information Processing] Enterprise Information Systems Volume 190 || Blueprint of a Semantic Business Process-Aware Enterprise Information Architecture: