Capture Dependencies to Derive Intelligence

Capture Dependencies to Derive Intelligence Marios Meimaris

Master of Science Artificial Intelligence School of Informatics University of Edinburgh 2009

Abstract Dependency modelling within a specified domain can help give insights regarding several aspects of the domain. By capturing the dependencies that exist within a business context, low-level analysis can be performed on business and business process models. In this thesis, a framework for capturing and modelling dependencies is defined, and a knowledge-based system that implements this framework is created. As a research and test domain, the book-selling domain has been considered, and specifically, focus was given on the business models and process models of four different types of book-sellers. Methods of analysing and comparing the derived dependency models are applied, and the results are discussed. The purpose of this thesis is (i) to study the subject of dependency modelling, (ii) apply knowledge-based techniques to implement a framework for capturing dependencies, and (iii) apply it to examples drawn from the business world and assess the derived results.

i

Acknowledgements I would like to thank my supervisor, Dr. Jessica Chen-Burger for her valuable support and guidance throughout the project, and for her patience over my endless questions. I would also like to thank my family for their unconditional love and support.

ii

Declaration I declare that this thesis was composed by myself, that the work contained herein is my own except where explicitly stated otherwise in the text, and that this work has not been submitted for any other degree or professional qualification except as specified.

(Marios Meimaris)

iii

Table of Contents Introduction............................................................................................................................1 1.1 Motivation...................................................................................................................1 1.2 Purpose and Objectives..............................................................................................1 1.3 Thesis Outline..............................................................................................................3 Background............................................................................................................................5 2.1 Business Modelling.....................................................................................................5 2.2 Business Process Modelling........................................................................................8 2.2.1 Business Process Modelling Definitions.............................................................8 2.2.2 Business Process Modelling Techniques.............................................................9 2.3 Conceptual Modelling...............................................................................................10 2.3.1 Representing Roles, Objects and Relationships.................................................10 2.3.2 Representing Ontological Knowledge...............................................................10 2.3.3 Reuse of knowledge and reference ontologies...................................................11 2.4 Dependency Modelling..............................................................................................13 2.4.1 Actor Dependencies...........................................................................................13 2.4.2 Activity Dependencies.......................................................................................15 2.5 KBST-EM..................................................................................................................16 2.6 The Book Selling Domain.........................................................................................17 2.6.1 Physical Store Based Business...........................................................................18 2.6.2 E-commerce book store.....................................................................................19 2.6.3 Book Publisher...................................................................................................19 2.6.4 Auction-Based book seller.................................................................................20 Modelling the Book Selling Domain....................................................................................21 3.1 Domain Ontology Design..........................................................................................21 3.1.1 Fundamental Design Choices............................................................................21 3.1.2 Overview of the Book Selling world.................................................................24 3.1.2.1 The Publishing Value Chain.....................................................................25 3.1.2.2 The Supply Chain of Book Production....................................................27 3.1.2.3 Inter-Business coalitions in the book selling world..................................28 3.1.3 The Role Ontology.............................................................................................32 3.1.3.1 Classifying Businesses..............................................................................33 3.1.3.2 Classifying Individuals...............................................................................35 3.1.4 The Resource Ontology.....................................................................................36 3.1.5 The Relationship Ontology...............................................................................41 3.1.6 Ontological Mappings........................................................................................44 3.2 Entity-Relationship Models......................................................................................44 3.2.1 Physical Store Based Business ER model.........................................................45 3.2.2 E-Commerce Based Business ER model..........................................................46 3.2.3 Publisher Based Business ER model.................................................................46 3.2.4 Auction Based Business....................................................................................47 3.3 Process Models.........................................................................................................48 3.3.1 Physical Store Based Business Process Model..................................................51 3.3.2 E-Commerce Based Business Process Model...................................................58 3.3.3 Publisher Business Process Model....................................................................58 3.3.4 Auction Based Business Model........................................................................58 System Implementation........................................................................................................61 4.1 Introduction...............................................................................................................61 4.1.1 Motivation.........................................................................................................61 iv

4.1.2 Modelling Environment and Language............................................................62 4.1.2.1 KBST-EM overview...................................................................................62 4.1.2.2 CLIPS overview ........................................................................................64 4.2 System Design Details..............................................................................................65 4.2.1 Diagram Representation – Model Formalization..............................................65 4.2.1.1 Representing Ontology Cards...................................................................66 4.2.1.2 Representing Entity-Relationship Cards...................................................67 4.2.1.3 Representing UML Activity Diagram cards..............................................68 4.2.2 Inference Engine...............................................................................................70 4.2.2.1 Ontology Classification.............................................................................71 4.2.2.2 Activity decomposition handling..............................................................72 4.2.2.3 Dependency derivation rules.....................................................................73 4.2.2.4 Creation of dependency diagrams.............................................................80 Experiments..........................................................................................................................83 5.1 Using the specialized dependency set...........................................................................84 5.1.1 Physical Store Based Business.........................................................................84 5.1.1.1 Resource dependencies between actors.....................................................84 5.1.1.2 Dependencies between activities................................................................88 5.1.2 E-Commerce Based Business...........................................................................89 5.2.1.1 Resource dependencies between actors.....................................................89 5.1.2.2 Dependencies between activities....................................................................90 5.1.3 Publisher Business.................................................................................................90 5.1.3.1 Resource dependencies between actors.........................................................90 5.1.3.2 Dependencies between activities................................................................91 5.1.4 Auction Based Business....................................................................................91 5.1.4.1 Resource dependencies between actors.........................................................91 5.1.4.2 Dependencies between activities................................................................92 5.1.5 Scoring the specialized dependency models.....................................................92 5.1.6 Comparing two different versions of a business....................................................96 5.2 Using the generic dependency set.............................................................................99 5.3 Generic vs. Specialized Dependencies...................................................................106 Evaluation...........................................................................................................................107 6.1 Evaluation of the conceptual modelling.................................................................107 6.1.1 Ontology Evaluation........................................................................................107 6.1.2 Entity-relationship and process models evaluation.........................................108 6.1.2.1 Soundness ...............................................................................................108 6.1.2.2 Realism....................................................................................................109 6.1.2.3 Completeness and coverage....................................................................110 6.2 Knowledge-based system evaluation.....................................................................110 6.2.1 KBS Verification.............................................................................................110 6.2.1.1 Consistency of the knowledge-base........................................................111 6.2.1.2 Correctness of the inference process.......................................................111 6.2.1 KBS Validation................................................................................................112 Conclusions and Future Work............................................................................................115 7.1 Conclusions..............................................................................................................115 7.2. Future work.............................................................................................................116 Bibliography.......................................................................................................................119 Appendix A.........................................................................................................................123 Appendix B.........................................................................................................................139 Appendix C.........................................................................................................................145 v

Appendix D........................................................................................................................151 Appendix E.........................................................................................................................159

vi

List of Figures Figure 1: Layers of the approach............................................................................................3 Figure 2: Business layers. Source: [34]..................................................................................5 Figure 3: Graphical notation for actor dependencies. Source: [i* guide website]...............15 Figure 4: Dependencies between tasks and resources. Source: [9]......................................16 Figure 5: The three upper level classes................................................................................22 Figure 6: The publishing value chain. Source: [8]...............................................................26 Figure 7: One view of the supply chain for books (Source: [8])..........................................27 Figure 8: The supply chain for books...................................................................................28 Figure 9: Classification of Business Models. The arrow in ‘Role’ indicates that it is not the root class of the ontology......................................................................................................35 Figure 10: Life-span of services...........................................................................................38 Figure 11: Specialization of facilities...................................................................................39 Figure 12: Partial ontology for resources. Notice that a 'Book Product' is a direct subclass of 'Object', because it contains both tangible (physical books) and intangible (electronic books) objects.......................................................................................................................40 Figure 13: Top classification of relationship types...............................................................41 Figure 14: Role-Object relationship type classification.......................................................42 Figure 15: Role-Role and Object-Object relationship type classifications..........................43 Figure 16: Model boundary..................................................................................................45 Figure 17: Generic 'sell' process taken from the MIT Process Handbook...........................50 Figure 18: Example case of simultaneous control flow and object flow.............................50 Figure 19: Parts of 'Distribute Physical Asset {Wholesaler/Retailer}'.................................51 Figure 20: Process 'Distribute Book {Physical Store Based Business}'..............................52 Figure 21: Decomposition and sequencing of 'Buy books to stock and to order'................53 Figure 22: Decomposition and sequencing of 'Sell books via physical store'......................55 Figure 23: Decomposition and sequencing of 'Identify potential customer's needs'............55 Figure 24: Decomposition and sequencing of 'Inform potential customers'........................56 Figure 25: Decomposition and sequencing of 'Receive order at register'............................56 Figure 26: Decomposition and sequencing of 'Process book order'.....................................57 Figure 27: Decomposition and sequencing of 'Receive payments at register'.....................57 Figure 28: Decomposition and sequencing of 'Deliver book to customer'...........................57 Figure 29: A simplistic view of the system and its inputs and outputs................................62 Figure 30: Sample CLIPS rule syntax. If (fact1 a b) and (fact2 b c) are both already asserted in the fact-list, then the rule is activated and executes the list of commands (rhs). ..............................................................................................................................................65 Figure 31: Relationship rel(A,B) between Entities A and B, and the "from" and "to" nodes of the two arcs......................................................................................................................68 Figure 32: Activity decomposition with the use of expansion cards....................................69 Figure 33: Layered view of the levels of information..........................................................70 Figure 34: CLIPS code for the rule for classifying classes based on their 'Subclass Of' relationships..........................................................................................................................71 Figure 35: Case 1..................................................................................................................72 Figure 36: Case 2..................................................................................................................73 Figure 37: Case 3..................................................................................................................73 Figure 38: Physical Store Based Business - Dependencies derived from ER diagram........84 Figure 39: E-Commerce Based Business - Dependencies derived from ER diagram.........89 Figure 40: Publisher Based Business - Dependencies derived from ER diagram................91 Figure 41: Dependency scores for all four models...............................................................95 vii

Figure 42: Dependency internal scores for all four models.................................................96 Figure 43: Publisher Based Business (limited outsourcing) - Dependencies derived from ER diagram...........................................................................................................................97 Figure 44: Comparison of the weighted score curves for the two versions of the publisher business model's ER diagram. Several values of a have been tried, starting from 1 and gradually going to 0. Upper curve: new version, Lower curve: original version.................98 Figure 45: Number of dependencies derived from ER diagrams for all four models........100 Figure 46: Number of contract dependencies for all four models......................................101 Figure 47: Number of service producer-buyer dependencies for all four models..............102 Figure 48: Number of 'product seller-buyer' dependencies for all four models.................103 Figure 49: Overview of the derived dependency counts for all four business models......103 Figure 50: Comparison of the number of object-flow dependencies and task dependencies for all four models, from their basic selling subprocess (red: task dependencies, blue: object-flow dependencies)..................................................................................................105 Figure 51: ER model for Physical Store Based Business...................................................124 Figure 52: ER model for E-Commerce Based Business....................................................125 Figure 53: ER model for Publisher Business.....................................................................126 Figure 54: ER model for Auction-Based Business.............................................................127 Figure 55: Top process for E-Commerce Based Business.................................................128 Figure 56: Decomposition of 'Buy books to stock and to order' for E-Commerce Based Business..............................................................................................................................128 Figure 57: Decomposition of 'Sell books via electronic store' for E-Commerce Based Business..............................................................................................................................129 Figure 58: Decomposition of 'Identify potential customers' needs' for E-Commerce Based Business..............................................................................................................................130 Figure 59: Decomposition of 'Inform potential customers' for E-Commerce Based Business. Note that the upper "Finish" node denotes the end of the process, while the lower "Finish" node is a 'Finish (decomposition)' node...............................................................131 Figure 60: Decomposition of 'Obtain order in electronic store' for E-Commerce Based Business..............................................................................................................................132 Figure 61: Decomposition of 'Receive payment in electronic store' for E-Commerce Based Business..............................................................................................................................132 Figure 62: Decomposition of 'Deliver product purchased over internet' for E-Commerce Based Business...................................................................................................................132 Figure 63: Top process for Auction Based Business..........................................................133 Figure 64: Decomposition of 'Broker books via internet' for Auction Based Business.....134 Figure 65: Decomposition of 'Manage auction' for Auction Based Business....................135 Figure 66: UML activity diagram notation in KBST-EM..................................................144 Figure 67: This is the code used to represent diagram objects of Ontology cards. Notice that there are two types of assertions taking place each time. A general assertion to capture the information of the object, and a specialized assertion to capture specifically the class or instance that is retrieved.....................................................................................................144 Figure 68: This is the code used to represent 'Subclass Of' links of Ontology cards.........145 Figure 69: Internal structure of the system.........................................................................148 Figure 70: A simple case of a business buying a product and a wholesaler selling the product................................................................................................................................154 Figure 71: Physical Store Based Business dependency diagram from ER model.............158 Figure 72: Physical Store Based Business object flow dependencies between activities for subprocess 'Sell books via physical store'..........................................................................159 Figure 73: Physical Store Based Business task dependencies from 'Sell books via physical viii

store' subprocess.................................................................................................................160 Figure 74: E-Commerce Based Business dependency diagram from ER model...............161 Figure 75: E-Commerce Based Business object flow dependencies between activities for subprocess 'Sell books via physical store'..........................................................................161 Figure 76: E-Commerce Based Business task dependencies from 'Sell books via electronic store' subprocess.................................................................................................................162 Figure 77: Publisher Business dependency diagram from ER model................................163 Figure 78: Publisher Business object flow dependencies between activities for sub-process 'Sell books via electronic store'..........................................................................................164 Figure 79: Publisher Business task dependencies from 'Sell books via electronic store' subprocess..........................................................................................................................165 Figure 80: Auction Based Business dependency diagram from ER model........................166 Figure 81: Auction Based Business object flow dependencies between activities for subprocess 'Broker books via internet'...............................................................................167 Figure 82: Auction Based Business task dependencies from 'Broker books via internet' subprocess..........................................................................................................................168

List of Tables Table 1: The four types of business models and their specializations. Source: [45]..............6 Table 2: BPM Goals and Requirements. Source: [17]...........................................................9 Table 3: External services and their outsourcing. *Book Packaging is performed partially. ..............................................................................................................................................31 Table 4: Internally handled services vs. outsourced services...............................................32 Table 5: Classification of the four business models.............................................................33 Table 6: Classification of external businesses......................................................................34 Table 7: What each role manipulates....................................................................................37 Table 8: Facilities of interaction with customers for each business.....................................39 Table 9: Relationships in the scope of the Physical Store Based Business..........................43 Table 10: Mappings of our ontology with four business ontologies in the top level...........44 Table 11: Entities and Relationships in the physical store retailer model............................48 Table 12: Comparison of implementation tools and methods..............................................63 Table 13: Fields and values for the dependency fact assertions...........................................79 Table 14: Dependency model notation created in KBST-EM. Notice that dependencies of control flow between activities are not modelled because they are based on the activity diagrams' control flow links, and thus are the same.............................................................82 Table 15: Physical store based business - Specializations of contract dependencies...........85 Table 16: Physical Store Based Business - Specializations of 'product seller-buyer' dependencies........................................................................................................................85 Table 17: Physical Store Based Business - Specializations of 'services producer-buyer' dependencies........................................................................................................................86 Table 18: Weights for specialized dependencies..................................................................94 Table 19: Representing Ontology items.............................................................................145 Table 20: Representing ER diagram items.........................................................................146 Table 21: Representing UML Activity Diagram items.......................................................147

ix

Chapter 1 Introduction 1.1 Motivation

Dependency modelling within a business contexts is a subject that can provide powerful insights for assessing and analysing the behaviour and complexity of business models, and set the basis for carrying out dependency-related comparisons between businesses. The use of knowledge-based techniques in the business domain is constantly attracting attention, since it can help provide automated analysis of interesting aspects within the business world. By studying the dependencies that exist within a domain, a different view of the domain is provided, in a level that is not obvious in the first place. Hence, the motivation of this approach is drawn from the desire to evaluate the effect of dependencies within a business domain, and how these help point out interesting information that is derived from the existing knowledge.

1.2 Purpose and Objectives

The purpose of this project is to combine knowledge engineering, conceptual modelling and logical programming techniques to create a framework that will be used to capture, model and understand the different kinds of dependencies that exist within a business context. In particular, we have chosen the book enterprise domain as our research and test domain. The book domain is one that is a recurring test-bed in both business and information technologies research domains, and its selection is also supported by the fact that its components (actors, resources etc.) are relatively easy to identify. Four different book selling business models will be examined, namely the physical store retailer, electronic store retailer, publisher and online auction-based book seller. This will be done 1

in the following steps: 1.The four business models will be modelled in two different aspects, namely entity-relationship diagrams and process models. The derived models will be used as the system's input. 2.Using conceptual modelling techniques, an ontology will be created that will provide the common backbone of the knowledge-based system, and will be shared by the system's components. 3.The knowledge-based system will be implemented. Its main components will be the knowledge base and the inference engine. The knowledge base will contain the rules that will be applied on the models created in step 1, in order to infer dependencies. The inference engine will control the inference process by using the created knowledge base. 4.The derived dependencies will be used to create the dependency models, using graphical notation from existing research. 5.The dependency models will be analysed, in order to draw insight and compare the four business models. This layered approach that we will follow can be seen in figure 1. The main objective of this thesis is twofold: ➢To

provide a framework for performing knowledge-based dependency modelling and

analysis, ➢To

apply this framework in the book selling domain and assess the effectiveness of

the approach. While the first point refers to the actual development of the knowledge-based system, the second point projects the need to thoroughly discuss the conceptual modelling step of this project, in order to better evaluate the system's effectiveness.

2

Figure 1: Layers of the approach

1.3 Thesis Outline

The thesis consists of 7 chapters. Chapter 2 will serve as the presentation of the literature review and background information that was needed for the project. In chapter 3, the methodology using in the conceptual modelling portion of the project will be presented. Chapter 4 covers the knowledge-based system's overview and the basic design choices that were made for its implementation. Chapter 5 will present several experiments that we conducted, as well as the derived conclusions. Chapter 6 presents the evaluation of the performed work, and chapter 7 will conclude the thesis.

3

4

Chapter 2 Background 2.1 Business Modelling

The term Business Model refers to formal and informal ways of representing the basic aspects of a business agent (company, individual etc.), based on the nature of its operations, strategies, purposes, processes and so on. A common mistake that happens in the literature is to confuse a business model with the strategy of a business, as this issue is addressed thoroughly in [39], but even though the two terms do share a large amount of overlap, the term ‘business model’ came to be interpreted as a way to replace every other strategic planning method, especially for electronic businesses, at the time it first came to existence [26]. Although this led to a disappointment over business modelling, it became clearer and clearer ever since that business models are an important tool for the strategic planning and set up of a business, be it an internet-based business or not. This importance lies in the fact that such models help clarify a business’s most important questions, like how is value created, who the business is addressed to, what is it trying to achieve, what is being sold/offered and so on. According to Osterwalder and Pigneur [34], business planning of an organization can be seen as a division in three different layers, where the strategy layer and business model layer form a clear distinction between the two terms. These layers can be seen in figure 2.

Figure 2: Business layers. Source: [34] 5

The issue of business models hasn’t been thoroughly addressed in the literature, and it isn’t completely understood [24] but Weill et al. [45] propose a framework for the generic classification of businesses. This framework classifies businesses based on what types of services they offer. This classification produces four basic types of businesses, and 4 specializations for each type, thus leading to a total of 42=16 different subtypes. The four basic types of business are in fact answers to the question “what kind of rights are being sold over an asset”, and they are Creator, Distributor, Landlord and Broker. The 4 generic specializations answer a different kind of question. That is “what types of assets are involved”. Figure 3 shows the basic business models and how these can be further specialized according to the nature of the assets they are dealing with. The table shown in table 1 contains the types of the four business model archetypes and terms from this approach will be drawn later on in the creation of ontologies and the mapping of the various actors and roles in our approach.

Table 1: The four types of business models and their specializations. Source: [45]

A brief explanation of the basic business model archetypes is given below: –

Creator : The Creator model is the one that is responsible for the design and creation of new products, usually using raw materials. This makes it perhaps the most important business model, as many other models use the products that are created by Creator businesses. The raw materials come from suppliers, but even so, the Creator model is one of the first links in the industry supply chain. 6

–

Distributor : Distributors can be Wholesalers or Retailers, the difference being in the final receptor of the products they sell. Wholesalers buy products that are usually fully prepared for final use by end-customers, but can sometimes add extra value, by repackaging the product, taking care of delivery issues etc.

–

Landlord : The term ‘Landlord’ is used by Weill et al. to describe businesses that sell the right to use some asset. The use of the asset is usually limited in time, and depending on the nature of the asset, it can refer to services like renting a physical location, renting manpower, skills and knowledge to perform a task that the buyer can’t handle on their own etc.

–

Broker : Brokers don’t acquire ownership of the assets whose selling they are involved to. This model is limited to providing the grounds for the matching of buyers and sellers, so this gives it an intermediary role between the seller and the buyer of the asset. The four basic archetypes described above are then further specialized to more

specific business models, depending on the nature of the assets that are involved in their transactions. The nature of the assets is also categorized to four types, as mentioned earlier, these being: –

Financial assets : these can be cash, insurance and anything that is of financial nature and can be sold or leased,

–

Physical assets : physical assets are products that have durable, physical nature, like electronic devices, buildings etc.

–

Intellectual assets : these include intangible assets, like intellectual property rights,

–

Human assets : this type of asset refers to manpower and knowledge, presented as skills and service offerings. According to this approach, most, if not all, of the existing businesses can be

classified based on the two dimensions of the table shown earlier, which can also be seen as two questions, “what rights of use are being sold” and “what types of assets are involved”. Business models are not created with the intention of describing more detailed aspects of an enterprise’s operations, but is centred on answering more high-level questions, as are these two. When it comes to describing in specific detail how a business

7

performs its internal operations and activities, then another modelling method is used, Business Process Modelling.

2.2 Business Process Modelling 2.2.1 Business Process Modelling Definitions A lot of definitions exist in the literature for Business Process Modelling (BPM). Perhaps the most commonly used in the literature is the one from Davenport [10], where a process is defined as the set of activities that is required in order to create a certain output for the customers or markets that need it. It emphasizes more on how a certain target is achieved through work, thus making it more low-level than other modelling methods that orbit around questions like why things are done or what are they trying to accomplish. In BPM, the goal is usually known from the start, and it is the breaking of the high-level, visible activities to more specific and descriptive processes and sub-processes that is of focus in BPM. In other words, a Business Process Model is a model that captures the structured and sequenced activities that a business performs in order to produce some output for a particular business agent (e.g. customer). These activities can span through time and space. The scope of BPM is to enable and promote a better understanding of the nature of business processes as well as improve them, and is aimed at helping people make, as well as evaluate business decisions. The description of a business’s processes and activities in a detailed level helps achieve this better understanding, and at this level of high detail one can see more clearly if and how a process can be improved, what needs to be changed and what is essential to remain the same. In essence, BPM requires capturing the knowledge of how processes operate in an enterprise, thus making it a rather knowledge-intensive task. By capturing this formerly tacit knowledge and modelling its characteristics in an explicit and defined manner, the derived models can be used for a variety of tasks, that not only have to do with automating processes with the creation of software, but also with analysing the derived models from a theoretical scope and thus providing the ability of performing structured critical analysis on the operations of a business. Table 2 summarizes the goals and requirements that are set for BPM. According to [17], if these goals and requirements are to be met, then the 8

corresponding model ought to be created in a level of detail that covers all the necessary information that describes a process’s functionality. This information can be about the actors that are involved in a process, the decomposition of a process into activities and subactivities and so on.

Table 2: BPM Goals and Requirements. Source: [17]

2.2.2 Business Process Modelling Techniques There exist several different approaches on how to represent business processes in the context of BPM. Reviews and evaluations of the most commonly used modelling techniques are made, among others, in [17] and [23]. These include the IDEF family of modelling methods first presented in [30], modelling using UML diagrams with an overview of the issues and methods that arise in business modelling and UML found in [11] and Petri nets, for which a discussion on their use and properties can be found in [31]. Generally, representing flow control is a key aspect of the conceptual part of modelling business processes. Flow control diagrams can be created using a variety of modelling methods, including IDEF3 and Petri nets, but for our purposes UML Activity Diagrams are used. The main reason why these are selected among the other options is that the different actors that are involved in a process are visible in the same diagram, with the use of swim lanes. Also, there was no need to use IDEF’s full functionality and representational abilities, and since it is a more complex modelling technique, addressed to 9

more specific contexts, Activity Diagrams fulfilled our purposes more conveniently. In any case, it is suggested that the best modelling technique is dependent on the context in which it is needed [33], making UML Activity Diagrams a reasonable choice for our purposes.

2.3 Conceptual Modelling 2.3.1 Representing Roles, Objects and Relationships In order to represent the relationships between the various roles in the book enterprise domain, a modelling technique needs to be used that can represent business relationships as social interactions between the roles that are involved. Role modelling in general can be done using a variety of methods, as there is no standard method that can be referenced specifically for this reason. Wagner [44] proposes a framework of modelling interactions between agents and objects, that can be used for enterprise modelling purposes, and is based on the widely used Entity-Relationship modelling method that was first introduced by Chen [6], but this approach is more centred on representing agents that are parts of the internal processes of an enterprise, and thus, is not applicable to more macroscopic views where the whole enterprise can be seen as a role. Even though Entity-Relationship (ER) diagrams are mainly intended to address data modelling for database design, they can also be used as a conceptual modelling tool to address this issue, and this type of diagram is used in our approach. The entities can be both roles (e.g. enterprises, individuals etc.) and objects (e.g. physical locations, book products, etc.). This way all functional relationships can be represented graphically and in a rather simple manner, by using ER diagrams, which also provides an easy understanding of the graphically represented knowledge by non-experts.

2.3.2 Representing Ontological Knowledge Another design issue that needs to be addressed is how to represent the conceptual knowledge of the domain. This can be done by creating an Ontology of concepts, be they roles (actors), objects, relationship types, dependency types and so on. The advantages of using ontological knowledge are of fundamental importance in the creation of Knowledge 10

Based Systems, as such systems need a commonly shared ontological basis for their components to interact with each other and make use of the same knowledge that is used in the domain. Ontologies are becoming increasingly popular as a conceptual modelling method, and as Gruber (in [20]) states, formal ontologies can be seen as “a way of specifying content-specific agreements for the sharing and reuse of knowledge among software entities ”. In [20], several guidelines on ontology creation are presented, with perhaps the most important of them being the view that ontological commitment should be minimized as much as possible. This means that, when creating an ontology, attention should be given so that the claims that are made are exactly as many as they should be in order to cover the domain, without having to reach an excess of knowledge that could otherwise be avoided. This principle is used in the design of the ontological knowledge, and in our approach we try to make a distinction between the necessary common knowledge, and the sub-domain specific instantiations of that common knowledge. The book domain’s concepts show diversity in their nature, as it covers many different conceptual entities, with classification being generic in some cases, and contextspecific in others. For example, differences between business model types have to be apparent (context-specific), but also differences between entities at the top level have to be clear also, e.g. tangible vs. intangible objects etc. (generic classification). For this reason, the ontology needs to incorporate an application-specific approach but also to follow some top-level ontology guidelines, in order to be able to handle the classification of all the diverse concepts involved. This is discussed in [22] and also this approach is taken in the development of the ABC model in [4], which is intended to form a common meta-model for the integration of different domain ontologies and semantic content in general.

2.3.3 Reuse of knowledge and reference ontologies As Schreiber et al. [38] stretch out, when modelling the conceptual knowledge of a domain, it is important first to look for existing ontologies that can be reused and/or adapted to one’s purposes. The rationale behind this is that existing ontologies are usually both already approved and tested, and the important thing is that 11

ontology creation

methodologies are inclined towards reusability of such knowledge. In the business domain, there have been several ambitious approaches of creating standard ontologies. The most notable ones are listed here: –

e3 – Value Ontology : this ontology was introduced in [19] and it is based on viewing the notion of ‘value’ as the main driver within the business context. The ontology’s design was based on the creation of a small number of basic concepts, like actors, value objects, value ports, value activities, among others, and their small number is what makes it easily understandable and, therefore, conveniently usable by the ontology’s user.

–

Enterprise Ontology : as part of the Enterprise Tool Set project [13] the enterprise ontology was created with the intention of becoming the intermediary connection for the collaboration and communication of different parties, be they people, organizations or software components. The main terms of the ontology are Activity, Organization, Strategy, Marketing and Time.

–

Resource-Event-Actor (REA) Ontology: the REA ontology was first created by McCarthy [29] as a model for accounting purposes, but was later developed to its more formal character in [16], which also used Sowa’s ontological design principles [40]. As the name suggests, the main terms are Resource, Event and Actor. The design of the ontology is based on the idea that any business transaction can potentially be represented as a exchange of resources between actors, within the context of an event.

–

Business Model Ontology (BMO) : Osterwalder’s Business Model Ontology [34] is focused on describing business models according to a classification of nine concepts within four categories, which are Customer Interface, Product, Infrastructure Management and Financial Aspects. It is based on the view of a single organization, thus making it more adaptable to distinct case modelling, instead of a more broader view. Andersson et al. [1] describe an approach of creating a reference ontology for

business models, by using three of the above ontologies (namely, the REA, e3 – Value and Business Model ontologies) and drawing from their concepts and principles. In a similar manner, the ontology created in our approach draws from design choices from these

12

popular business ontologies, but ultimately, its nature is unique as we are more concerned in creating a descriptive ontology of the domain that is fit for the purposes of our knowledge-based system, than making knowledge reuse the main target. Insight is drawn from these approaches, and there is an overlap in some commonly used terms. Even though the naming schemes of all the approaches differ, some of the meanings that the terms carry can be considered to be very similar (such as activity-event, actor-role etc.).

2.4 Dependency Modelling As part of the purpose of this project is to build a framework for the automatic derivation of dependencies between entities, theory concerning dependency modelling ought to be discussed. Because the description of the book domain will be done based on Entity-Relationship and Process models, we are concerned with two types of dependencies, actor dependencies and activity dependencies. Actor dependencies are formed between two actors (roles) and are intentional. Activity dependencies are formed between two activities (tasks, sub-processes) in a process model.

2.4.1 Actor Dependencies The term ‘actor dependency’ is defined in [14] as an ‘agreement’ between two interacting actors over a certain object. The two actors are called Depender and Dependee, and the object around which the dependency is focused is called Dependum. The Depender is the actor who depends on the Dependee on accomplishing the Dependum. This approach was introduced in [47], called the i*-framework (pronounced “i-star”). It is based on business modelling from a strategic actor dependency point of view. Yu and Mylopoulos in [47] argue that the interdependencies between actors within and between organizations are a powerful way of pointing to organizational work patterns, and they make the notion of actor dependency central to their research. The nature of the dependum is used to classify actor dependencies in four categories, resource, task, goal and softgoal dependencies. This classification is adopted partly in our approach are, and the four dependency types are described briefly as follows: –

Resource Dependencies : by the term ‘resource’, everything that can be produced and

13

consumed is included. Resources can be physical (e.g. a physical book) or non-physical (e.g. data, information etc.). This dependency appears when the depender expects the dependee to provide him with a certain resource. –

Task Dependencies : this type of dependency occurs when the dependum is a task (activity) that the depender expects the dependee to undertake. As an example, the Accounting department (depender) can depend on the Sales department (dependee) to provide them with needed sales information (dependum).

–

Goal Dependencies : unlike task dependencies, where the task that needs to be carried out is a small fraction of the overall processes within the organization, goal dependencies are more macroscopic and usually have to do with rigid goals that the depender wants the dependee to accomplish. The depender does not care about how the dependee will bring about this new state of affairs in the world, but only relies on them to achieve the given goal (e.g. the customer depends on the book store to buy a certain book)

–

Softgoal Dependencies : softgoals are like goals, but they differ in that the results that are caused by softgoals cannot usually be detected at once, and their nature is a lot less clear than that of goals. Examples of softgoals can be cases where one department (depender) depends on another department (dependee) to have a good level of quality (dependum) in their organizational interactions. The i*-framework also provides a graphical notation and modelling method for

representing actor dependencies. The graphical notation for actors, dependums and dependencies between them can be seen in figure 3. Because part of our work is to be able to automatically generate graphical representations of dependency models, this notation is adopted in the creation of actor dependency models.

14

Figure 3: Graphical notation for actor dependencies. Source: [i* guide website]

2.4.2 Activity Dependencies Activity dependencies involve fewer types of dependencies in their classification. The reason for this is that they are not intentional, at least not in the same sense as actor dependencies are. Using the same terminology that is used in the i*-framework, the dependency between two activities (depender activity and dependum activity) is considered to be not intentional only in the sense that an activity is a non-intentional concept that has no conscience of itself. So any intentionality that activity dependencies may carried is only implied within the actors that perform them. In [9] a framework for classifying interdependencies between tasks (activities) and resources is given. The work presented in that article is focused on handling coordination of tasks by examining the tasks’ interdependencies and arguing that the two are strongly connected, since coordination of tasks is affected by the way these tasks handle, produce, consume or share resources. Figure 4 summarizes the dependencies considered in [9]. It is reasonable to say that the two top types of dependencies that we are considering in our work, i.e. actor and activity dependencies, can be correlated and are not completely independent. This though will be covered in detail in the modelling design choices description.

15

Figure 4: Dependencies between tasks and resources. Source: [9]

2.5 KBST-EM The tool that we selected to use for the modelling of the domain is KBST-EM (Knowledge Based Support Tool for Enterprise Modelling]). KBST-EM is a generic modelling system that supports graphical modelling in a variety of different diagram techniques, such as UML, IDEF3, Entity-Relationship, Ontology diagrams etc. It is built upon Hardy, a programmable diagram platform that supports the creation of new diagram types as well. As KBST-EM is sitting on top of an empty knowledge based system shell, it is equipped with CLIPS logic programming facilities. CLIPS is a language based on C, that is especially designed for the creation of expert systems, thus it integrates the ability of working with a knowledge base where facts are saved (asserted), with the ability to define rules that are triggered and executed at run-time. The reasons why this tool was selected can be summarized in the following points:

➢

The ability to create different types of diagrams proved to be very useful, because this way not only modifications can be made in existing diagram types, but new diagram types can be created, such as the Actor Dependency Model described earlier,

➢

The large variety of supported diagram types covered our requirements for the modelling part, which involved at least three different existing diagram types, 16

namely UML Activity Diagram, Entity-Relationship Diagram, Ontology Diagram., ➢

The ability to modify existing diagram types can be helpful in defining new diagram objects and edit their attributes. This is not done in a manner that disobeys the modelling principles of each diagram type, but is proved helpful in interpreting and representing the diagrams with CLIPS code,

➢

Using code written in CLIPS, the diagrams can be represented in the knowledge base in any way we choose to do so, leaving endless abilities in the manipulation of the graphical knowledge,

➢

Rules can be defined, so that they can be activated whenever a new dependency is captured, this way creating and populating Dependency Diagrams,

➢

Since the knowledge base is commonly shared, the Ontology can be represented and it is then easy for the rest of the models to share the ontological knowledge.

2.6 The Book Selling Domain The reasons why this domain is selected over many possible alternatives lie in the ease of understanding of its nature as a commercial domain, and the fact that its process materials are easier to identify than in other more complex cases. Most importantly, though, the book selling industry is one that has been tremendously impacted and revolutionized with the use of the internet and information technologies, and therefore is a potentially interesting domain to work on. Book-selling includes commercial dependencies between its actors and an abundance of easily identifiable conceptual entities (e.g. actors include Book-seller, Publisher, Author, Customer etc.). Furthermore, the sub-domains of the book-selling world can have diversity in their nature, as there can be different kinds of actors (companies mainly) that share, in essence, the role of “book-seller”, but their process models can be differentiated from the generic retailer-model. Depending on their business models, and thus the way the various companies perform business, different categories of companies can arise, and in fact do exist in the business world, even though they can be associated with the same domain. For example, an e-commerce book seller company operates differently than a traditional high-street 17

bookstore, i.e. has a different business model. The fact though that these two companies produce value differently is irrelevant to the fact that in essence they sell the same product. These differentiations in how businesses are set up and how they perform their processes make such companies that belong in different categories good candidates for our purposes, as we can extract the knowledge involved in their business models and business process models and perform dependency analysis on it. In the book selling domain, the categories that are initially identified based on the differences of the business models they represent are: ●

Physical Store Based Business,

●

E-commerce Business,

●

Book Publisher Business,

●

Auction Based Business The advantages of this differentiation lie in the fact that it covers a lot of the variety

that business models can have. Both business that sell products in-person and online are studied, as well as businesses that are closer to the creator of the products they sell (publishers). Also, auction-based businesses will be looked into as this is a modern and successful way of making the best out of the internet and its resources. These categories will be further discussed below.

2.6.1 Physical Store Based Business This category includes companies that operate through physical stores, and thus have a physical presence where there is face-to-face interaction with the customers. Such companies are often referred to as “Brick-and-Mortar” retailers or “High Street” stores. Because physical stores are based on their physical existence, one of their advantages is the sense of security they provide to their customers, who can enter such stores, try or test the merchandise, get face-to-face realtime advice and feedback over questions and walk away with or without buying some product. Their disadvantages though are mainly based on the lack of a wide reach to customers. An example of a High street book store is WaterStone’s, though it has now expanded to the online world and has become multichannel in each 18

operations.

2.6.2 E-commerce book store Members of this category are retail companies that sell books solely online, i.e. over the internet. They don’t have a physical appearance, as physical stores do, and they often distribute challenging tasks like handling logistics etc. to external service providers. Their advantage is the wide reach of customers that can only be achieved with the use of the internet. Customers purchase products through online shopping, which involves visiting a company’s website, browsing products and placing orders, or even comparing many different online stores’ prices on the same products. As an example case for this category, Amazon.com is considered to be the most famous and successful online book seller, though it has expanded its product range to include many other types of products, like electronics, music etc. Amazon.com is ranked first in the U.S. In the list of top internet retailers (source: www.internetretailer.com/top500/).

2.6.3 Book Publisher Companies that fall under this category are involved with the publishing of books and other literature products. This means that they are closer to the creators (writers, authors etc.) of such literature, forming a direct link between the creation of the product and its commercialization. Publishing includes several phases, such as negotiation and acceptance of the material, contract agreement on the intellectual property rights with the authors, editing, book packaging, marketing and so on. Publishing companies usually play intermediary roles between the creation and the distribution of literature, such as books, as they sell their products to front-end booksellers that deal directly with the potential final customers. This though isn’t the case for all publishing companies, as sometimes publishers can directly provide customers the end products, this way skipping the previously mentioned step. An example company is Springer, which focuses on academic reference journals and science books. Springer is the largest STM (Science, Technology, Medicine) book publishing firm and second largest STM journal publisher in the world (source: www.springer.com).

19

2.6.4 Auction-Based book seller This category includes companies that centre their selling operations under the use of auctions between the candidate customers. Because of their online auction-based nature, it is difficult for such companies to put constraints on their product range. For this reason, we will only be addressing the book selling operations of companies that use the online auction business model. Auction-based companies are considered to have the role of a Broker, as they are responsible for matching buyers with sellers. Sources of revenue are, depending on the company, fees for listing products on the website, fees on the final transaction and so on. The first and most famous example of an online auction company is eBay. What eBay does is to give the possibility to individual sellers to present products with descriptions, photos, reviews etc. Buyers can then bid for a specific product and the highest bid after a fixed amount of time will result in the bidder finally buying the product. eBay does not receive fees from the buyer of a product, but only from the seller. The four business models considered here will be presented more thoroughly in Chapter 3, where their characteristics will be examined and the needed knowledge will be captured and modelled.

20

Chapter 3 Modelling the Book Selling Domain In this section we present the Book Selling domain, as viewed within the context of the four business models of interest. The reasons why we chose this domain as our research and test domain have been briefly discussed in chapters 1 and 2. The knowledge that is essential for the scope of this project will be identified and captured, thus leading to the creation of ontological knowledge, that will be used in the system’s implementation, as the backbone of common concepts that the knowledge-based system will use. Also, the methodology of the creation of the different model views (entity-relationship and process models) that describe the businesses will be discussed.

3.1

Domain Ontology Design

3.1.1 Fundamental Design Choices

The best way to start the description of the domain model is to present the fundamental design choices that were made, which can be seen as our knowledgeengineering guidelines, in the sense that they helped define the prism under which the captured knowledge was assessed and modelled. As was previously mentioned, this project focuses on business models of 4 typical types of book sellers. That, though, is not meant in the traditional sense of exclusively viewing book sellers as merely carriers of retail transactions, as is the case with physical and electronic store retailers and, partly, with the publisher model, because in that case, the auction based business model would not qualify as a book seller, since it does not claim the ownership rights of the books that are being transacted through its operations. The intention was to capture the differences in business models at a somewhat high level, so 21

that we can analyse and compare the businesses over a common ground, where the object of focus is the product being transacted, and not the transaction event between a business and the end customer, which is more low-level and information-dependent. We are concerned with how each type of business contributes in providing the final book reader (end customer) with the book product through a sale transaction. This way the differences can be seen more objectively, because if we focused on comparing different instantiations of the same business model (i.e. model a number of actual retail companies) and how they achieve the final book selling transaction, then our judgement could be biased by the commonalities that arise between the cases because they would use the same business model. Thus, the first fundamental design choice was: The value-driving object of our domain is the book product, and the focal event of our knowledge-engineering is the book product reaching the end customer The second fundamental design choice that was made was to define the three root categories of all the terms that were used, i.e. three top ontology classes under which any entity could then be classified. As can be seen in figure 5 these are:

●

Role : these are entities that have intentionality in their actions, can also be referred to as agents or actors,

●

Resource : can be anything that does not have intentionality but has endurant nature, and doesn’t gather temporal parts with the passing of time,

●

Relationship : relationships can be formed between (i) two roles, (ii) a role and a resource, or (iii) between resources. The temporal characteristics of a relationship are not of interest. What interests us is the nature of the relationship and the part it plays in the operations of roles. We focus on binary relationships because they are straight-forward to capture and assess.

Figure 5: The three upper level classes

22

This classification is similar to the principles used by the REA ontology mentioned in chapter 2, as it shares the assumptions of viewing Resources, Events and Actors as central objects. This assumption is based on the fact that these three concepts are fundamental in our domain model, in the sense that they provide all of the information that we wish to understand. Even though ‘Role’ is analogous to REA’s ‘Actor’ and ‘Resource’ is analogous to REA’s ‘Resource’, there is no direct analogy between ‘Relationship’ and ‘Event’. The differences lie in the time-viewpoint of business transactions, where in REA the temporal properties are of interest, but in our ontology only the meaning of the transaction is of interest, independently of any temporal properties the relationship may have. This is the reason why all types of relationships assumed here are treated in an equal manner from the ontological point of view. To summarize the second fundamental assumption: The three central classifications made in our ontology are Role, Relationship and Resource The third fundamental design choice that was made is concerned with the overall view of the domain that we adopt. Because the aim of the project is to study the dependencies in the domain, the ontology was created in a manner that is helpful to this view. This means that the captured knowledge should reflect the basic questions that need to be asked when performing dependency modelling and analysis. These questions are: ➢

What entities (depender and dependee) are involved in a dependency?

➢

What is the focal object (dependum) of the dependency?

➢

Within what context does the dependency lie? The answers to the first two questions are the drivers of the second fundamental

design choice described earlier. The third question needs to be further clarified. When we are asking the question ‘within what context are the dependencies considered?’ we are referring to whether the dependencies are context-specific, and thus, domain-specific, or generic, and thus context-independent, or both. We have chosen to study both domainspecific and generic dependencies, because both types of dependencies are important. By ‘context-specific dependency’ it is meant that the dependency is somewhat specialized to fit in the business domain that we are considering. By ‘generic dependency’ it is meant that such a dependency is independent of the business nature of the domain and doesn’t reflect

23

specialized types of dependencies, but instead dependencies that could be present within any context whatsoever. This will be clarified further in the section were the dependency rules will be described. To summarize this: The conceptual modelling is only ‘biased’ in the way that makes dependency derivation and modelling easier Finally, the fourth fundamental design choice that was made concerns the way our domain entities are treated. Even though the models are not based on specific instantiations of the four business models (i.e. models of existing, and thus specific companies), there is a borderline where generic terms are treated as instances rather than concepts. What is meant is that, for example, even though there is a class called ‘Business’, as will be described later on, the focal role of each business model is given a generic name (e.g. ‘Physical Store Based Business’) but, counter-intuitively, it is considered to be an instance of the class ‘Business’, rather than a subclass of it. This is done so that there is a distinction between the commonly shared ontology between the models and the knowledge required to represent each model separately. This way, generic knowledge that is used only for one model is treated data-wise rather than concept-wise. Only the commonly used knowledge is part of the conceptual ontology. Any generic concepts that are model-specific are instantiations of concepts of the common ontology.

3.1.2 Overview of the Book Selling world When creating an ontology for a particular domain of interest, an overview of the domain helps put the conceptual modelling into context easier than concentrating on specific steps from the beginning. This helps answer initial questions such as: ➢

What parts of the domain knowledge are needed?

➢

What level of specificity should be reached?

➢

How is the captured knowledge connected to existing theoretical frameworks?

When performing knowledge engineering, it is not always clear as to what should be kept and what should not. It can be claimed that capturing more than what is needed is not a serious mistake and perhaps could prove useful for future expansions, but, as was argued in

24

chapter 2, one of the basic guidelines of creating an ontology, especially when creating it for the purposes of specific applications, is that ontological commitment should be kept to a minimum. This is an important principle because it dictates the boundaries of the application, and thus, the boundaries of the application’s ontological needs. This is also noted in a similar way in [38] where the commonKADS methodology for knowledge engineering and management is presented. In this approach, one of the basic conceptual modelling guidelines that is given by the authors is that the knowledge engineer should be able to capture every necessary aspect of the domain of interest without having to become a domain expert. Another reason why this principle is important is that it helps to better manage the available time, when extracting and modelling knowledge for the purposes of an application, and not spend too much time in trying to become a domain expert.

3.1.2.1 The Publishing Value Chain

Clark in [8] gives a thorough presentation of the stages involved between creating a book and selling it to the end-customer. These can be summarized as shown in figure 6. As can be seen, there are quite a few stages involved, for each of which a brief description follows: 1. Creation of Intellectual Property: During this stage, the author produces a draft of the potential book product. This draft is considered intellectual property, held at this point by the author. 2. Editorial: During this stage, the draft manuscript will pass through an editing process, usually done by professionals, in order for it to acquire the final form that will be presented in the completed book product, which will be read by consumers. 3. Design and Production: At this stage, the edited text will undergo a design process driven by commercialization. Every aspect of the book that does not have to do with the actual text, but with its presentation, such as illustrations, front and back covers, prologues and so on will be considered and ultimately finalized during this stage. When the design phase is complete, the book product is produced in its final form, be it physical or electronic (e-book). 4. Marketing: Issues concerning the promotion and selling of the final book product are resolved during this stage, where the marketing strategy is adopted and the marketing 25

process is undertaken. 5. Sales: Selling the final book product to the end-customer takes places during this stage. This refers to retail sales, and not wholesale transactions, as these take place during the Distribution stage. 6. Storage: When producing large numbers of books, the issue of storage (warehousing) is considered before sending out the books to fulfil orders. This is especially useful in the case of fast-selling consumer books, where the risk of production is small and the sales numbers are predicted to be high. On the contrary, there can be titles that are not massively produced, and may sometimes be printed on a print-to-order basis, e.g. using the Print-OnDemand1 technique. 7. Order Processing: This is the stage where large orders are handled, usually from distributors (wholesalers and retailers). 8. Distribution: During this stage, the final book product is distributed after processing the orders. The receivers are wholesalers and retailers, who then aim to further elongate the chain by selling the product over to the next link (be it another distributor, or the endcustomer).

Figure 6: The publishing value chain. Source: [8]

1 Print on Demand (POD) is a business process where the book is not printed until it is ordered. This technique is relatively new and owes its existence to the emergence of digital printing technologies, which are faster and cheaper than traditional techniques. Nevertheless, the reduced business risks associated with POD can be countered by a lowered overall product quality.

26

3.1.2.2 The Supply Chain of Book Production

According to a view presented in [8], the supply chain for books resembles the one in figure 7. Even though this view is intuitively correct, there are a few points that have to be made before adopting a definition. A definition of the supply chain needs to be adopted, not because it will be modelled explicitly, but because it is needed as part of the foundational theory that covers the domain. The need for this theory lies in the fact that when it is formalized, it provides the opportunity for the modeller to easily extract the needed knowledge. The points we wish to make concerning Clark’s view of the book supply chain have to do with the assumptions we make in modelling the basic roles (actors) of the book selling domain. First, a verbal explanation of the supply chain seen in the figure needs to be made. As can be seen, the starting point of the chain is the Publisher. This is true in regard to the final product that is being sold, but excludes the intellectual property creator, i.e. the Author, from the view.

Figure 7: One view of the supply chain for books (Source: [8])

Whether or not the Author should be included in the supply chain depends on the viewpoint. The consideration taken here is that the Author, instead of the Publisher, is the actual starting point of the supply chain, since in a way he/she contributes to the supply chain in similar way that a supplier of raw materials would do, in the creation of a commercial product. The difference here is that the primary element that is crucial for the creation of a new book product is the intellectual property created by the author, rather than

27

the physical raw materials that are needed for the creation of the book’s physical form (e.g. paper, ink etc.). A second point that needs to be made is that there are distinct nodes for Retailer, Wholesaler and Distributor2 in the figure’s supply chain. To avoid any confusion, the Distributor seen in this figure has a different role than the Retailer and Wholesaler. The Distributor’s role in this supply chain is limited to distributing the books to Wholesalers and Retailers, without actually owning them at any point. On the other hand, a Wholesaler buys books in bulk and then sells them to Retailers, and a Retailer buys books according to their order and predicted sales needs and sells them to end-customers. For this reason, figure 8 shows a slightly changed view of the supply chain, this time including the starting and ending points (Author and End-Customer respectively), but not including Distributors. This is done to only show a chain were the arcs between the nodes are of the same generic type: they show the precedence of who actually owns the book, at the form it has at that point in time.

Figure 8: The supply chain for books

3.1.2.3 Inter-Business coalitions in the book selling world

By studying the publishing value chain and the supply chain presented in the previous sections, we can see that the basic actors and value-driving actions of the world are starting to emerge and become more easy to retrieve. The next step is to assess the inter-business coalitions that are formed between the steps of creating a book and making it reach the end-customer. The stages described in section 3.1.2.1 are a good way of trying to extract the needed information. 2 Note: the term ‘Distributor’ as used in figure 7 is not the same as the Distributor business model of the MIT approach presented in chapter 2. The latter is a superclass of Wholesalers and Retailers.

28

During the stages of editing, designing and producing the final book product (stages 2 and 3) and depending on various factors, there can be several different inter-business relationships found along the way. Of course, it is usually the Publisher’s job to edit, design and publish a book, but it is a common practice for many publishers, especially those of a smaller scale, to outsource these tasks to expert contractors. The types of contractors that are connected to stages 2 and 3 of the publishing value chain can be offering services on these tasks: ➢

Editing

➢

Proofreading

➢

Layout and design

➢

Printing

➢

Product packaging

These tasks are generally necessary for the production of the final book product. Larger publishing firms usually handle such tasks on their own, as they are more capable of financially supporting specialized departments. In fact, there exists a business model that specializes on handling all or most of these tasks, operating subcontracted by the Publisher business. This is a common technique called Book Packaging, and is performed by Book Packaging contractors. Book packaging companies handle such tasks, but can also handle the entire production of a book, from its conception as an idea to its printing and coming to a physical form. Professional writers can be involved in the operations of book packaging contractors, as they can be used in putting commercial book ideas in a written form. Because complete book packaging is not the norm in book production, we consider that some of the publishing tasks are outsourced and some are handled internally by the business itself. The task that is more financially demanding than others usually is printing, so we consider that this is subcontracted to companies that offer printing services. Stages 4 and 5, Marketing and Sales, are usually handled by the Publisher business’s marketing and sales departments, focusing on the creation of commercialization strategies that are targeted on selling the products to the end-customer. This is not only a step that is central to publishers who sell their products directly to end-customers, but affects the distribution chain as well, because the marketing of a product by its creator is what will help lean the distributors’ decision on buying the product and helps the distributors make predictions on sales risks. Thus, it is considered that stages 4 and 5 are 29

handled internally. Stages 6, 7 and 8 have to do with storage, order processing and distribution of books. Stage 7 is considered to be handled internally by the business itself, whether it is a publisher or a distributor. The storage and distribution stages have to be examined further, as they usually form interesting relationships between the book selling business and service-offering contractors. Storage is a key stage in the distribution of books. It is usually handled by professional contractors, who offer warehousing services under contract agreement. Its importance lies in the fact that the volume of produced books in the pre-sales phase doesn’t only need to be stored, but also needs to be easily accessible, appropriately catalogued and handled in an error-free manner. To summarize the various tasks that warehousing contractors can undertake, these can be: ➢

Physical storage

➢

Order preparation

➢

Public or specialized warehousing

➢

Inventory control

➢

Picking

The diversity of such tasks makes outsourcing them a frequently encountered business behaviour. We consider that the considered companies that keep stock outsource warehousing to warehousing contractors. Distribution of books can be done in several ways. According to the Booksellers Association (BA) of the UK and Ireland, which represents 95% of these locations’ operating bookseller businesses, book distribution can be done in three mainstream ways: 1. Self-distribution 2. Fulfilment only, or Third party pick, pack and dispatch 3. Full-service distribution While self-distribution, as well as pick pack and dispatch, are usually adopted by small firms that handle small amounts of stock, medium to large firms use full-service distribution. This includes order management and sometimes distribution directly to endcustomers, depending on the scale of the purchase. We consider that the models that 30

concern us are of medium scale, so basically use the second type of distribution. Vaidyanathan [42] makes a list of the major product-focusing tasks that companies usually outsource to other companies. Here, we list the most relevant ones: ➢

Transportation

➢

Warehousing

➢

Product marking, labelling and packaging

➢

Inventory management

➢

Order management

➢

Packaging As can be seen, there is a large degree of similarities between the tasks in this list

with the central tasks that the book-selling businesses perform themselves and outsource to others. The above list though only contains tasks that use or manipulate the book product. In reality, these are not the only activities a business performs in order to produce and distribute their products. Several other activities that are crucial to the business models that interest us should be considered, because of their importance to the overall existence and operations of the businesses. These kinds of activities are only differentiated from the ones described so far as to the object of their focus, as they are not centred on the book product, but on other resources of the business, such as financial assets, logistics and accounting, issues concerning the physical placing of the business, and so on. Table 3 summarizes the basic inter-business relationships considered in the book selling domain. Nature of the service

Handled by role

Storage handling

Warehousing Contractor

Supplying

Wholesaler/Publisher

Intellectual property creation

Author

Financial Services

Financial Landlord

Insurance Services

Insurance Landlord

Physical Placing of operations

Physical Landlord

Physical location design and shopfitting

Shopfitting Contractor

Website design and maintenance

IT Contractor

Book Packaging*

Book Packaging Contractor

Goods transportation

Delivery contractor

Table 3: External services and their outsourcing. *Book Packaging is performed partially. 31

All of the basic services considered for a bookseller/publisher can be seen in table (4). As can be seen in the table, the names of the roles that are responsible for each service follow the naming convention of the business models presented in chapter 2.

3.1.3 The Role Ontology Roles are the basic entities in the domain, because they have intentionality. This property gives a role the capabilities of connecting with other roles and resources in a meaningful and motivated way. Any relationship between two entities is driven by the intentional actions of a role, even when it is not explicitly stated (e.g. relationship between two objects). In creating the role ontology, two questions need to be considered: Nature of the service

Internal / External

Handled by role

Storage handling

External

Warehousing Contractor

Supplying

External

Wholesaler/Publisher acting as a Wholesaler

Intellectual property creation External

Author

Financial Services

External

Banking Company

Insurance Services

External

Insurance Company

Physical

Placing

of External

Physical Store Landlord

operations Physical location design and External

Shopfitting Contractor

shopfitting Website

design

and External

IT Contractor

maintenance Book Packaging*

External

Book Packaging Contractor

Goods transportation

External

Delivery Contractor

Accounting

Internal

Business

Logistics

Internal

Business

Order management

Internal

Business

Editing and Proofreading

Internal

Business

Sales

Internal

Business

Marketing and promotion

Internal

Business

Table 4: Internally handled services vs. outsourced services

32

–

Who are the main actors in the book selling world?

–

What are the differences between them?

By identifying the main actors and the ways they differ, we can assess the nature of their operations and form an ontological classification accordingly. A reasonable starting point was looking at inter-business relationships in the previous section, and how these affect the operations of a business throughout its life span. This helps identify the main actors that contribute to the operations of a book selling business, and especially those that are central to how the books reach the end-customers.

3.1.3.1 Classifying Businesses

Businesses in general can form many coalitions and cooperations with each other, through their life span. The kinds of inter-business relationships that can arise through the existence of an organization can be either brief and needed only at some particular point in time by the business, or lasting, which means that one or several parts of a business’s operations depend on the relationships it keeps with other parties (e.g. contract agreements). Because of our need to capture the operations of book selling businesses as viewed from a static point, it is reasonable to assume that our focus will be aimed at the inter-business relationships of time-lasting nature. The basic business roles that we are considering are the four business models the approach is centred upon: Physical Store Based Business, E-Commerce Based Business, Publisher Business and Auction Based Business. Classifying these according to the business model types presented in chapter 2 would result in the following table. Book selling Business

Business Model

Physical Store Based Business

Retailer

E-Commerce Business

Retailer

Publisher Business

Creator Intellectual Landlord Wholesaler Retailer

Auction Based Business

Physical Broker

Table 5: Classification of the four business models 33

As can be seen in the table, a Publisher Business integrates four different BM types. The creation of new products out of raw material makes it a Creator, the kind of implied agreement with the customer upon the sale of a book makes it an Intellectual Landlord3, and of course, as was already mentioned, it can act both as a Wholesaler and a Retailer, selling books to other Distributors and to end-customers directly. It is quite apparent that the complexity of the Publisher model usually surpasses that of Retailers, such as high street stores or e-stores. The remaining important roles can be extracted from table 4. Trying to classify these in accordance with the business model categories of the MIT approach, given in chapter 2, results in table 6. We have used the MIT classification schema of business types, and taking into consideration tables 5 and 6, a first ontological classification of the business roles included in the two tables is shown in figure 9. As can be seen in the figure, the four business models are not included as classes, because as described earlier, they will be considered as instances of the more general classes presented here. External Business

Business Model

Warehousing Contractor

Contractor – Physical Landlord

Wholesaler/Publisher

Distributor (Wholesaler)

Author

Creator

Banking Company

Financial Landlord

Insurance Company

Financial Landlord

Physical Store Landlord

Physical Landlord

Shopfitting Contractor

Contractor

IT Contractor

Contractor

Book Packaging Contractor

Contractor

Delivery Contractor

Contractor

Table 6: Classification of external businesses To avoid limiting the inferencing capabilities that the knowledge based system will have, we make use of the fact that all four classes (Creator, Landlord, Distributor and Broker) share a common characteristic that differentiates them from other roles. They all 3 According to the MIT Process Handbook [27], a Publisher is a subtype of Intellectual Landlord, in the sense that it provides limited use of the intellectual property rights that are sold along with the book product’s physical or electronic form.

34

are classes of Businesses. For this reason, the class ‘Business’ is introduced as a common parent of these four classes, as shown in the figure. This assumption makes logical manipulation of all businesses possible, independently of their specification (e.g. by applying rules that are applied on instances of ‘Business’ in general).

Figure 9: Classification of Business Models. The arrow in ‘Role’ indicates that it is not the root class of the ontology.

3.1.3.2 Classifying Individuals

While businesses are central roles in the book selling domain, there are other kinds of intentional actors operating in the same world. Some of them were already mentioned, like authors and end-customers. These are considered to be individuals, in the sense that they do not operate within a business or an organization, but use their actions for their own benefit. The basic ones are: ➢

End-Customer : an end-customer is the final node of the book’s supply chain, i.e. the final reader

➢

Author : the author writes the book draft, thus creating the intellectual property to be sold to the publisher later on

➢

Auctioneer : an individual who creates an auction to sell their used product

➢

Bidder : an individual who takes part in an auction by placing a bid. The outcome of the auction is not of importance for membership in this class, as it contains all individuals who have placed bids in some auction. In order to achieve a more specific and useful classification, there need to be more

generalizations and specializations introduced. For example, while the end-customer plays

35

a crucial part in a retail sell of a book product, it is not the only type of customer that exists in the domain. This calls for a generalization of the term, to a class called ‘Customer’. This class is not shown in the list above, because it can include business customers as well, or customers that are not in the end of the supply chain in general. For these reasons, the class ‘Customer’ is given as a direct subclass of the root of roles. A further generalization of this class is ‘Potential Customer’. Potential customers are roles that aren’t committed in becoming actual customers i.e. by completing a transaction. Because temporality is not important, it is considered that any instance of the class ‘Customer’ has, at some point, been a potential customer.

3.1.4 The Resource Ontology

The next step is to create the partial ontology for resources. As was mentioned before, resources are endurant things that do not have the property of intentionality, and thus are non-agentive, in the sense that is used in the DOLCE upper level ontology (found in [15]). Although intuitively resources are thought of as physical objects with substance, this is not always true, as information, data and objects in general that don’t manifest themselves in physical form are types of resources that appear very frequently in any domain. Examples include a contract agreement (not the physical paper and the signature, but the collection of information and data that forms the agreement), e-books, an order, and so on. The nature of the resource’s substance (physical, electronic or other) is not the only aspect a resource can have that differentiates it from other resources. In [35] the Cyc project is described, within it there is an upper level ontological classification, where another classification of entities is considered, namely tangible and intangible things. Tangible things, as the name suggests, are things of a rigid essence, that have physical form, whereas intangible things are not physical. In Cyc, the classification goes on further, with the class of ‘partially intangible’ things, which are intangible things that exist in time, like bank accounts, terms and conditions of a product’s use etc. The specializations go on a little more, with classes like ‘composite tangible and intangible object’, which contains all the things that have both types of components, such as a CD and the music in it etc. The purpose of this reference to Cyc’s upper-level classification schema is to show

36

that there are a lot of ways to classify resources in the upper levels, and so we have to screen and choose what is useful to us. The best way to do this is to list the resources that are most necessary in the domains that interest us and then assess which differences we wish to capture between them. A good way to extract knowledge about the domain’s resources is to look at the role partial ontology and try to assess how the different roles operate. Each role’s operations and actions overall have one or several conceptual input and output resources, and this view is helpful to assessing what the resources of the domain are. In the following table (7), the basic inputs and/or outputs that are of

interest to us for each role are shown. An

explanation of the table’s information and some assumptions should be given at this point.

Role

Inputs/Outputs of actions

Warehousing Contractor

Warehousing services

Wholesaler/Publisher

acting

as

a Books

Wholesaler Author

Book drafts (manuscripts)

Banking Company

Banking services

Insurance Company

Insurance

Physical Store Landlord

Physical Store

Shopfitting Contractor

Shopfitting and design

IT Contractor

Electronic store Website design and maintenance

Book Packaging Contractor

Book packaging

Delivery Contractor

Deliveries and transportation

Bookseller

Books

Auctioneer

Auctions Used books

Bidder

Auctions

Table 7: What each role manipulates

Several patterns begin to emerge from the table above, especially concerning potential groupings of resources. The basic ones are: ➢

Physical objects (e.g. books)

37

➢

Non-physical objects (e.g. auctions, drafts)

➢

Services (e.g. banking, packaging)

➢

Locations - Facilities (e.g. physical store, electronic store)

The items in the list above point out to an initial classification of resources. As we can see, there is a need to represent both physical and non-physical objects, tangible and intangible ones, as well as facilities within which a business operates. Furthermore, by examining each resource separately, there can arise more specializations and generalizations in the resource classification schema. For example, under the assumption that services must be treated as objects, they are best classified as intangible objects. Their abstract nature is what makes them intangible, but there is a debate on whether or not the assumption that services are treated as objects holds. In favour of the argument lies the fact that they can be manipulated in an object-like way (e.g. producing, selling and buying services etc.) but the truth of the matter is that this view dictates the need to consider temporal boundaries in the life-span of services, i.e. they can’t be seen as endurants because they exist for a specific period of time. Figure 10 is a simplified illustration of the life span of a particular service, consisting of two primary stages, preparation and application.

Figure 10: Life-span of services So when viewed in this manner, a service cannot be considered to be an object. There is though a different view of services, where the cyclical nature of their application is taken into consideration. What is meant here is that frequently, service-offering companies and especially the ones that are under long-time contract agreements, never stop preparing and applying their offered services in the duration dictated by the agreement. So in this view, a service is seen as a constant application of service instances, such as the one depicted in figure 10, and can be seen as having an endurant rather than perdurant nature, thus it can potentially be classified as an object. This is the assumption we make, as we consider a service to be an intangible object, consisting of the different but continuous instantiations of service applications and reflecting the inter-business relationships’ lasting 38

nature. Another interesting resource is the placing (location) from where a business conducts its operations and, mainly, interacts with the customers. We define a separate class for these kinds of resources, called ‘Facility’, which can be considered similar to the Business Model Ontology’s ‘Distribution Channel’ [34]. A closer look at the four types of businesses under consideration, and the way they interact with customers to sell their products results in the following table.

Business Model

Facility of customer interaction

Physical Store Based Business

Physical Store

E-Commerce Based Business

Electronic Store

Publisher Business

Electronic Store

Auction Based Business

Online Auction Site

Table 8: Facilities of interaction with customers for each business

As can be seen in the table, both physical and electronic locations can act as facilities where the business interacts with its customers. Thus there is a need to represent both types of locations. The ways of representing these eventually come down to the following three: (a) Focus on the locations’ operational features and group them together under a common superclass that is semantically defined after these features4, (b) Don’t differentiate them from the categorization of objects, using existing classes, such as tangible and non-physical tangible objects, or (c) Treat each type of location differently (e.g. treat websites as information objects and physical stores as spatial regions) according classifications of existing ontologies.

Figure 11: Specialization of facilities 4 In this case, a common superclass would be ‘Facility’, which is meant to include all operational facilities of a business, independent of their nature (i.e. physical or not). In this case it is these operational features that define the classification of facilities.

39

Cases (b) and (c) are focused on the nature of the facilities rather than their purpose, while case (a) focuses on the purpose of their existence. In other words, by choosing either one of cases (b) and (c) we choose to disregard the main characteristic of such resources, which is the ability to support customer-business interaction within them, automatically disregarding their unifying characteristic also. While choosing one of these two ways is more correct when the ontology is viewed from an upper-level ontological point of view, it is not helpful in this case, because of the specificity of the domain, which dictates a classification bias towards the business characteristics of each entity. For these reasons, the reasonable choice is to follow case (a) and create a common superclass named ‘Facility’. This can be further specialized as shown in figure 11. This way the important characteristic of these locations is captured, whether they are physical or electronic (virtual). Taking all of these points into consideration, we come up with the partial ontology for resources that is depicted in figure 12.

Figure 12: Partial ontology for resources. Notice that a 'Book Product' is a direct subclass of 'Object', because it contains both tangible (physical books) and intangible (electronic books) objects.

40

3.1.5 The Relationship Ontology

The ontology of relationships is a taxonomy of the different relationship types that exist in the book selling domain. The importance of this partial ontology is due to the following points:

➢

dependencies are considered to be specialized relationship types [46]

➢

relationships are connections between entities

➢

interactions between entities create dependencies

We are considering relationships that connect entities in the Entity-Relationship models, which can be between roles, objects, or a role and an object. This first classification is a good starting point to consider as the upper level of the partial ontology for relationships, and can be seen in figure 13.

Figure 13: Top classification of relationship types Under this schema, it is natural to assume that the actor dependencies we are considering must be placed under the ‘Role-Role Relationship’ node, though this is not the only type of dependency we are considering, as was briefly mentioned in chapter 2. Dependencies between activities though will be described later, in the process modelling section. Since the modelling is focused on the book selling domain, the basic relationships between roles should be first considered. These can shape the taxonomy, by pointing out the differences between relationship types, as well as what should be represented and what not. In table 9, the case of a physical store based retailer is considered, where the relationships that are formed with various entities within the scope of this retailers are assessed. Note that a relationship is directional when the order of the entities that appear in the relationship matters (e.g. A -> sells -> B). As can be seen in the table, there is a

41

similarity between the cases where there is a contract relationship. A contract relationship, therefore, is a subtype of a role-role relationship where the two roles that are involved are mutually related via a contract agreement (therefore, contract relationships are considered to be non-directional). Notice that in the selling and buying relationships, only one role participates along with the object that is being sold or bought, because the relationships are binary. This will be used later to form a dependency rule that captures the derived dependency between the seller and the buyer. Following this rationale for all types of businesses and entities in general in the domain, the final ontology for relationships is created. The classification of role-object relationships can be seen in figure 14. The other two upper types of relationships are depicted in figure 15. The ‘create’, ‘use’ and ‘own’ relationships are quite generic and their instantiations give them meaning, but they are useful in asserting resource dependencies between roles, as will be described later on.

Figure 14: Role-Object relationship type classification

42

Entity 1

Entity 2

Relationship description

Directionality

Physical Store Based Physical Business Landlord

Store Leasing of the directional physical location

Physical Store Based Physical Business Landlord

Store Leasing contract

non-directional

Physical Store Based Warehousing Business Contractor

Contract agreement non-directional over warehousing services

Physical Store Based Financial Landlord Business

Contract over services

Physical Store Based Physical Store Business

Operation within the directional facility

Physical Landlord

Ownership resource

Store Physical Store

agreement non-directional financial

of

the directional

Physical Store Based Shopfitting Business Contractor

Contract agreement non-directional over shopfitting and store design services

Physical Store Based Book Wholesaler Business

Contract agreement non-directional for book supplying

Physical Store Based Book Product Business

Entity 1 sells Entity 2 directional

End Customer

Entity 1 buys Entity directional 2

Book Product

Table 9: Relationships in the scope of the Physical Store Based Business

Figure 15: Role-Role and Object-Object relationship type classifications

43

3.1.6 Ontological Mappings

Some of the mappings of the basic concepts in our ontology with the four business ontologies mentioned in chapter 2 can be seen in the following table. There are many commonalities, and the main rationale between all ontologies is the same, when viewed in the top level. More detailed views show that there are differences in as to what view each ontology adopts. My ontology

e3 - value

Enterprise

REA

Role

Actor

Actor / Actor Role

Economic Agent

Resource

Value Object

Resource

Economic Resource

Relationship

Value Activity

Activity

Economic Event

Table 10: Mappings of our ontology with four business ontologies in the top level.

3.2 Entity-Relationship Models

The four entity-relationship (ER) models share commonalities in the roles they include and how they interact with each other. It is important to note that the prism under which we view each domain (derived from each business model) is the defining factor of the ER model’s boundaries. These boundaries will eventually define what roles must be included in each ER model, as well as what resources and relationships between entities. In figure 16, the blue circle can be considered as the central (focal) entity (which, in our case, can be one of the four businesses), the green circles represent the entities that are under the scope of the focal entity, and the red ones are outside the scope of the model, thus they are not included in the model. Note that the links do not represent relationships, but are to be seen as a degree of the connection between entities. As an example, in the case of the physical store retailer, the end-customer and the supplier will be included in the model, but the supplier’s supplier will not, because it is outside the scope of the model’s intention to capture the information centred around the retailer’s immediate interactions.

44

Figure 16: Model boundary The needed knowledge was captured in a similar way as the ontological knowledge was, as presented in the previous section, as the two were developed almost simultaneously, so there is no need to describe the whole process again. For the creation of the ER models, several assumptions were made. The general ones that are common between and affect more than one of the business models are: ➢

For most models, there is a financial landlord that covers financial issues of the company, by offering financial services. This is a grouping of the specialized types of financial services, under one role, called Financial Landlord, and contains services such as banking and insurance

➢

E-Commerce business and Publishers sell physical and electronic books

➢

All but the Auction based business sell new books, whilst the auction based business hosts auctions that have used books as items

3.2.1 Physical Store Based Business ER model Table 11 contains a list of the model’s entities and relationships, classified under the created ontological schema. The retailer business is central to the model and forms the majority of relationships. Another point worth noting is that contract relationships are not specialized further, according to the nature of the contract. This can automatically be asserted by the knowledge based system, based on the types of the participating roles. Assumptions made for the creation of this model include: ➢

The business leases the physical store facility, and is also under a contract 45

agreement with the facility’s owner, i.e. the Physical Store Landlord. This way both the relationships of the business with the role and the resource are captured. The same is done between roles that are connected with contract relationships, or ‘buy services’ relationships ➢

The physical store is designed by a specialized professional role (Shopfitting Contractor)

3.2.2 E-Commerce Based Business ER model There are a lot of commonalities with the physical store retailer model. The reason for this is mainly that they are both retailer business models, with the only difference being in the facility within which the business operates. Several assumptions are made in the creation of the ER model for the e-store retailer. The following points refer to these assumptions: ➢

The e-commerce business keeps stock, and therefore has warehousing needs

➢

The creation and maintenance of the website is outsourced to a specialized contractor (IT Contractor) who undertakes the maintenance part under contract terms

➢

Books can be both physical and e-books

➢

The delivery of the ordered goods is outsourced to a speciliazed contractor (Delivery Contractor)

3.2.3 Publisher Based Business ER model The Publisher business model is more complex than the previous two, as there are more types of inter-business relationships handled by a publisher. It can be argued that there is no need to represent the supplying relationships between the publisher and other businesses, i.e. the relationships where the publisher acts as a supplier, but this is not the case because these types of relationships still fall within the scope of the model. This is meant in the sense that since there is a connection (relationship) between two roles, then this calls for modelling every relationship that exists between these roles. This way, the complexity of the different role-role relationships is captured, and thus more dependencies

46

are derived. The main assumptions made for the creation of this model are: ➢

The Publisher sells directly to end-customers via an electronic store, in the same way that the E-Commerce business does

➢

Some of the tasks of creating a new book product are outsourced to a professional contractor (Book Packaging Contractor). The boundaries to which of these tasks are outsourced and which are handled internally are not defined, because this way a certain degree of freedom is introduced in the model

➢

The Author and the Publisher are connected through the Book Draft, created by the author and bought by the publisher, as well as a contract relationship between them which captures the terms of the agreement regarding intellectual rights ownership and loyalties paid to the author

3.2.4 Auction Based Business The auction based business model is the one that differs the most in comparison with the other three. The fact that it doesn’t act as a distributor (wholesaler or retailer) raises the debate on as to whether it should be included in our approach, but we have already mentioned, the approach is focused on the book product being acquired by the final reader, so under this view the auction based model is not out of place in this domain. The basic assumptions made are: ➢

Auctioneer puts a used book on auction

➢

Seller is also an auctioneer, with the difference that the seller is also related to the book by a ‘sell’ relationship

➢

Bidder participates in an auction

➢

Buyer is also a bidder, but is connected to the used book by a ‘buy’ relationship (there is no relationship between bidders and books)

This is the most simple ER model in terms of numbers of relationships, as well as complexity of relationships (few inter-business relationships means that the business model requires less to operate).

47

ER model name

object ER model Object Meta-ontology type Instance of ontology type class

Physical Store Based Entity Business

Role

Retailer

Physical Store

Entity

Resource

Physical Facility

Financial Landlord

Entity

Role

Financial Landlord

Warehousing Contractor

Entity

Role

Contractor

Store Entity

Role

Physical Landlord

Shopfitting Contractor

Entity

Role

Contractor

Book Wholesaler

Entity

Role

Wholesaler

Book Customer

Entity

Role

End Customer

contract

Relationship

Relationship

Role-role relationship

produce as a landlord Relationship

Relationship

produce services

produce contractor

Physical Landlord

as

a Relationship

Relationship

produce services

sell product retailer

as Relationship

Relationship

sell product business

as

buy product retailer

as Relationship

Relationship

buy product business

as

sell product wholesaler

as Relationship

Relationship

sell product business

as

buy product as end Relationship customer

Relationship

buy product individual

as

operate within

Relationship

Relationship

use

lease

Relationship

Relationship

buy services

buy services

Relationship

Relationship

buy services

to Relationship

Relationship

object-object relationship

apply object

services

Table 11: Entities and Relationships in the physical store retailer model

3.3 Process Models The next stage in modelling the domain is the creation of the business processes of each type of business. We choose to model in detail the subprocesses of selling the

48

products. Several bits of knowledge are taken from the MIT Process Handbook (PH) for this task, presented in [27]. The MIT PH is a collaborative attempt of creating a common repository for processes, providing conceptual tools and a knowledge classification framework to manipulate the repository’s knowledge. The MIT PH includes generic business processes, as well as specific example cases of business processes from case studies of companies. Generic processes include ‘buy’ and ‘sell’ processes and example case studies include, among other, Amazon’s ‘Distribute books via electronic store’ process, Cisco’s ‘Create network equipment to order’ process, Google’s ‘Extract web audience using search engine’ process. A screenshot of the generic ‘sell’ process taken from the MIT PH online website can be seen in figure 17. Notice that for each process there are several fields given, such as the process’s name, description, parts5 and properties. There is also the ability to retrieve related processes, which can be generalizations and specializations of a process, different ways that a process can be done, and processes which use the process as a part. Using such capabilities to navigate within the Process Handbook, we created several process models that are based on the Process Handbook’s entries. A very similar approach is made in [28] where there are three versions of the processes taken from the MIT PH: 1. MIT PH version : a process is taken from the Process Handbook as it is 2. Sequenced version : the first version of the process is sequenced 3. Enriched version : the sequenced version is further enriched with knowledge to become more accurate and complete Sequencing of the process models is needed because the processes in the MIT PH are not sequenced, i.e. there is no indication of the ordering of the parts of a process model. The knowledge is further enriched in order to suit our specific needs, because the MIT versions are quite high-level and don’t get into too much detail. The need to capture detailed steps and activities in a process model is due to the fact that more dependencies can be captured from specific knowledge rather than from abstract knowledge. For the modelling of the required processes, UML Activity Diagrams are used, as was mentioned in chapter 2. Two types of links are used in the diagrams, namely control flow links and object flow links.

5 Note that ‘parts’ are the subprocesses in which a process is decomposed to.

49

Figure 17: Generic 'sell' process taken from the MIT Process Handbook One difference between the generally accepted guidelines for UML Activity Diagram creation and our diagrams is that control flow and object flow happen simultaneously, in the sense that control flow is only implied by the control flow links which solely occur between activities. For example, in the case where activity A creates object O and then control is passed on to activity B, the diagram for this case will be the one shown in figure 18. The solid line represents a control flow link, while the dashed line represents an object flow link. This way, control and object dependencies are better captured from the system’s rules. We will present the process model and its decompositions for the physical store retailer, then briefly describe the others. The figures of the process models can be found in Appendix A.

Figure 18: Example case of simultaneous control flow and object flow

50

3.3.1 Physical Store Based Business Process Model The basic selling process adopted from the Process Handbook for physical store retailers is called ‘Sell via physical store’ and is a part of the more general process called ‘Distribute physical asset {Wholesaler/retailer}’ which can be seen in figure 19. Since there is no sequencing in the Process Handbook, figure 19 shows the main process and its parts, without control flow links.

Figure 19: Parts of 'Distribute Physical Asset {Wholesaler/Retailer}'

As can be seen in the figure, the knowledge included in the MIT Process Handbook suffers from a lack of accuracy, since in this case, retailers and wholesalers do not design or make a product, but their process is limited to buying from a supplier, selling the products and managing their business. By looking at the case examples that are included in the handbook, we come up with several examples of retailers, which can guide our processes in a more valid way. Two of such cases are Amazon and Barnes and Noble. Both of their processes consist of three parts, instead of the five shown in figure 19. In the case of Amazon, these are: ➢

Buy books to stock and to order

➢

Sell books via electronic store

➢

Manage solely internet distribution The model for Barnes and Noble is almost the same, the difference being that the

distribution is done both via physical and electronic store, and this affects the third part (management) also. Notice that the names are now context specific, as they refer to a specific type of product, distribution method etc. Under this pattern, we conclude that the process model for the physical store retailer consists of the following three parts: ➢

Buy books to stock and to order

➢

Sell books via physical store

51

➢

Manage solely physical distribution As was mentioned before, the lack of sequencing urges as into sequencing these

parts. Since buying has to occur before selling, in order for the business to acquire the products to be sold before actually selling them, the precedence of these two is [buy -> sell]. It is also considered that the management stage is done all the time during this buying-selling cycle, so it is modelled as a parallel activity. The resulting top level process model, created in KBST-EM, can be seen in figure 20. The bold border of an activity means that it is further decomposed into subparts, and as can be seen in the figure, this is the case for ‘Buy books to stock and to order’ and ‘Sell books via physical store’.

Figure 20: Process 'Distribute Book {Physical Store Based Business}' The parts that the process ‘Buy books to stock and to order’ consists of can be seen in figure 21, in their sequenced version. Notice that there are no further process decompositions in the diagram, because we did not model in detail this process. Also, the start and finish nodes of decompositions do not have the same meaning as the start and finish nodes of the top process diagram. They merely signify the starting and finishing point of the decomposition, and are in fact different types of nodes that were created for this purpose in KBST-EM, as will be described later.

52

Figure 21: Decomposition and sequencing of 'Buy books to stock and to order'

As was mentioned in the beginning of the chapter, attention is given to the selling process of each business, in this case being ‘Sell books via physical store’. The MIT version was used as the basis for the detailed model, and its consisting parts can be seen in figure 22, also in their sequenced version. It should be noted that the process ‘Attract potential customers to physical store’ is assumed to be performed in parallel to the six consequent processes that result in the actual sell, and not in the beginning of the sequence, as would be assumed intuitively. This is done because during the sales cycle (which can be said to be the six consequent processes at the bottom of the diagram shown in figure 22) there is a different set of actions and events that lead to attracting customers to the store, than to sell a product to a customer. By modelling these in parallel, we capture them as differently motivated processes. Even when assessing the needs of one customer, the business keeps trying to attract customers in the store, perhaps by advertising the store, or promoting offers etc. So the process of attracting customers is always performed in the background and this is the reason why it is modelled in parallel. Each of the six parts in the bottom of figure 22 are further decomposed, except for the first one, ‘Identify potential customers’. Some of the parts that form decompositions are performed by external roles, such as the End Customer. This is generally shown in UML using swim lanes, where each activity node is put under the name of its performer. In KBST-EM, the swim lanes have to be defined in a different manner, because of Hardy’s ability to handle only nodes and arcs between them . Thus, we have enriched the UML activity diagram type by adding specialized links between activities and nodes called ‘swim lanes’. This way, when an activity is connected to a swim lane named ‘A’, it is implied that the activity is carried out by ‘A’. The notation we used in KBST-EM can be 53

seen in Appendix C. A description of the decomposing parts is given as follows: ➢

Identify potential customers : this can be performed by either the business or the customer, according to the MIT Process Handbook, and is the step that defines the boundaries between people who are considered to be potential customers and people who are not. For example, a person who intends to visit a store is automatically self-identified as a potential customer, as is a target group of people that the business believes will be attracted to the store.

➢

Identify potential customer’s needs : this can also be performed by both the business and the customer, in the general case, but in the book selling domain it is more probable that the customer will identify his/her own needs. This can be further decomposed into the diagram shown in figure 23. It is assumed that finding and visiting the physical store is part of identifying one’s needs, because this way it puts the identified needs into the context of translating the needs to an actual store visit.

➢

Inform potential customers : (figure 24) during this subprocess, the business informs the potential customers on their identified needs. The customer then decides whether or not he/she is interested in buying the book, if not then they redefine the needs or leave the store. The part ‘Refine book need to store visit’ is where the customer puts the identified need into a realistic frame and maps it to an actual product in the store. This is done because the customer’s identified need may well be an abstract desire for a book based on a category, author etc., so a refined need is the mapping of this abstract need to an actual book. It is therefore assumed that at the end of this process, the customer has a book title that represents a book he/she intends to buy. Because the refinement of the needs to fit the store’s context can only lead to titles that the physical store based business is being supplied with by its wholesalers, any book title that is considered at the end of this process can be acquired by the business.

➢

Receive order at register : the decomposition of this process can be seen in figure 25. Note that the necessary steps that lead to the creation of the book order have to do with the book’s availability. The customer’s invoice is generated immediately if the book is available, or after processing the order, if it unavailable. The 54

decomposition of ‘Process book order’ is depicted in figure 26. ➢

Receive payments at register : at this point, the invoice is already generated and the customer handles it by paying at the register. The decomposition of this process is shown in figure 27.

➢

Deliver book to customer : the decomposition for this can be seen in figure 28.

Figure 22: Decomposition and sequencing of 'Sell books via physical store'

Figure 23: Decomposition and sequencing of 'Identify potential customer's needs'

55

Figure 24: Decomposition and sequencing of 'Inform potential customers'

Figure 25: Decomposition and sequencing of 'Receive order at register'

56

Figure 26: Decomposition and sequencing of 'Process book order'

Figure 27: Decomposition and sequencing of 'Receive payments at register'

Figure 28: Decomposition and sequencing of 'Deliver book to customer' 57

3.3.2 E-Commerce Based Business Process Model The commonalities between the electronic store retailer’s processes and the physical store retailer’s processes are many, because they are both retailers, and the only thing that is different is the location from which the business interacts with the customer in order to perform sales. In this case, the differences are: ➢

Electronic instead of physical store

➢

The potential customer has to perform a search in the e-store, by converting his/her identified needs to a search string

➢

The potential customer has to select a result from the returned search list

➢

Books can be either physical or electronic

➢

Payment is done electronically

➢

Delivery is dependent on the form of the book. If it is physical, then it is delivered to the customer by the Delivery contractor and if it is an e-book, a download link is given to the customer

3.3.3 Publisher Business Process Model The publisher process model is also similar to the previous two when comparing the retail sell operation, but there are several differences regarding the way orders are processed mainly, as well as the top level processes in general. These have to do with the fact there is no external supplying of books for the publisher, and thus no 'buy books to stock and to order' subprocess. As a publisher, the business incorporates a ‘Create books to stock and to order’ process, as well as a ‘Sell books to distributors’ process, which though are not further modelled.

3.3.4 Auction Based Business Model The business process of the auction based model is different from the other three, as 58

it doesn’t act as a retailer. The main sub-process that results to the selling and buying of a book is called 'Broker books via internet' and is taken from the MIT Process Handbook as well. The main steps within this sub-process then, are: ➢Identification ➢Informing

of the buyer's needs (usually done by the buyer)

the potential buyers. This is done through the website, which gives out

information over a product that is on auction. ➢Managing

an auction. This step involves executing the auction (auction algorithms etc.)

by the business, then informing the participants of the outcome. ➢Arranging

the sale. This step involves providing a means for buyers and sellers to arrange

the book sale, and the sale-related aspects, such as payment, delivery etc. ➢Receive

fee from sale. This is the step through which the business benefits, by receiving a

fee from the seller's payment.

59

60

Chapter 4 System Implementation 4.1 Introduction

In this chapter, we will describe the implemented knowledge-based system. The system aims at producing dependency models in graphical form, given a set of models that describe the domain, in accordance with a set of dependency rules, which will be described using first order logic form later in this chapter. Since the implementation is bound to the models' development in KBST-EM, the models are naturally presented in the system in graphical form (i.e. as a set of diagrams). The system then represents the diagram content as facts in the knowledge base, which gives it the ability to manipulate and use this knowledge as dictated by the inference engine's operation. An abstract depiction of this can be seen in figure 29 . As many of the system's knowledge components (ontologies and models) were described in chapter 3, they will only be referenced in this chapter.

4.1.1 Motivation Since modelling dependencies within a business context is not a well-studied subject in the literature, except from a few exceptions such as the i*-framework that was mentioned in chapter 2, there is not a sufficient amount of documented attempts of such an approach. This, though, is a reasonable fact, because any approach of modelling dependencies within a certain context would be dependent to its context, thus making it too context-specific to provide a definite on generalization for all business (process) models. This inability lies in the fact that the implementation is bound to the knowledge of the modelled domain and the modelling decisions, as well as its ontological commitments. In this thesis, we aim to examine whether or not a systematic approach can be applied to domains with relevant business knowledge and information, so that dependencies can be automatically derived and assessed on common business practice, and then compared within different business models. 61

Figure 29: A simplistic view of the system and its inputs and outputs

4.1.2 Modelling Environment and Language 4.1.2.1 KBST-EM overview

In chapter 2, a brief overview of KBST-EM was made, were the advantages of using this tool were mentioned. They will also be pointed out here as well, along with a list of the alternative choices of programming languages and tools that were considered. Other possible choices of implementation tools and programming language included: ➢Visual

Prolog, with the use of Java classes

➢KBST-EM

with CLIPS to export facts as PROLOG clauses and use PROLOG for

reasoning ➢Prolog

(no visual support)

The advantages of using KBST-EM with CLIPS for reasoning are: ➢Many

types of diagrams (~30) are supported by default

➢Creation

of new diagram types and modification of existing ones is very useful

and provides agility in modelling ➢The

use of CLIPS, as a programming language, makes it easy to give reasoning

capabilities in the modelling, with the use of production rules and facts (explained in more detail later) ➢Ability

to use a common ontology that is shared among different types of models

A comparison of the basic aspects that interest us can be seen in the following table. As can be seen, the first row appears to be the best way out of the considered four. The 'Programming Language Ease of Use' column is assessed based on my prior experience on 62

each language, ease of learning of a new language, and ease of using the language to our purposes. Implementation Method

Visual Diagram Modelling Support (a priori)

Direct Programming Reasoning Language Ease of Use

KBST-EM & CLIPS

Yes

Yes

Yes

Medium

KBST-EM & CLIPS & Prolog

Yes

Yes

No

Medium-Hard

VISUAL Prolog & Java

Yes

Limited

Yes

Medium-Hard

Prolog

No

No

Yes

Easy-Medium

Table 12: Comparison of implementation tools and methods

KBST-EM is built on top of Hardy, a platform that supports programmable visualization of the diagrams. The graphical models are created within cards, which, as the name suggests, can be considered as paper cards on which diagrams are drawn. The control window holds information over the set of existing cards, which are linked to each other in a tree-like manner. An attribute of a card is its card type. There are four basic card types in Hardy, Diagram cards, Hypertext cards, Text cards and Expansion cards. We will be concerned mainly with Diagram cards, but with expansion cards as well at some points. Expansion cards are expansions of diagram cards, that are not considered to be separate cards, but as continuations of cards. This is useful when modelling a diagram, an object of which requires further description. We use this feature for modelling decomposition of UML activities into sub-activities (which are also UML activity diagrams), in order to have a better and more easily navigable environment (useful for large diagrams). Furthermore, a Diagram card is defined by a diagram type, depending on the modelling method (e.g. UML Activity Diagram card, Ontology card etc.). Independently of the diagram's type, there are two main types of components, named diagram objects, a diagram can consist of: nodes, and arcs that connect nodes. Hardy provides many CLIPS functions that can be used to retrieve cards, card items (diagram nodes and arcs) etc., as well as create new cards and objects and modify existing ones.

63

4.1.2.2 CLIPS overview

The designed system was implemented using a language for expert systems, CLIPS (C Language Integrated Production System). In CLIPS, the data is stored in the form of facts, which can be considered as small pieces of information that are stored in the current (i.e. during program execution) list of facts, called fact-list. Facts are in the following form: (a1 a2 a3 ….. an) where n is an integer greater than zero, and a field ai can be of any data type (e.g. string, integer, boolean etc.). The first field can be considered as a form of fact identifier6, such as a relationship applied to the rest of the fields, or an identifying name of the model from which the fact information originates. There are three ways to represent knowledge using CLIPS: ➢Rules:

rules can be activated depending on the truthfulness of their prerequisites (which

is a list of facts) and their syntax resembles an abstract IF-THEN statement of the form: IF [LHS] => THEN [RHS]7 ➢Functions

: functions are used for modelling procedural knowledge and can be executed

by calls to them, rather than activations (which is the case for rules) ➢Object-Oriented

Programming : CLIPS provides OO features for procedural knowledge,

such as classes, abstractions etc. We will be using exclusively rules and functions. The syntax for a sample rule can be seen in figure 30, where 'fact1', 'a' and 'b' are the values of the three fields of the first fact in the LHS, and 'fact2', 'b' and 'c' are the values of the second fact's fields. Notice that the two facts in the example share a common value, that of 'b', which appears in the third field of the first fact, and also in the second field of the second fact. This means that rule 'sample-rule' will be activated only if there are two such facts, that satisfy the prerequisites. It should be noted that these are not variables, since variables are denoted with a question mark before their name, e.g. ?counter is a variable. Variables can be used for the matching of facts in the LHS of a rule, in the case that we don't care about a field's value, but we 6 Not to be confused with 'fact-identifier', which is a unique id given to facts in CLIPS 7 LHS and RHS stand for Left Hand Side and Right Hand Side respectively

64

want to make sure that two different facts share the same value at one of their fields.

Figure 30: Sample CLIPS rule syntax. If (fact1 a b) and (fact2 b c) are both already asserted in the fact-list, then the rule is activated and executes the list of commands (rhs).

4.2 System Design Details The general operation of the system is characterized by a layered manipulation of information. A visual insight to the system's internal structure can be seen in Appendix C. Although the ontology is given to the system in a graphical form, using an Ontology card, it is not considered as input to the system, because it is the underlying common structure of knowledge that is used by the system as a resource. But still, we have to model it in one or more ontology cards, so that it can be represented later by the system. The actual input is the set of diagram models, i.e. the entity-relationship and UML activity diagrams for the four business types. Then, the diagrams are handled by the diagram representation algorithm, which produces facts that represent the diagram objects. During the representation, the diagram objects (where applicable) are mapped to the ontology, which is also represented as facts in the fact-list, by the end of the algorithm's execution. These facts populate the fact-list at run-time, and the inference engine uses its defined rules to act accordingly.

4.2.1 Diagram Representation – Model Formalization

The first step that the system performs is to translate the information included in the given diagrams into a machine-understandable form, and thus formalize the given models. 65

This is done by a CLIPS function. This is the top level function for the representation of the models, and there are two main actions that are carried out for every diagram card in the running KBST-EM session: 1.Retrieve the diagram type of the diagram card, 2.Call the corresponding specialized representation function depending on the diagram card's diagram type. The level and quality of the model formalization that we want to achieve depends on the way the diagram cards are handled by their corresponding representation functions. The basic question that needed to be asked during the creation of these functions is simple:“what pieces of information from the diagrams need to be stored for later use?”.The essence of this question lies in the fact that we are able to associate any amount of information we want, when asserting a fact. To make this more clear, there is a default amount of information associated with every diagram node. This includes the unique id of the node, the id of the diagram image that the node contains, a set of string attributes that are defined in the diagram type definition such as name, description etc. Therefore, we could choose to assert in a fact any number of these data values. In the following subsections, the design choices for representing each type of diagram card will be described.

4.2.1.1 Representing Ontology Cards

In the case of Ontology cards, we need to be able to assert the following information: ➢Retrieve

the 'Class' nodes and assert them as ontology classes

➢Retrieve

the 'Instance' nodes and assert them as ontology instances

➢Retrieve

the 'Subclass Of' links (arcs) and assert the meaning of the link, i.e. make

it known to the system that the two nodes connected with a 'Subclass Of' link are associated with a 'Subclass Of' relationship ➢Retrieve

the 'Instance Of' links and assert their meaning to the system (similar to

the way 'Subclass Of' links are handled)

66

It is relatively easy to assert facts regarding the first two cases (classes and instances). When the function 'represent-ontology' is called by the top representation function, each diagram node is retrieved, along with its information (type, name etc.). Then, depending on the type of the node, the corresponding fact assertion is made. For example, if the type of the node image is 'Class', the system goes on to assert a fact that describes this node as a class of the ontology. We choose to store a fact concerning an ontology node with the first field called 'ontology'. This is done in order to group facts according to the diagram type they come from. Further more, the type of the node, as well as its name, its image id and the card that hosts it are store in the asserted fact. Asserting the information captured by arcs is more complicated than nodes. This is because, given an arc, the two nodes associated with the arc have to be retrieved also. The rationale is that for each diagram arc, its type is retrieved, along with the starting and ending nodes that are linked via the arc. According to the arc type (“Subclass Of” or “Instance Of”) the appropriate assertion is made. The produced facts for each ontology item, as well as some parts of the corresponding code, can be seen in Appendix C.

4.2.1.2 Representing Entity-Relationship Cards

The function that is used for the representation of entity-relationship models is called 'represent-er'. When handling entity-relationship cards, dealing with diagram objects differs from the methodology used in Ontology cards in several points, but the main rationale remains similar. For every diagram object, its details are retrieved and the appropriate part of the code, handled by control statements, is executed. In the case of Entities, things are rather simple. In more or less the same way that classes and instances were handled in 'represent-ontology', entities are represented in 'represent-er'. The asserted facts for entities hold the necessary information associated with them, such as the entity's name, the diagram image id, the id of the hosting card etc. It is somewhat more difficult for 'represent-er' to handle relationships between entities. This is due to the fact that a relationship node (see figure 31) in a diagram card is nothing more than a diagram object, such as entities, classes and instances are taken to be. This means that there is no default way (Hardy functions) to handle relationships exclusively, and for this reason, a function called 'handle-relationships' was created. This function is called whenever a diagram object is recognised to be of type 'Relationship'.

67

Figure 31: Relationship rel(A,B) between Entities A and B, and the "from" and "to" nodes of the two arcs. This function, given the relationship image id and the host diagram card as input parameters, retrieves all the arcs associated with the relationship and then retrieves the “from” and “to” nodes for each arc. Because it is not clear which object behaves as the “from” node and which as the “to”, we check to see that it isn't the relationship node. Also, there is a check that the retrieved “from” and “to” are Entities, because it could be the case that the relationship is linked to another relationship 8 or an attribute node (represented by an oval). Also, similarly to handle-relationships, there is a function called 'handleattributes' designed to assert the attributes of diagram objects (entities or relationships) as facts in the fact-list.9 The facts that are asserted to represent ER items can be seen in Appendix C.

4.2.1.3 Representing UML Activity Diagram cards

When the retrieved card is a UML Activity diagram card, the function 'representactivity-diagram' is called. This, in a similar way as before, gets the information associated with the diagram nodes and arcs and appropriately asserts the corresponding facts. When representing a process model, we need to be able to store the information associated with every activity, object, as well as the role that performs each activity. Split/Join junctions, start and finish nodes and decision nodes are treated as generic activity diagram items because we don't want to capture their meaning, but their presence and how this affects the diagram's flow. Also. the model's arcs give out the necessary information of control and 8 NB: This is not likely to happen since it is not correct in entity-relationship modelling to link two relationships. 9 Although attributes were not used in the ER modelling, the function was created for completeness.

68

object flow. There were a few modifications made in KBST-EM's UML activity diagram type, that have to do with handling activity decompositions and swim lanes. In the case of swim lanes, because the graphical environment of Hardy can't support the conventional use of swim lanes in activity diagrams, we chose to do this in a different manner. A new type of node to represent swim lanes is created, which is used to represent the actor that performs one or more activities. The activities that are associated with a swim lane are connected to the swim lane via a 'swim lane arc'. The reason why we chose to use decompositions and create a distinct way of handling their representation was because this way process modelling is more agile to change. Also, big processes translate to excessively long diagrams, and by grouping and decomposing activities this problem is surpassed, also making the modelling more manageable. Because previously activity decomposition in UML activity diagram cards is not handled within KBST-EM, we integrated it to both the diagram type (by adding two new kinds of nodes) and the 'represent-activity-diagram' function. As was mentioned in the beginning of the chapter, decomposition is done with the use of expansion cards. When creating an expansion card on an activity, we can model a new UML activity diagram within that expansion card (see figure 32).

Figure 32: Activity decomposition with the use of expansion cards Notice that in the figure, to signify the start and finish nodes of the decomposition, we use a specialized set of nodes, called 'Start (decomposition)' and 'Finish (decomposition)'. We created these two new nodes so that the representation function can track down the starting and ending point of a decomposition (see the notation in Appendix C). For each activity, we can perform a simple check to see if there are any expansion cards 69

connected to that activity, an appropriate fact assertion is made, and this is later handled by the inference engine. Since the top representation function retrieves all cards within the index, this will be the case for expansion cards too. These are handled by the 'representactivity-diagram' function in the same way as ordinary activity diagram cards are handled, as far as their nodes are concerned. Control and object flow between cards (expansions and activities) is handled by the inference engine at a later stage 10. An overview of the activity diagram's items and the corresponding facts that represent them can be seen in Appendix C.

4.2.2 Inference Engine

The inference engine of the system is the knowledge handling core. It performs the overall control of the program execution, and uses the knowledge base to execute rules that are activated and this way derive new facts from existing ones. This method is one of the two main reasoning methods and is referred to as forward chaining. Forward chaining is based on the activation of rules by known (already asserted) facts, which may or may not lead to the desired result. The other method is called backward chaining and it works by assuming that the desired result holds, and then backtracking to the beginning to see if there is available data (facts) in the system to justify the result. Our choice of reasoning style is natural, because in the case of dependency derivation there is no desired goal that we know of from the start. Only if we wanted to see if certain (given) dependency models hold based on what is known so far, i.e. the fact-list. A layered view of the information asserted as input and derived by the inference engine can be seen in figure 33.

Figure 33: Layered view of the levels of information 10 This is not done inside 'represent-activity-diagram' because the asserted facts need to be retrieved, and only rules (not functions) can access the facts.

70

4.2.2.1 Ontology Classification

The inference engine has to be able to produce facts that represent the ontology's hierarchy. Several rules were created to satisfy this requirement. The classification rules are activated whenever facts that represent the ontology are asserted, like the ones introduced in section 4.2.1.1. The rules are activated at the following three fact occurrences: ➢There

exists an ontology class A, which is a subclass of an ontology class B, which in

turn is a subclass of an ontology class C. In this case, it is derived that class A is also a subclass of C, due to the transitivity of the 'Subclass Of' relationship Class(A) /\ Class(B) /\ Class(C) /\ Subclass_Of(A,B) /\ Subclass_Of(B,C) => Subclass_Of(A,C) ➢There

exists an instance A of a Class B, which is a subclass of a class C. In this case, it is

derived that the instance A is also an instance of class C. This is to describe the inheritance properties of instances Class(B) /\ Class (C) /\ Subclass_Of(B,C) /\ Instance(A) /\ Instance_Of(A,B) => Instance_Of(A,C) ➢There

exists a class A. It is derived that class A is a subclass of itself Class(A) => Subclass_Of(A,A)11

The code for the first rule can be seen in figure 34. The other two rules follow this logic.

Figure 34: CLIPS code for the rule for classifying classes based on their 'Subclass Of' relationships

11 CLIPS ensures that this rule does not cause infinite loops, because each set of facts that activates it, can only activate it once, and then is removed from the activation list.

71

4.2.2.2 Activity decomposition handling

As was mentioned earlier, when it comes to the representation of decomposed activities, the representation function for activity diagrams only asserts facts concerning the decomposition of activities, storing data such as their expansion card. The control flow for these is handled by the inference engine, using a set of rules created for this purpose. Since we gave the system the ability to include decomposed activities as a way of “compacting” large process models, when it comes to representing the process control flow, there is no need of storing data about the control flow between decomposed activities, but there is a need to represent the control flow of the bottom level activities, i.e. the ones that are not further decomposed. There are three cases that are handled by these rules: 1.Two decomposed activities, A and B, are connected via a control flow link12 2.A bottom level activity passes the control to (is followed by) a decomposed activity 3.A decomposable activity passes the control to (is followed by) a bottom level activity The facts that activate these rules, as well as the facts that are derived from the rules can be seen in their schematic form, in figures 35, 36 and 37 (decomposed activities have bold boundaries).

Figure 35: Case 1

12 It is noted that the decomposed activities A and B are independently decomposed, i.e. activity A is decomposed to a set of n activities A1...An and B to a set of m activities B1...Bm

72

Figure 36: Case 2

Figure 37: Case 3

4.2.2.3 Dependency derivation rules

The inference engine has to be able to produce dependency diagrams, given a set of models. The content of these diagrams will be inferred depending on the stored data in the system, i.e. the facts contained in the fact-list. The inference engine will try to match the left hand side (LHS) of the dependency rules to the already asserted facts, and for each activation of a dependency rule, a dependency fact will be derived and stored (as prescribed by the RHS of the activated rule). The facts we want to store for each derived dependency consist of two parts. First, they have to carry all the information associated with the dependency itself, such as the depender, dependee and dependum, as well as the dependency's name and it's metaproperties (symmetricity, dependency type etc.). Second, it has to be able to contain information regarding the dependency's occurrence (i.e. the model within which it exists, the host card etc.), which will be used later on by the system to create the dependency diagrams. Handling dependencies in general, differs between the ones that exist within an ERmodel and the ones that exist within a process model. This is mainly due to the fact that they are different types of dependencies. Nevertheless, the structure of a dependency rule is more or less the same, and as any rule, consists of the LHS (prerequisites for activation) and the RHS (dependency fact assertion). In the case of ER models we are mainly concerned with dependencies that form between roles, over a certain object (dependum). These are considered to be actor dependencies, and more specifically resource dependencies (under the i*-framework classification schema). The other types of actor dependencies (task and goal dependencies) are difficult to derive based on our framework, because (i) task dependencies are very low 73

level and presuppose that we have information concerning specific tasks that are assigned by one role to another, and this is not the case in ER-models as they are very high level, and (ii) goal dependencies are considered to be of a more subjective essence and can't be derived from rigid facts without risking to end up with untrusted or false information. In the case of process models (UML activity diagrams), there can be two different dependency types derived. The first type is activity dependencies, which shouldn't be confused with task dependencies, because this type of dependency forms between two activities in an activity diagram (while task dependencies are formed between two roles), and the second type is task dependencies, which can be derived based on the information given by the swim lanes, i.e. the roles who carried out the activities etc. Dependency Types Some of the considered types of dependencies are context-specific, bound to the business aspects of the domain, but others are quite generic, with the ability of generalization and application in other domains. In order to perform different kinds of experiments, as will be presented later, we have created two sets of dependency rules, one generic and one more domain-specific. The second one is a superset of the first one, and thus it is an extension of it. Although the subject is not covered by significant amount of research in the literature, there have been several cases where dependencies were used for specialized purposes. Examples of this include Provan & Gassenheimer's approach of assessing the relationship between “inter-organizational dependence and exercised power” that can be seen in [36], and Ryser & Glinz's use of dependency charts13 on scenario-based testing in [37]. There are no approaches that attempt to perform thorough specialized classifications or identification of dependencies, with the exception of some approaches that have produced generic taxonomies, such as the i*-framework's classification of dependencies as resource, task and goal/softgoal dependencies, or the approach found in [2] where there are two generic types of dependencies identified, namely trust and flow dependencies14. We tried to examine whether more specific types of dependencies can be identified 13 A dependency chart is a graphical notation of modelling dependencies (see [37]) 14 Trust and flow dependencies are both inter-process dependencies (like the 'activity dependencies' considered here). A trust dependency exists between two business transactions when A has to be performed before B as a consequence of limited trust, whereas a flow dependency exists between when A has to be performed before B because of more practical constraints, such as when A creates a resource that B needs etc. Flow dependencies in this paper are drawn from Crowston's taxonomy presented in chapter 2 and found in [9].

74

and if they can contribute in providing useful information on the domain. An important thing that needs to be noted is that several types of dependency can be further specialized, but both generic and specialized types can exist in the same domain. For example, there might be a case where there is a dependency over dependum A1 which is an instance of class A, and there is also another dependency over dependum A2 which is an instance of a class B, which in turn is a subclass of A. In this case, if it is important to capture, within the asserted dependency, the fact that A1 is an instance of class A, then we must have a way to show the differentiation coming from the fact that the second type of dependency is a specialization of the first type. For this reason, after the dependencies are asserted, they are also classified according to a dependency ontology, which was created using a top-down approach15. The generic set of dependencies that can be derived from the ER models are given below. The whole list of dependency rules , both generic and specialized, can be seen in Appendix B. ER model dependencies Below, the generic ER model dependencies will be presented. Note that the naming style follows the logic of the created ontology. Relationships are denoted with a lower-case first letter, and classes are denoted with an upper-case first letter. The classes and relationships have been defined in chapter 3. (1) Contract dependency This type of dependency is fundamental to inter-business relationships. Its derivation is rather simple, as it presupposes that there exist two businesses connected with a contract relationship in the ER model. By capturing this dependency we are capturing a long-term business inter-dependency that has to be fulfilled by both parties equally. This makes it not symmetric. The formal rule, given in first order logic is Business(A) /\ Business (B) /\ contract(A,B) => contract_dependency(A,B) (2) Dependency between resource owner and resource user This dependency presupposes the existence of a resource (dependum), i,e. an instance of the resource ontology, which is owned by one role (dependee) and used by another 15 This means that the different types of dependencies that existed, along with the domain ontology, guided the creation of the dependency ontology.

75

(depender). A resource owner-user dependency between roles A and B over a resource C exists when A owns C and B uses C, and it means that B depends on A, as the owner of C, to use C. The relationship ontology includes classes that describe ownership and usage relationships, and this way the dependency rule is activated. In first order logic the rule is given by the following expression Role(A) /\ Role(B) /\ Resource(C) /\ own(A,C) /\ use(B,C) => resource_owner-user_dependency(A,B,C) (3) Dependency between resource creator and resource user This is considered to be a fundamental type of dependency, appearing in both process (activity) dependencies and actor dependencies. The user of a resource has to rely (depend) on the creator of the resource for its existence / availability. Role(A) /\ Role(B) /\ Resource(C) /\ create(A,C) /\ use(B,C) = >resource-creator-user-dependency(A,B,C) (4) Dependency between object owner and object user This is a specialized type of 'resource owner-user dependency' and exists when the resource C is an instance of the class 'Object'. Role(A) /\ Role(B) /\ ObjectC) /\ own(A,C) /\ use(B,C) =>object_owner-user_dependency(A,B,C)

(5) Dependency between facility owner and facility user This is also a specialized type of 'resource owner-user dependency' and exists when the resource C is an instance of the class 'Facility'. Role(A) /\ Role(B) /\ FacilityC) /\ own(A,C) /\ use(B,C) => facility_owner-user_dependency(A,B,C)

(6) Dependency between resource seller and buyer This type of dependency exists when two roles, independently of their role type, act as buyer and seller of the same resource. This is a generic type of seller-buyer dependency that doesn't specialize on the type of resource Role(A) /\ Role(B) /\ Resource(C) /\ buy(A,C) /\ sell(B,C) 76

=> resource_seller-buyer_dependency(A,B,C)

(7) Dependency between product seller and buyer This type of dependency exists when two roles, independently of their role type, act as buyer and seller of the same product. This is a specialized type of the 'resource seller-buyer dependency' Role(A) /\ Role(B) /\ Product(C) /\ buy(A,C) /\ sell(B,C) => product_seller-buyer_dependency(A,B,C) (8) Dependency between product producer and buyer This type of dependency is specific, in that the prerequisites limit its context, in comparison to other types of dependency. The role that buys a product depends on the producer of the product. Note that this doesn't necessarily hold that the producer is also the seller of the product. Also, there is a semantic connection with 'resource creator-user dependency' but can't be directly asserted within our context, because it would mean that 'selling' is a specialized type of 'using' which is not clear as to its validity Role(A) /\ Role(B) /\ Product(C) /\ buy(A,C) /\ produce_product(B,C) = >product-producer-buyer-dependency(A,B,C) (9) Dependency between service producer and buyer This dependency exists when a role offers a service to another role. Because services are modelled as resources, this dependency can hold independently of anything else that is prescribed within the business context of two related businesses (such as contracts, other types of dependencies etc.). Note that 'landlord-leaser dependency' is a specialized dependency of this type. Business(A) /\ Role(B) /\ Service(C) /\ produce_services(A,C) /\ buy_services(B,C) => service-producer-buyer-dependency(A,B,C) These cover mostly generic dependencies, without taking into account the specific natures of the dependers, dependees and dependums. The specialized dependency set, that was mentioned before, provides rules for this purpose. These rules capture dependencies that carry more specific information, and therefore can provide more accurate analysis later on. For example, specializations of 'product seller-buyer dependency' include 'product 77

wholesaler-retailer dependency' and 'product retailer-customer dependency'.These rules can be seen in Appendix B.

Process model dependencies. The dependencies that can be derived from process models are of three types, given below: ➢Control

flow dependency: This type of dependency between two activities, A and B,

indicates that A comes before B, and, therefore, has to be carried out in order for B to be carried out Activity(A) /\ Activity(B) /\ followed_by(A,B) => control_flow_dependency(A,B,”control”)16 ➢Object

flow dependency: This type of dependency between two activities A and B, where

A creates an object that B uses, captures the need for activity A to produce the object B in order for B to use it. Activity(A) /\ Activity(B) /\ Object(C) /\ create(A,C) /\ use(B,C) => object_flow_dependency(A,B,C) ➢Task

dependency: This type of dependency can be derived from swim lanes. Specifically,

when an overall process P is carried out by role A, and within that process there are activities that are carried out by a role B different than A, then A depends on B to perform these activities in order for the whole process described by the process model to be carried out successfully. Process(P) /\ Activity(X) /\ Activity(Y) /\ top_process(X,P) /\ top_process(Y,P) /\ Role(A) /\ Role(B) /\ A≠B /\ carried_out_by(X,A) /\ carried_out_by(Y,B) /\ process_of_role(P,A) => task_dependency(A,B,Y) Representation of dependencies The facts that are asserted in each case are of the following form: (dependency f1 f2 f3 f4 f5 f6 f7 f8 ) Where f1...f8 represent the fields of the fact, and their values can be seen in table 13. 16 In order to keep the already used dependency format (depender, dependee, dependum) we set the dependum as a string named “control”.

78

Field

Meaning

Allowed values

f1

Is the dependency derived or inherited from the dependency ontology?

{derived, inherited}

f2

What type of diagram does the dependency originate from?

{er-diagram, activity-diagram}

f3

Is the dependency symmetric (work both ways) or not symmetric (directional)?

{symmetric, not symmetric}

f4

Name of the dependency

string

f5

Name of the depender

depender name

f6

Name of the dependee

dependee name

f7

Name of the dependum

dependum name

f8

Id of the host card

card

Table 13: Fields and values for the dependency fact assertions

Classification of derived dependencies After the dependency rules are executed and there are no more rules activated by the asserted facts, automated dependency classification takes place. This is done in two steps. The first is the classification of the derived dependencies (which are instances) according to a given dependency ontology. This does not contribute to the production of the dependency diagrams, but provides useful information for potential future reference. For this reason, a simple rule was created that asserts facts to classify the derived dependencies, in a similar manner that the classification of the ontology is done. In this case, we mark these types of dependencies as 'inherited' in their corresponding facts, and when representing diagrams, we do not represent inherited dependencies. The second is based on the existence of dependency rules that produce specialized types of other dependency rules. So given the fact that a dependency d1 is a specialized type of another dependency d0, and thus D1 (the class of d1 ) is a subclass of D0 (the class of d0 ), both dependencies would be derived by the inference engine for the same triple (depender, dependee, dependum). This is an unwanted behaviour because the asserted dependency facts will both be marked as derived17. As an example, consider the case of a buyer A, who buys a resource C 17 This is important because the rules that create dependency diagrams are activated only by derived dependencies, and so we have to make sure that the only derived dependencies in the fact-list are the ones we really want to depict.

79

from a seller B, and that resource C is also a product. This means that both 'resource sellerbuyer dependency' and 'product seller-buyer dependency' would be asserted. In the created dependency diagram, though, we only want the specialized (lower level) dependency to be depicted, because the other one would either way be inferred

by the dependency

classification rule. This case is handled by a simple rule, which is activated whenever two derived (and not inherited) dependencies exist for the same triplet, and one of them is a generalization of the other. Then. the generalized dependency fact is retracted from the fact list. 4.2.2.4 Creation of dependency diagrams

At the point where the inference engine has asserted the facts associated with the derived dependencies, the dependency diagrams are created for each business type. This task too is handled by the inference engine, and thus it is carried out with the use of CLIPS rules. These rules are designed to handle the following dependency categories separately: ➢Entity-relationship

diagram resource dependencies

➢Activity

diagram activity dependencies

➢Activity

diagram task dependencies

According to the type of diagram and dependency, the appropriate rules are activated. The basic logic behind the way the different dependency diagrams are created remains the same, with a few differences. For each model that corresponds to a business type (e.g. the ER diagram for Publisher, or the process model for Auction based business), a single dependency model card is created for each dependency category. For example, the publisher's ER model will have a dependency model card linked to it, and the publisher's process model will have another dependency model card linked to it. Different dependency categories between the same business type are not modelled within the same dependency model card, because the dependency types are incompatible (having actor dependencies and activity dependencies in the same card would not be useful for the card viewer). A more detailed view on how this set of rules operates will be given here. Specifically, because the rules are similar, we will only describe the way resource dependencies from ER models are drawn in a diagram, as a series of steps: 1.The rule is activated whenever there is a dependency that is derived (not 80

inherited), and its dependum is of type “Resource”. 2.Find out the model in which this dependency appears (e.g. the Publisher's ER model) and check to see if there is already a Dependency Model card linked to it. 3.If a Dependency Model card already exists for the dependency's model, then retrieve it, else create a new Dependency Model card and give it an appropriate name (e.g. “Dependency Model – Publisher Business ER diagram”) 4.If the depender, the dependee and the dependum already exist as nodes in the dependency diagram, then retrieve their images, else create new ones to represent them. 5.Link the depender, dependee and dependum with the appropriate type of link (symmetric or not symmetric). 6.The dependency name is given on the arc that links the depender and the dependum. A new diagram type was created within KBST-EM, especially designed to depict dependency models. The notation of the diagram type is based on i*-framework's notation, and it can be seen in table 14. An example of how a diagram is represented, then used to derive dependencies can be seen in Appendix D.

81

Dependency Category

Dependum Type

Actor

Resource (not symmetric)

Actor

Resource (symmetric)

Actor

Task

Actor

Softgoal

Actor

Goal

Activity

Resource (object flow)

Activity

Control (control flow)

Graphical Notation

not modelled

Table 14: Dependency model notation created in KBST-EM. Notice that dependencies of control flow between activities are not modelled because they are based on the activity diagrams' control flow links, and thus are the same.

82

Chapter 5 Experiments In this chapter, we will present the results that the system produced for the four created business models, using two different sets of dependency rules; a generic one and a specialized one, which can be seen in Appendix B. The specialized set is an extension of the generic set, and thus it contains all of the generic rules as well. With the use of specialized rules, though, we can capture more specific information for each type of dependency, and therefore perform different kinds of analysis. The results will be analysed and compared with each other, to see what information we can derive from an approach like this. The analysis and comparison will be performed over a set of properties that will be defined (e.g. complexity of the dependency models etc.) Weights for each specialized dependency will be defined, and we will examine ways to score the dependency models using these weights, and if they can give out useful results. First, the results for each type of business will be derived, using the specialized dependency set, and then comparisons will be made between the four sets of models (given in chapter 3 and Appendix A), by using both the specialized and the generic dependency set. This way we can assess the quality of the analysis in each case. The reason for using the generic dependency set to compare all four models, is that it provides a common ground for comparison in a better way than the specialized dependency set does (as long as scores are not used). We will first examine the case of the Physical Store Based Business, where all of the dependencies will be discussed from both ER and process models, and then we will present the dependency diagrams of the other three business models and point out only important information, since their modelling rationale is the same among them. Through this approach, the case of two different versions of the Publisher model will be examined and compared. Finally, we will compare the results from the two ways (generic vs specialized).

83

5.1 Using the specialized dependency set 5.1.1 Physical Store Based Business 5.1.1.1 Resource dependencies between actors

In the case of the Physical Store Based Business, the resulting resource dependency diagram, that was created from the business's ER model, is shown in Appendix E. The derived dependencies, and their quantities, can be seen in figure 38. As can be seen in the R e s o u r c e d e p e n d e n c ie s fo r P h y s ica l S t o r e B a s e d f in a n cia l s e rvice s p ro d u ce r-b u ye r B u s in e s s p ro d u ct w h o le s a le r- re ta ile r p ro d u c t re t a ile r- c u s t o m e r

1

2

p ro d u c t s e lle r- b u ye r

1

1

cu sto m e r-sto re

1

la n d lo rd -le a s e r

1

re s o u rce cre a to r-u se r

2

f a c ilit y o w n e r- u s e r s u p p lie r c o n t ra c t

2 1 1

1 1

c o n t ra c t o r s e rvic e s c o n t ra c t la n d lo rd s e rvice s co n tra ct te n a n cy co n tra ct

1

c o n t ra c t o r s e rvic e s p ro d u c e rb u ye r

Figure 38: Physical Store Based Business - Dependencies derived from ER diagram figure, there is a total of 16 derived dependencies. We will analyse them in the following lines, by grouping them in categories according to their common dependency super-types. Contract dependencies Most of the derived dependencies are contract dependencies. In reality, these represent the number of contracts we acknowledge the existence of, when we created the ER diagram. Contract dependencies are considered to be fundamental inter-business dependencies, and they provide a lot of implied knowledge of the business model's operations. For example, we may know of the contract relationships between two businesses, but we may not have any explicit knowledge on the nature of the agreement, e.g. the resource being traded in accordance to the contract's terms, but by knowing the types of businesses, we can make a safe conclusion on the contract's nature, as well as the nature of the relationship between the businesses. Contract dependencies signify the boundaries of 84

the business network within which the business under study lies. The Physical Store Based Business has contract dependencies with the roles that can be seen in table 15. Dependee

Specialized type of dependency

Warehousing Contractor

'contractor services' contract dependency

Shopfitting Contractor

'contractor services' contract dependency

Physical Store Landlord

'tenancy' contract dependency

Wholesaler

'supplier' contract dependency

Financial Landlord

'landlord services' contract dependency

Table 15: Physical store based business - Specializations of contract dependencies Product seller-buyer dependencies There are four dependencies of this type, derived from the ER model. These dependencies show that the depender (buyer) depends on the dependee (seller) in order to buy the desired dependum (product), and thus are very important in a domain like this, which involves retailing and wholesaling. This type of dependency is inferred in the following table: Depender Physical Business

Dependee Store

Based Wholesaler

Customer

Physical Business

Customer

Wholesaler

Physical Business

Store

Specialized type

Based Physical Business

dependency

'product wholesaler-retailer' Store

Based 'product retailer-customer' 'product seller-buyer'

Store

Based 'product seller-buyer'

Table 16: Physical Store Based Business - Specializations of 'product seller-buyer' dependencies As can be seen in the table, the two first dependencies are intuitively expected, by the two last are not as much apparent. In the third case, we see that the system inferred a dependency between the end customer and the wholesaler, which is not a direct dependency. This is not a wrong inference, because in an indirect way, the end customer depends on the retailer's supplier (wholesaler) to distribute the books to the retailer, or else he/she wouldn't be able to buy them from the retailer. In the fourth case, we see that there is a dependency between the physical store retailer and itself. This is inferred because the retailer acts both as a buyer and as a seller of the same product, thus depending on itself in order to acquire the product (buy) and redistribute it (sell). Notice that in the last two cases, 85

the dependency is of the generic 'product seller-buyer' type, because no specialized rule was applied there. Services producer-buyer dependency This type of dependency shows the fact that one role depends on another in order to buy the services that the latter produces, in a similar way that the dependency between a product seller and a product buyer works. The object of the dependency (dependum) here is the service being produced and bought, and thus the derived knowledge captures the transfer of this service, from the service producer to the buyer. The derived dependencies of this type are shown in table 17. Resource creator-user dependency This type of dependency is inferred between the physical store retailer and the physical store landlord, over the physical store. This type of dependency may not be intuitively correct, but it captures the relationship between the two roles, when viewing the physical store as a type of resource that the physical landlord creates, in order for the retailer to use. Therefore, it captures the information of usage of the physical store, and not the service provided. Depender

Dependee

Specialized dependency type

Physical Business

Store

Based Warehousing Contractor

'contractor buyer

services'

Physical Business

Store

Based Financial Landlord

'financial services' producer-buyer

Physical Business

Store

Based Shopfitting Contractor

'contractor buyer

Physical Business

Store

Based Physical Landlord

services'

producer-

producer-

Store 'landlord-leaser'

Table 17: Physical Store Based Business - Specializations of 'services producer-buyer' dependencies

Facility owner-user dependency Again, this dependency is between the physical store retailer and the physical landlord. The difference between this dependency and the previous two, is that in this case, we capture the information concerning the dependency between the owner of the store, and

86

its user. Therefore, we can see that there are three types of dependency that occur in the same triplet . This shows that depending on the dependency production rules we define, different information can be captured between the same depender, dependee and dependum. This is a useful property for further using the information in possible expansions of the system, or connection to other reasoning systems. The triple is: •

Customer-store dependency The last dependency derived from the ER model of the physical store retailer has a more specialized meaning, rather than the so far overall generic information acquired by the other types of dependencies. The triple is: •

The information that is captured here, is that the customer depends on the retailer business to provide him/her with the accessibility of the facility within which the customer-business transactions take place. Therefore, the importance of this dependency lies in the fact that the customer actually depends on the retailer over the way they interact, in this case being the physical store location. Conclusions from ER diagram dependencies From the results shown above, we can see that a significant percentage of the derived dependencies is gathered between the two first types, namely contract dependencies and product seller-buyer dependencies (a little over 50%). This helps point out the major needs and operations of the physical store retailer. An attempt to see the impact of these dependencies to the business's existence points to removing the entities involved and reassessing the model. In this case though, we can't make assumptions on how the business operates without some of these dependencies, because there is no measure of the necessity of the business relationships involved. Even though small numbers of dependencies show a small degree of complexity, we have to assess the fact that some relationships cannot be removed from the model, because they are essential to its operations. This point projects the need of creating necessity measures for each type of dependency.

87

5.1.1.2 Dependencies between activities

When deriving dependencies from the process model of the business type under consideration, there can be two dependency categories that are derived, as was already discussed. The first category includes the dependencies that are inferred between activities within a process model. These dependencies are of two kinds, namely control flow and object flow dependencies.

We have chosen not to produce diagrams of control flow

dependencies, because these are already visible when examining the process models (where the precedence of activities is already modelled). The produced facts for control flow dependencies, though, are nevertheless asserted in the CLIPS fact-list and can be used for further processing. Object flow dependencies though are not always apparent, and thus their diagrams are created by the system. These diagrams show how one activity that uses an object depends upon another activity for the object's creation. We only modelled the 'Sell books via physical store' process in detail (i.e. including the flow of objects within that process), the dependency diagram for this process is included in Appendix E. There is a total number of 9 object flow dependencies. These are modelled as “resource dependencies”, since the shared objects are considered to be resources. The other type of dependencies that are derived from the process models are task dependencies between roles. The process model of a business can include activities that are carried out externally, i.e. by different roles. This creates a dependency between the business and these roles, which captures the information that the business depends on other roles for the completion of the business's overall process model. The derived task dependency diagram for the Physical Store Based Business can be found in Appendix E. There are 12 derived task dependencies overall. From the diagram, we can see that these dependencies are between the physical store retailer and three other roles, namely the customer, the warehousing contractor and the wholesaler. Taking one of these as an example, we can see that there is the triple , which can be translated as the following sentence: The physical store based business depends upon the customer to perform the 'pay invoice' activity. The importance of task dependencies lies in the fact that they give specific information on what kinds of dependencies can be developed in a particular process model, and thus make predictions on how the performance of an external role can affect the overall process model of a business.

88

5.1.2 E-Commerce Based Business

5.2.1.1 Resource dependencies between actors

The derived dependency diagram from the entity – relationship diagram of the electronic commerce business is shown in Appendix E. Figure 39 shows the distribution of dependencies derived from this diagram. R e s o u r c e d e p e n d e n c ie s fo r E - C o m m e r c e B a s e d B u s in e s s p ro d u ct w h o le s a le r- re ta ile r

1

1

p ro d u c t re t a ile r- c u s t o m e r

1

p ro d u ct s e lle r- b u ye r

3 2

s u p p lie r co n tra c t la n d lo rd s e rvic e s co n tra c t

1

1

c o n t ra cto r s e rvic e s co n tra ct f in a n c ia l s e rvic e s p ro d u c e rb u ye r

1 3

c o n t ra cto r s e rvic e s p ro d u c e rb u ye r

Figure 39: E-Commerce Based Business - Dependencies derived from ER diagram As can be seen in the diagram, there are in total 14 derived dependencies. It is important to note that because of our assumption that the electronic store retailer sells two types of book products (physical books and electronic books), the system originally produced distinct dependencies for each product case. Also, it produced the same dependencies for the superclass of both book products, the generic product entity called 'Book Product', thus resulting to three times the dependencies that would be derived in the case of one book product. We have chosen, though, not to include them in the diagrams and only keep the dependencies of the generic product. This way, the inter-model comparisons can be more truthful and not biased to show larger complexity for businesses that handle different types of products. It is not necessary that if a book seller handles more than one type of books (e.g. physical and electronic), then his overall business model is more complex (the total amount of books of both types that are being sold total amount of may well be the same as in the case of a retailer that sells one type of books). 89

The e-commerce based business is more dependent on external services than the physical store retailer, because of the need for delivery to the customers, but there are no attachments with physical landlords. The seller-buyer dependencies are the same as in the physical store model, four in total.

5.1.2.2 Dependencies between activities In the case of object flow dependencies, the derived dependency diagram is included in Appendix D. The derived dependency diagram for task dependencies that was produced from the sub-process 'Sell books via electronic store' can also be seen in Appendix D.

5.1.3 Publisher Business

5.1.3.1 Resource dependencies between actors In the case of the Publisher Business, the derived diagram from the entityrelationship model can be seen in Appendix E. Figure 40 shows the distribution of the derived dependencies. As we can see, the publisher model has a comparable amount of dependencies derived from the ER diagram, with the previous two models. Since the publisher business model is the most complex of all four, we would intuitively expect to see a noticeable difference in the amount of dependencies, with the two retailer models (physical and electronic). The main reason why we don't, is from the fact that there are no 'buyer-seller' dependencies in the produced diagram. This information is captured in another type of dependency, along with the information that the publisher also produces the products it sells. This type of dependency is 'product producer-buyer' and we can see two specializations of it in the diagram ('product producer-distributor' and 'product producer-customer'). It is reasonable to say that this dependency is more complicated, because both selling and producing the book products need to be present for its derivation, in contrast with the 'product buyer-seller' dependency, where only the selling relationship needs to be present in the ER model.

90

Also, notice that this model has the most contract dependencies of all the models (8 contract dependencies). This shows the complexity of the external business relationships that are needed for the publisher to operate. Of the 8 contract dependencies, 5 of those correspond to dependencies with service-offering businesses (contractors and financial landlords), which is the largest number when compared to the other models.

R e s o u r c e d e p e n d e n c ie s f o r P u b lis h e r B u s in e s s

p ro d u c t p ro d u c e r- d is t rib u t o r p ro d u ct p ro d u c e r- cu s to m e r

1

2 s u p p lie r co n tra c t

1

a u th o r c o n tra ct

4 2

la n d lo rd s e rvice s co n tra ct co n tra cto r s e rvice s co n tra ct

1

1

f in a n cia l s e rvice s p ro d u ce r- b u ye r co n tra cto r s e rvice s p ro d u ce rb u ye r

1 4

cu s to m e r-s to re

Figure 40: Publisher Based Business - Dependencies derived from ER diagram

5.1.3.2 Dependencies between activities

The object flow dependencies diagram for the publisher business model and the derived dependency diagram for task dependencies that was produced from the subprocess 'Sell books via electronic store' can be seen in Appendix D.

5.1.4 Auction Based Business 5.1.4.1 Resource dependencies between actors In the case of the auction-based business model, the derived resource dependency diagram from the entity-relationship model can be seen in Appendix D. It can be seen in the corresponding figure that the auction based business has the simplest resource dependency model of the four under consideration. This is a reasonable result, given that the auction based business model does not have many needs to operate, such as warehousing services (as it doesn't keep any stock), or buying books in order to resell them 91

(as it does not buy the products that are being transacted through it) etc. So the number of resource dependencies in this case is only 5, and these have to do with the business's fundamental needs, such as the IT support for its website, the seller-buyer dependency between the book sellers and buyers, and the dependencies created by the online auction handling. Notice that, while the bidder only depends on the business in order to use the online auction, the buyer (who is also a bidder) is associated with two dependencies: using the online auction and buying the book product (though the seller-buyer dependency in this case is between the buyer and the seller, not the business, it is derived because it is within the scope of the business's operations). 5.1.4.2 Dependencies between activities

The object flow dependencies for the auction based business model, as well as the derived dependency diagram for task dependencies that was produced from the subprocess 'Broker books via internet' can be seen in Appendix D.

5.1.5 Scoring the specialized dependency models Now that the four business models have been used to create their dependency diagrams using the specialized set, we will attempt to perform an assessment of each type of dependency, in order to assign weight measures to each one and score the four models. Note that this approach will only be concerned with the resource dependencies that we got from the ER diagrams, as these provide the most information for the models' overall operations18. Several approaches to providing evaluation frameworks for dependency models have been proposed, and a number of those use the definition of actor-dependency models that is provided by the i*-framework. An interesting approach in this subject can be seen in [12], where a set of dependencies [d1..dn] is evaluated for a certain property P, over a model M, by mapping each dependency to a certain weight in the range of [0,1], and also adjusting these weights depending on the nature of the dependency's participants. In our approach, P is the combination of how important, necessary and complex is 18 Since we did not provide specializations of object-flow and task dependencies, we can only use their quantities to make comparisons between the business models.

92

a dependency in the model M. There is no need for weight adjustment for each particular dependency in our case, because the nature of the participants is implied within each type of our specialized dependencies. A simple approach has been used, following some of the principles presented in [12], which can be summarized in the following steps: 1.Order the specialized dependencies that are present in all four models, according to their importance, complexity and replaceability, 2.Assign weights on the dependencies based on their order from step 1, 3.Normalize the weights in the range [0,1] 4.Score each business model according to the following formula: s  M , P=d 1×w d 1 , P ...d n×w d n , P  , where M: the model whose dependencies are evaluated, P: the property under measurement, [d1..dn]: the set of dependencies in M, w(di,P) : the weight of dependency di for property P

We will first order the main dependency super-types according to the degree they exhibit property P19, then for each super-type we will order its subtypes, and finally we will end up with the wanted ordering by first ordering the super-types and then encapsulating the specialized types' ordering. The main generic dependencies found here are: •contract

dependency

•product

seller-buyer dependency

•product

producer-buyer dependency

•services

producer-buyer dependency

We consider the most highly ranked (according to the three criteria mentioned above) type is 'product producer-buyer dependency', because it presupposes that the producer both produces and sells the product. The 'product seller-buyer dependency' follows next, because it does not presuppose that the seller produces the product, but the 19 As was mentioned, we are examining the combination of a dependency's necessity, importance and replaceability. These three sub-properties are not treated individually because the have closely bound meanings, and thus a common weight that describes all three of them can be defined for each dependency.

93

selling action is the main value driver of a bookseller business. Contract dependencies and services dependencies come in third and fourth respectively, because of the fact that within a contract dependency, both roles have to abide by the strict contract agreement, and the contract defines the scope of the services offered. Therefore, the ranking of these, from highest to lowest weight is: product producer-buyer > product seller-buyer > contract > services producer-buyer Next, we looked at each of the above generic types individually, and order their specializations. The final list of the specialized dependencies with their weights can be seen in table 18. Dependency

Score

product producer-distributor

1.000

product producer-customer

0.933

product wholesaler-retailer

0.866

product retailer-customer

0.799

product seller-buyer

0.732

supplier contract

0.665

author contract

0.598

tenancy contract

0.531

landlord services contract

0.464

contractor services contract

0.397

landlord-leaser

0.330

financial services producer-buyer

0.263

contractor services producer-buyer

0.196

resource creator-user

0.129

facility owner-user

0.062

customer-store Table 18: Weights for specialized dependencies

0.000

Notice that the difference between weights is the same, as we traverse from the first to the last dependency weight. By applying this weight-table to the four models, we get the overall scores that can be seen in figure 41.

94

10 9

D e p e n d e n cy Sco r e s

8 ,8 9 3

7 ,6 9 2

8 7

6 ,3

6 5 4 3 2

1 ,5 9 3

1 0 A u c t io n

E le c t r o n ic

P h y s ic a l

P u b lis h e r

Figure 41: Dependency scores for all four models These scores don't have any meaning when studied individually, but they provide a view of the relative comparison of the models. As we can see in figure 41, there is a big gap between the Auction Based Business and the other three business models, which all lie in close proximity with each other. This is explained by the fact that the Auction Based Business does not have much in common with the other three business models, as it does not act neither as a producer nor as a distributor (retailer or wholesaler). Therefore, it is safe to assume that it is the simplest of the four. Looking at the other three models as a group, we can see that the results are quite reasonable. The Publisher Business is, in reality, the most complicated, and thus, demanding model of all, at least when compared within the same scale of operations. We can also see that the physical store retailer model lies in the middle of the three, with almost equal distances between. This means that the Publisher is two times more complicated than the Physical store retailer, when they are both compared to the ECommerce model. In order to derive a measure that reflects the property P internally, we assess each model by applying the following formula: si  M , P=

d 1×w d 1 , P ...d n ×w d n , P  , where n

si(M,P) : the internal score of property P over model M, n: the total number of dependencies in M, M: the model whose dependencies are evaluated, P: the property under measurement,

95

[d1..dn]: the set of dependencies in M, w(di,P) : the weight of dependency di for property P The results can be seen in figure 42. In essence, the internal score of a model shows the average dependency weight that is present in that particular model, i.e. it is a measure of how present the property P is in the dependency model of M. We can see that the results give similar information as the ones in figure 41. 0 ,6

in t e r n a l s c o r e s

0 ,5

0 ,4 5

0 ,5 2 3 1 1 7 6 4 7 0 ,4 8 0 7 5

0 ,4 0 ,3 1 8 6 0 ,3 0 ,2 0 ,1 0 A u c t io n

E le c t r o n i c

P h y s ic a l

P u b lis h e r

Figure 42: Dependency internal scores for all four models

5.1.6 Comparing two different versions of a business Now that we have cross-compared the four business models, another type of experiment that we will perform is to produce a second version of one particular business type, and compare the two versions. We considered the case of the publisher model, where in the original ER diagram version, it was considered that a fair amount of the book production tasks were being outsourced to a book packaging contractor. Also, warehousing of the inventory was outsourced to a warehousing contractor. In the new version, we considered that these two outsourcings were no longer the case, hence the business had to rent a warehouse location from a warehouse landlord, and also there had to exist a facility were the books are produced, along with a supplier of raw materials for the production (printing, binding etc.) of books. By giving this new model as input to the system, we got the dependencies that can be seen in figure 43. As we can see, there are 24 dependencies in total, thus 7 more dependencies than the original version of the publisher model, or ~45% more dependencies.

96

R e s o u r c e d e p e n d e n c ie s f o r P u b lis h e r B u s in e s s ( lim it e d o u t s o u r c in g ) 2

4

p ro d u ct p ro d u ce r-d istrib u to r

1

p ro d u ct p ro d u ce r-cu s to m e r s u p p lie r co n t ra c t

3

a u th o r co n tra ct te n a n cy co n tra ct

3

la n d lo rd s e rvic e s co n t ra c t

1 1

1

co n t ra c to r s e rvic e s co n t ra c t la n d lo rd - le a s e r f in a n c ia l s e rvic e s p ro d u ce r- b u ye r

1

co n t ra c to r s e rvic e s p ro d u ce r- b u ye r

3

o th e r

4

Figure 43: Publisher Based Business (limited outsourcing) - Dependencies derived from ER diagram This increase in the number implies an increase of the model's complexity, due to not outsourcing tasks that make the business dependent upon more external entities. Nevertheless, the increase in dependencies is a consequence of the increase of the entities and relationships in the new ER diagram, and for this reason we should try to compare the two models in a more objective way. Using s(M,P) We will first attempt to score the new model using the definition of s(M,P) that was given earlier. This gives 11.94 for the new version of the publisher model. Compared to the original version, which had a score of approximately 8.9, we can see an increase of the scale of 30% in the model's score. Using si(M,P) Using the internal score on the new version of the publisher gives 0.4975. This is slightly lower than the internal score of the original model, which was 0.52. This shows that even though the new model has more dependencies, these exhibit the property P (complexity etc.) a little bit less than before.

Using a weighted score, sw We will be considering one last scoring way, that uses both the internal score si and 97

the number of dependencies n. The absolute number of dependencies is very important in some comparisons, because it shows how many dependencies there are, independently of their score. For example, consider the case of comparing two dependency models D1 and D2. Suppose that D1 has a total of 20 dependencies, with an si of 0.5, and D2 has a total of 10 dependencies with an si of 0.9 for some property P. The information that we get from D1's internal score, is that its dependencies have an average weight of 0.5 for P, and 0.9 in the case of D2 for the same property P. This points to assessing D1 as exhibiting the property P a lot less than D2. In reality though, the two models exhibit P in different ways, because of their relative difference in dependency numbers. When comparing the s(M,P) of D1 and D2 we get the inverse result, thus that D1 is actually exhibiting P more than D2. Therefore, these two ways of measurement have to be weighted and combined in one formula. This is defined below: s w  M , P=s i  M , P ×an×b , a+b =1, where sw: the weighted score of P over M, a: the weight of the internal score si, b: the weight of the number of dependencies n in M By applying this method to the two versions of the publisher model, for values of a in the range of [0,1] we get the two curves shown in figure 44. 30 25 20 15

N e w v e r sio n O r ig in a l v e r sio n

10 5 0 1

2

3

4

5

6

7

8

9

10

11

Figure 44: Comparison of the weighted score curves for the two versions of the publisher business model's ER diagram. Several values of a have been tried, starting from 1 and gradually going to 0. Upper curve: new version, Lower curve: original version As we can see from the figure, originally (for a=1, b=0) we can see that the curves start at the numbers of the dependencies. As a gets smaller and b bigger, the curves end at the points where the values are equal to the internal score. In between, we can see the two 98

curves for several values of a and b. In other words, as the curves gradually fall down, the impact of the number of dependencies in the models gets lower, and the impact of the average weight of the dependencies in the model gets bigger. In any reasonable case in-between the starting and ending curve points, we can see that the new version is scored higher, and therefore exhibits P more than the original version. Thus, the new version is more complicated and demanding than the original version of the publisher business model. This is what we would intuitively expect, as the purpose of outsourcing is to make businesses able to avoid handling all complex tasks by themselves, by hiring professionals. Thus, the operating costs are dramatically decreased with outsourcing.

5.2 Using the generic dependency set Comparison of dependencies from ER models By applying the generic dependency set to the four models, we will compare them and assess them based on the derived dependency diagrams. A first degree of comparison is to look at each dependency diagram category for all of the business models and compare the number of produced dependencies. This can be seen in figure 45 for the dependencies that were derived from the entity-relationship diagrams . From this view, we can see that the publisher model is the most complicated of all (20 dependencies), followed by the physical store model (16 dependencies), the e-commerce model (14 dependencies), and the auction based model (5) respectively. There are two things that should be noted here. First, we in the cases where the businesses handle two types of book products (physical and electronic books), we do not take that fact into consideration and we treat both types of book products as one generic book product. Second, as we can see, the publisher model has more dependencies than in the case where we applied the specialized set of dependencies. This is due to the fact that some specialized dependencies were modelled in a way to represent more than one types of generic dependencies. For example, the 'product producer-buyer' type in the generic dependency set does not presuppose that the producer of the product also sells the product, as this is captured by the 'product seller-buyer' dependency type.

99

25 20

20 16

d e p e n d e n cy co u n ts

14

15

10 5

5

0 P h y s ic a l

E le c t r o n ic

P u b lis h e r

A u c t io n

Figure 45: Number of dependencies derived from ER diagrams for all four models By studying individual types of dependencies we can get further insights on the points where the models differ. Since contract dependencies are very important in pointing out inter-business relationships for each model, comparing the amount of contract dependencies between the four models can give information on how the business relationship networks of the models are compared to each other. This can be seen in figure 46. As we see, the amount of contract dependencies between the physical store and the electronic store retailers is the same, 5 in each case. This shows that the two businesses are alike in as to how they develop their business relationships with other businesses, and thus how externally demanding their business models are. Intuitively, this is reasonable because the two businesses both act as retailers, and they only differ in their way of product distribution to the end customer. However, it is not the case that all electronic store retailers have the same demands as the ones that arise from the electronic store model we created. For example, it is fairly common for businesses that trade their product online not to keep stock at all, as they may directly distribute their products from their suppliers. Nevertheless, because of the fact that this business behaviour is observed in smaller scale businesses e-commerce based businesses, and given the assumption that the model we created for this type of business operates by keeping stock, the equal number of dependencies that is derived is a reasonable result. This counterexample though shows that the derived dependencies are bound to the modelling view that the modeller adopts, and thus it is not clear as to how such results can be generalized.

100

The publisher business has the most contract dependencies, and the auction based business has the fewest, namely 8 and 1 respectively. This suggests that the publisher model is the most externally20 demanding one, contrary to the auction based business which appears to be the least demanding one, in that sense.

c o n t r a c t d e p e n d e n c ie s 9 8 7 6 5 4 3 2 1 0

8

5

5

1

P h y sic a l S to r e B ase d

E-C o m m e r c e B ase d

P u b li s h e r

A u c tio n B a se d

Figure 46: Number of contract dependencies for all four models The next particular type of dependencies that we will consider for comparison is 'service producer-buyer' dependencies. These have a lot in common with they way contract dependencies are derived, because in most of the cases were two businesses are bound with a contract agreement, it is the case that this contract agreement dictates the transaction of services. This though is not always the case, as there can be contract agreements for other types of transactions e.g. contracts between the author and the publisher, or between a business and its supplier. The chart shown in figure 47 shows the number of 'service producer-buyer' dependencies for all four models. As can be seen, the results are quite different than the ones that we got from comparing contract dependencies. Here, the electronic store retailer and the publisher models have the most dependencies, namely 4 and 5 respectively, then the physical store retailer has 3 dependencies of this type, followed by the auction based business with only one. At this point, it should be noted that the physical store retailer actually has 4 dependencies of this type too, because, as is already mentioned, the 'landlord-leaser' dependency is a specialized subtype of the 'service producer-buyer' dependency. This, though, is chosen not to be shown in the diagram because when comparing dependencies, we should only compare dependencies of the same level of classification, because specializations are used to capture different (more precise) information.

20 'Externally' is meant in the sense that it relies on external companies for several of its operations.

101

6

s e r v ic e s p r o d u c e r- b u y e r d e p e n d e n c ie s 5

5 4

4 3

3 2

1

1 0 P h y s ic a l

E le c t r o n ic

P u b lis h e r

A u c t io n

Figure 47: Number of service producer-buyer dependencies for all four models Another important type of resource dependency that we must compare is the 'product seller-buyer' dependency. In essence, this type of dependency helps show how many times a product is transacted under a certain model view. The dependency counts in this case are depicted in figure 48. It must be noted that for the production of this diagram, only one generic product is considered in the cases where the book product can be of more than one type (e.g. physical and electronic book). Taking this into consideration, we can see that the electronic store and the physical store retailers have the most dependencies of this type, followed by the publisher and the auction based business (4, 4, 3, and 1 respectively). It is interesting to note that in the case that the business is supplied externally with the product before selling it, it costs one more dependency to the corresponding model, as was briefly discussed at the beginning of this chapter21. This, though, is not the case for the publisher model, because the publisher does not have to buy the products from an external supplier, and this is the reason why the publisher has one less dependency of this type than the two retailers. We can see that the auction based business is the least complicated in this view too. In the case of the auction based business, the business itself is neither the depender nor the dependee on the product seller-buyer dependency (as these are the book buyer and seller respectively), but it is included in the dependency model because it falls within the scope of the business's operations, i.e. without this transaction that causes the dependency, the auction based business would not profit. Therefore, it is important that it is included in the count.

21 This is because when business A buys product B and resells it, then this creates a buyer-seller dependency for the triple (A,A,B).

102

4 ,5 4

p r o d u c t s e lle r - b u ye r d e p e n d e n c ie s 4

4

3 ,5

3

3 2 ,5 2 1 ,5

1

1 0 ,5 0 P h y s ic a l

E le c t r o n ic

P u b lis h e r

A u c t io n

Figure 48: Number of 'product seller-buyer' dependencies for all four models Finally, there are several dependencies that are individually present in some of the models, and thus cannot be directly compared. This information, though, is implied in the total dependency count of figure 45. Figure 49 shows an overall comparison of the dependencies derived from the ER models. 18 16 14 12

o th e r

10

c u sto m e r -sto r e

8

c o n tr ac t

6

s e r v ic e s p r o d u c e r - b u y e r

4

p r o d u c t s e l le r - b u y e r

2 0 P h y sic a l

E l e c t r o n ic

P u b li s h e r

A u c tio n

Figure 49: Overview of the derived dependency counts for all four business models

Comparison of dependencies from process models Next step is to compare the task and activity dependencies that are derived from the four process models. Figure 50 summarizes the results for object flow dependencies. Since these all come from each model's selling sub-process, we can make some observations regarding the complexity of each model's customer transaction operations. As can be seen in the figure, the electronic store retailer appears to have the most dependencies in both categories, than any other model. If we mutually compare the electronic store retailer to the 103

publisher model, from this figure, we can see that even though the publisher also sells books via an electronic store, it has a smaller number of derived dependencies. This is due to the fact that the publisher never needs to be supplied with books, as it produces its own books. Comparing the electronic store retailer to the physical store retailer, we see that the latter has a smaller number of derived dependencies, in both categories. This is due to several reasons. One of them is that the physical store retailer only sells one type of book product, where the electronic store retailer sells two. A second reason is the existence of a Delivery Contractor in the case of the electronic store retailer, whereas in the physical store there is no such need, because the customer picks up the books personally. Even though several insights can be drawn from this analysis, there seem to be weaknesses in as to how the assessment of the dependencies can give rise to definite results. For example, not all task dependencies and object flow dependencies are equally weighted. There can be task dependencies whose task dependums are rather simple (and not demanding) to carry out, between a business and an external role, and thus, when compared to task dependencies for more complicated tasks, their mere count is not a sufficient evaluation metric. This shows that a different evaluation framework must be used, which also projects the need for further classification of these two dependency categories. In the case of object-flow, then are can also be objects that are less demanding to create than others, so again, the comparison is not sufficiently objective. This, though, also shows that there is a strong commitment of the derived dependencies to the modelling rationale that was followed. This point can be overcome by the fact that when comparing different business models, we can reduce the bias posed by this commitment by applying the same modelling rationale to all models. Comparison conclusions From all of the above, we can conclude that the descending order of the complexity of the four business models is: Publisher > Physical Store Based > E-Commerce Based > Auction Based

104

30 25 20 15

14 13

12

10

10 5

11

9

9

8

P u b lis h e r

A u c tio n B a s e d

0 P h y s ic a l S t o r e B a se d

E-C o m m e r c e B a se d

Figure 50: Comparison of the number of object-flow dependencies and task dependencies for all four models, from their basic selling subprocess (red: task dependencies, blue: object-flow dependencies) The degree of trust that this comparison provides, through the use of the generic dependency set, though, is compromised by many factors. Some of these are: ➢The

level at which each type of dependency affects the complexity of each model is not

the same. For example, even though the publisher business appears to have a comparable amount of dependencies with the electronic commerce and the physical store businesses, the dependencies, when assessed individually, do not have the same weights. Thus, not all dependency types are of equal importance. This point projects the need of assigning weight measures for each type of dependency, as shown in the case of the specialized dependency approach. ➢The

set of dependency rules used in this approach is generic, and even though it is

equally applied to all of the business models, it doesn't give out more specific information that would affect the criticality of each dependency. For example, a generic 'seller-buyer' dependency appears to be of equal importance when present in two different models, but more specific dependency rules would produce dependencies such as 'wholesaler-retailer dependency' or 'retailer-customer dependency' which can then be assessed differently. This point projects the need of using more specific dependency rules (at the risk of becoming too bound to the domain). ➢The

previous point would mean that direct comparison based on the dependency counts

would not have much meaning, because we would be comparing different types of dependencies. Thus, if specialized dependencies are introduced, then the need of assigning weights to each type would become apparent, and thus a framework of evaluation based

105

on a set of dependency metrics would have to be created. ➢The

models don't have any flexibility, that would make them more realistic. We are

considering four business model cases which are all created under certain assumptions, such as which services are outsourced and which are handled internally etc. If, for example, we considered the case where the physical store retailer does not outsource the warehousing services to a contractor, but rents a physical location (warehouse), then this would create another set of dependencies between the landlord of the warehouse and the physical store retailer, thus affecting the comparison with the other models. This point shows that no definite conclusions can be generalized (to all types of businesses under the same business model) from such an approach. This, though, does not mean that interesting insights cannot be drawn. The power of a dependency modelling approach lies within specific applications, where the modelled businesses are not intended to be generalized.

5.3 Generic vs. Specialized Dependencies To conclude these experiments, we consider that using specialized dependencies gives insights with better quality than the use of generic dependencies. Also, the use of specialized dependencies enables us to assess the derived dependency models in many different ways, such as the score, internal score and weighted score approaches that we performed. This though implies an increase in time and effort, since weights and scoring methods need to be devised. Nevertheless, the results that we got from both comparisons point to the same conclusions regarding the assessment of the models' complexity. This, though, is due to the fact that our domain is not modelled in a large scale, and therefore the number of dependencies that can be derived is not very big. It is reasonable to assume that in domains where many dependency types can be derived, the level of detail would be too great to be derived and assessed, if only generic dependency sets are used to capture the domain operations and dependencies. Thus, scoring methods, if defined correctly, would probably be a lot more accurate.

106

Chapter 6 Evaluation In this chapter we will evaluate the work presented in the previous chapters. We will use a theoretical evaluation framework that consists of two parts: ➢Evaluation

of the conceptual modelling

➢Evaluation

of the developed knowledge-based system

6.1 Evaluation of the conceptual modelling

In chapter 3 we described the conceptual modelling methodology that we used to model the book selling domain. This consisted of two parts, the first being the creation of the common ontology, and the second being the creation of specific types of models, i.e. the entity-relationship models and the process models. We will attempt to evaluate these two parts in the following sections.

6.1.1 Ontology Evaluation According to [3], evaluating an ontology of a domain can be done in several methods, though ultimately it comes down to the use expert knowledge. This is because ontologies, by definition, are conceptual views of domains, and thus cannot be restricted to just one correct way of development, i.e. the subjective factor is almost unavoidable. These methods include consulting experts and using “golden ontological standards” of the specified domain. In our case, there is no unique golden standard, and every approach for development of standards falls within a certain scope of application. Nevertheless, we have mentioned that several existing ontologies and modelling methods have been used to develop the ontology presented in chapter 3, and thus we will evaluate it using these existing approaches.

107

The basis of the ontology is formed by the three core concepts, Role, Resource and Relationship. These three concepts are accepted by the four ontologies that were used as reference, and this points to the validity of our ontology's backbone, which is perhaps the most important part. Differentiations on how these concepts are seen in each ontology come from the fact that each one of them adopts a different way of viewing the domain. The more we go in detail when defining concepts, the less the validity of the concepts can be acknowledged by the other ontologies. This, though, is a fact that not only holds for our ontology, but also when comparing the other business ontologies with each other. Nevertheless, we have used top-level ontological approaches as reference, in order for the classification to be consistent with general ontological standards. This points to the validity of the classification schema that we have used when defining more specific concepts. Given that our ontology is entirely bound to the system's development, its consistency and correctness can be assessed along with the overall system performance, which will be discussed later on.

6.1.2 Entity-relationship and process models evaluation The developed ER and process models have to be evaluated according to the following criteria: ➢soundness:

do the developed models correspond to ER modelling and UML

specifications? ➢realism:

do the developed models reflect the reality of the domain?

➢completeness

and coverage: are the models complete, under the application context,

and do they cover all possible scenarios?

6.1.2.1 Soundness

Soundness evaluation shows whether the appropriate specifications of the modelling methods have been followed. In the case of the entity-relationship modelling, the created diagrams conform with a subset of the specifications provided in [6]. Specifications such as cardinality in the 108

relationships and the use of attributes have not been used, because we have adopted ER modelling to suit our own purposes, i.e. as a visualization tool of the basic entities and relationships in the book selling domain. This means that our ER diagrams are sound, according to a subset of the full ER modelling specifications. Given that ER modelling is primarily used for modelling databases, it is reasonable to assume that we would not need to strictly conform to the full set of specifications. In the case of the process models, were UML activity diagrams have been used, we have to consider several points before assessing their soundness. Strictly speaking, the created activity diagrams are not sound, because of the fact that we have used a different method of visualizing object flow. This though can be considered as an extension of the original use of UML activity diagrams, and can be justified by the fact that UML, as a visualization framework, provides the agility and freedom to be used according to the modeller's needs. The second thing that falls out of the scope of UML activity diagram specifications is the way we use swim lanes in KBST-EM i.e. creating diagram objects to represent swim lanes and connecting them to activities to represent whenever an activity falls within a certain swim lane. This though is a necessary change due to the way Hardy defines and handles diagrams. From the above, we can conclude that the developed process models are conditionally sound, given that they are used to suit our modelling tools and purposes.

6.1.2.2 Realism

The development of the ER models is a derivative of the conceptual modelling methodology that we used. We have surveyed the literature in order to capture the important concepts and notions in the bookselling domain, and translated them to our purposes through the use of entity-relationship modelling. The basic high-level business relationships have been captured and modelled, by drawing insights from the literature and from real-world observation. Therefore, we can say that the developed ER models are realistic, under the scope of our approach. The process models have been developed using two resources, namely the MIT Process Handbook, which is an existing and recognised framework, and actual real-world observation of the selling processes of each business model. This means that we used our own experience of physical store, e-commerce and auction-based selling processes, drawn from real companies, such as WaterStone's and Blackwell (physical store retailers), 109

Amazon.com and BarnesAndNoble.com (e-commerce retailers), Springer (publisher and direct online retailer) and eBay (auction-based, but not product specific), and integrated this knowledge with the MIT Process Handbook framework's predefined processes and case-specific examples. The selling process was modelled to detail, providing low-level objects (such as abstract book needs and search string). This was done so that the processes are complete and the loss of information is kept to a minimum. Under this scope, we can say that the created process models conform to realistic knowledge.

6.1.2.3 Completeness and coverage

Evaluation of completeness and coverage of the created models is unavoidably dependent on the application's context. Therefore, we cannot say that the models cover all possible scenarios of business processes. For example, in the case of the process models, we have only modelled in detail particular sub-processes for each business model. Also, we have chosen to model four different business models, while we could have chosen more (e.g. book wholesalers, combined e-commerce and physical retailing etc.). Nevertheless, under the scope that we defined for this approach, we have covered the information that was needed.

6.2 Knowledge-based system evaluation

There exist no standard criteria for evaluating a knowledge-based system [25], but the evaluation of a knowledge-based system (KBS) is generally considered to consist of two parts, verification and validation: 1.Verification: (i) assessment of the knowledge-base's consistency and (ii) assessment of the inference process's correctness 2.Validation: assessment of the quality of the produced results

6.2.1 KBS Verification Verification of the KBS consists of the two parts mentioned above. They will be examined here individually.

110

6.2.1.1 Consistency of the knowledge-base

The created knowledge base contains the dependency-related knowledge, i.e. the dependency production rules that the system uses. Verification of the knowledge base, thus, means that we have to examine whether the set of dependency rules is consistent and complete. This, though, would mean that there is a definition of a complete dependency knowledge-base, especially designed for the purposes of our application, but this is not true, because there is no unique limited spectrum of dependencies that can be used in any domain22. This is supported by the fact that we used two different dependency rule sets, thus two different knowledge bases, and in both cases the system produced results that adhere to the initial requirements of the system, i.e. the production of dependency models and dependency-related information given a set of models that describe the domain. The created knowledge base can only be considered as an instantiation out of many possible alternatives, that ultimately fall within factors such as the experience, literature surveying and even the intuition of the knowledge engineer. Taking these points into consideration, we can say that the developed knowledge based system is consistent within its own boundaries, without excluding the fact that it is not the only way of modelling the contained knowledge. 6.2.1.2 Correctness of the inference process

What is perhaps most important in the KBS's evaluation is for the inference engine to behave correctly. If it fails to do so, then both the consistency of the knowledge base and the effectiveness of the system are compromised. In order to assess the correctness of the inference process, the specificity of the application calls for using ad-hoc techniques. These mainly have to do with testing each inference rule individually, and assessing its behaviour. We did this by considering the possible existence of conflicting rules, redundant rules, unnecessary activation conditions and subsumed rules, as is done in [32]. The important thing to note here is that the design of the inference engine is done in a way that there are no wrong activations of rules. This means that the facts are modelled to be asserted in a way that they can help guide the activation of the rules that are required each time. Also, care has been taken in producing fact assertions that carry the necessary information for the execution of the rules' commands.

22 Since we are not dealing with a problem of algorithmic nature (standard output for standard input), or a problem with discrete boundaries, we cannot assume that there is a discrete amount of existing dependencies that we have to model, in order for the knowledge base to be complete.

111

Overall, the correctness of the inference process was performed in a bottom-up approach, as is done in [25]. We started off by testing each rule individually, by feeding devised facts that activate that particular rule, and checking the correct activation and execution of the rules. Then, the rules where checked together as groups for each module of the inference engine (classification, representation, inference etc.) and finally the performance of the inference engine was assessed as a whole, i.e. containing all the rules. It was not difficult to verify that the system behaves correctly, because we didn't have to deal with large sets of domain models, and thus could verify the correctness of the inferences for each model by performing the operations manually. The final version of the system did not exhibit any wrong activations or unpredicted/unwanted behaviour. Therefore, we can say that the inference process is correct.

6.2.1 KBS Validation

In order to evaluate the performance of the approach as a whole, the most reasonable way to do so is to examine the produced results and the overall performance of the implemented system. As was discussed in chapter 5, the experiments point to realistic results, which can be cross-checked by comparison studies of business models, and booksellers specifically, drawn by the literature. In [5] the authors attempt a comparison of e-commerce vs. conventional retailing techniques, by using an approach centred around the pricing of the products. They conclude that the online retailer model carries a smaller degree of friction, and thus complexity, than physical store retailer models, a finding that conforms with the results we got from using both specialized and generic dependency rules. Other studies that support this belief include [43], where the finding of the internet retailer model to be less complex is conditional upon the population sample that was used in their survey, and [21], where the internet retailer model is found to provide low transaction complexity which helps organizations benefit further. It is generally accepted that the operating costs of running a physical store business outweigh those of the e-commerce business, when viewed at the same level of operations. This dependency-based study though doesn't account for factors such product variation, operating costs vs. revenue, and the fact that e-commerce businesses have distribution channels that operate 24 hours a day, contrary to physical store businesses that are restricted by working hours. These factors, though, lie outside of the 112

scope of this analysis and do not affect the knowledge-based systems effectiveness. The auction based model is the least complicated of all, because it does not act as part of a supply chain, like the other models do. Nevertheless, the fact that the auction based model creates value by receiving transaction fees makes its revenues quantitatively less than the revenues of the other models, when comparing the same number of selling transactions. Again, though, this lies outside the scope of our dependency-based analysis, which ultimately helps classify the business models according to their operating costs. Finally, the publisher model is reasonable to be found as the most complex model of the four, as its role, by definition, subsumes the role of the e-commerce model. Thus, the results that were discussed in chapter 5 reflect at a fair degree the reality of the domain, and we can say that the system's effectiveness is therefore sufficient, at least under the defined scope.

113

114

Chapter 7 Conclusions and Future Work 7.1 Conclusions Several conclusions have been drawn from this project. We have seen how dependencies can be captured and modelled within a specific domain, by defining and using dependency production rules. We have created a framework for this reason, and applied it to the book selling enterprise domain. We have also seen how the derived models can be assessed and compared. Positive points drawn from this approach are: ➢Dependency

modelling provides an insight of the domain under consideration that

is only implied by the initial domain model. This is a consequence of the fact that dependencies are derived from the combination of known facts, and thus they capture the information that helps formalize these implications. ➢Within

a business context, by capturing dependencies we can study how

businesses are inter-related and make useful conclusions on the way they operate and interact with each other, and how they impact each other, when unexpected changes happen. ➢With

the use of dependency evaluation frameworks, such as the simple weight-

based scoring approaches that were discussed in chapter 5, we can assess dependency-related properties, such as importance and complexity of the dependencies. This can be specialized to fit any specific needs, thus to study any property that a dependency model may have. ➢Dependencies,

by nature, provide a view of the needs that a certain entity or

model has to attend to, and is constrained by, for its existence within the specified context. Under this scope, dependency modelling can help provide insights to assessing and improving these needs. ➢Dependency

models can provide a solid foundation for comparisons. They are

115

also agile to different interpretations, depending on the studied properties, thus allowing for different types of comparisons ➢Dependencies

can be derived from more than one modelling view of a domain. In

our approach, we have used both entity-relationship and process models, under an ontological approach, to derive dependencies. This can be further applied to other types of models, such as workflow charts, sequence charts, organisation models, communication models, interaction models, other types of knowledge models etc. Drawbacks of this approach include: ➢The

framework, when applied, is bound to be application-dependent. This means

that the models that are given to a dependency modelling KBS as inputs have to conform to the specifications of the system. Only the pre-specified types of models can be assessed by the system (as in our case the system only handles ER and UML activity diagrams). If new types of models need to be used, then new dependency rules will have to be created and applied. ➢A

large percentage of the work that was performed was in the conceptual models

This is both time-consuming and unavoidable in order to ensure correctness in both the input models and the common ontology. This point highlights the need for using standards and appropriate automated support of verification, validation and guidance, in order to avoid errors and misconceptions, as well as to save time, It is not implied though that standards will exist for any considered domain ➢Since

the truthfulness of the knowledge base (i.e. the dependency rules) relies on

the realism of the created models and the common ontology, potential errors in these will compromise the quality of the results. This point shows that there is a high degree of coupling between the knowledge base and the domain modelling ➢The

types of dependencies are usually not pre-defined for a specific domain, and

thus have to be extracted from existing knowledge, or, in the worst case, they have to be assumed. In the case that assumptions are made over the definition of dependency types, the quality of the results is further compromised by potential errors and misconceptions

116

7.2. Future work Future work for this project involves two main aspects, improvement of the developed knowledge-based system and further research on dependencies. Improvement of the KBS is focused in the following points: ➢Extend

the system's diagram-handling capabilities, in order to be able to handle

more types of diagrams ➢Develop

a tool that enables the user to define dependency types, and

automatically produce the CLIPS rules ➢Integrate

in the KBS dependency scoring with the use of a dependency evaluation

framework, such as the one discussed in chapter 5 ➢Extend

the system to be able to derive more types of dependencies, such as goal

and softgoal dependencies Further research on dependencies includes: ➢Development

of context-specific dependency-related standards that are more

detailed than existing approaches (such as the i*-framework) ➢Development

of consistent dependency evaluation metrics for business-related

dependencies ➢Research

on how business dependencies are affected by business-related factors,

such as operating costs, business revenues etc.

117

118

Bibliography ´ [1] Andersson B, Bergholtz M, Edirisuriya A, Ilayperuma T, Johannesson P, Gordijn J, Gregoire B, Schmitt M, Dubois E, Abels S, Hahn A, Wangler B, Weigand H (2006) Towards a reference ontology for business models. In: Proceeding of the 25th international conference on conceptual modeling, Tucson [2] Maria Bergholtz, Prasad Jayaweera, Paul Johannesson, and Petia Wohed (2002). Process Models and Business Models - A Unified Framework. In Stefano Spaccapietra, Salvatore T. March, and Yahiko Kambayashi, editors, ER (Workshops), volume 2503 of Lecture Notes in Computer Science, pages 364–377. Springer, 2002. [3] J. Brank, M. Grobelnik, and D. Mladenic (2005). A survey of ontology evaluation techniques. In Proceedings of the Conference on Data Mining and Data Warehouses (SiKDD 2005), Ljubljana, Slovenia, 2005. [4] D. Brickley, J. Hunter, and C. Lagoze, (1999). “ABC: A Logical Model for Metadata Interoperability,” Harmony Project, Working Paper http://www.ilrt.bris.ac.uk/discovery/harmony/docs/abc/abc_draft.html, 1999. [5] Brynjolfsson, Erik and Michael D. Smith. (2000). "Frictionless Commerce? A Comparison of Internet and Conventional Retailers." Management Science. April, 46:4, pp. 563-85. [6] Peter Pin-Shan Chen, (1976). The entity-relationship model—toward a unified view of data, ACM Transactions on Database Systems (TODS), v.1 n.1, p.9-36, March 1976 [7] Chen-Burger, Y-H, Robertson, Dave (2005). Automating Business Modelling: A Declarative Approach for FBPML, European Conference on Artificial Intelligence. Seattle, Washington, USA. [8] Clark, G. N. (1994). Inside book publishing. London: Book House Training Centre. [9] Crowston, K. (1994): A Taxonomy of Organisational Dependencies and Coordination Mechanisms. MIT Center for Coordination Science Working Paper. Massachusetts Institute of Technology, August 1994 (available from http://ccs.mit.edu/ccsmainhtml). [10]Davenport, T. H. (1993). "Process Innovation: Re-engineering Work through Information Technology". Harvard Business School Press, Boston. [11]H.E. Eriksson and M. Penker (1999). Business Modeling with UML: Business Patterns at Work, Wiley, New York. 119

[12]Franch, X., Grau, G., Quer, C. (2004). "A Framework for the Definition of Metrics for Actor-Dependency Models". In Proceedings of the 12th IEEE International Conference on Requirements Engineering, pp. 348-349. [13]Fraser. J, Tate, A and Uschold, M, (1995). “The enterprise toolsetÐan open enterprise architecture” In The Impact of Ontologies on Reuse, Interoperability and Distributed Processing 42±50. Unicom Seminars, London. [14]A. Fuxman, P. Giorgini, M. Kolp, and J. Mylopoulos, (2001). “Information systems as social structures”. in Second International Conference on Formal Ontologies for Information Systems (FOIS-2001), Ogun-quit, USA, October 17–19 2001. [15]Gangemi, A., Guarino, N., Masolo, C., Oltramari, A., Schneider, L., (2002): “Sweetening Ontologies with DOLCE”. In: Proceedings of the 13th European Conference on Knowledge Engineering and Knowledge Management (EKAW2002), Siguenza, Spain. [16]Geerts, G. and W.E. McCarthy, (2000). “An Ontological Analysis of the Primitives of the Extended-REA Enterprise Information Architecture,” Forthcoming in The International Journal of Accounting Information Systems [17]Giaglis, G.M. (1999), “A taxonomy of business process modeling and information systems modeling techniques”, work in progress, Brunel University, Uxbridge, . [18]J. Giarratano and G. Riley, (1994). Expert Systems: Principles and Programming, PWS Publishing Company, Boston, MA . [19]Jaap Gordijn, Hans Akkermans and Hans Van Vliet, (2000). “Value based requirements creation for electronic commerce applications”. In Proceedings of the 33rd Hawaii International Conference On System Sciences. [20]T. Gruber, (1995). “Towards principles for the design of ontologies used for knowledge sharing”. International Journal of Human-Computer Studies, 43(5/6): 907-928, 1995. [21]M.Y. Kiang, T.S. Raghu and K.H.M. Shang, (2000).” Marketing on the internet— who can benefit from an online marketing approach?”. Decision Support Systems 27 4 (2000), pp. 383–393. [22]M. Klein, (2001). “Combining and relating ontologies: an analysis of problems and solutions”. In IJCAI-2001 Workshop on Ontologies and Information Sharing, pages 53--62, Seattle, WA, 2001. [23]Lin, FR., Yang, MC. and Pai, YH, (2002). “A generic structure for business process modeling”. Business Process Management , Journal, Vol. 8. No.1, Emerald, 2002. [24]Linder, J. and S. Cantrell (2000). "Changing Business Models: Surveying the Landscape" accenture Institute for Strategic Change.

120

[25]Logi and Ritchie, (2001). “Development and evaluation of a knowledge-based system for traffic congestion management and control”. Transportation Research C 9, 433–459. [26]Magretta, J. (2002). "Why Business Models Matter." Harvard Business Review 80(5): 86-92. [27]Malone, T. W., K. Crowston, et al. (2003). “Organizing Business Knowledge: The MIT Process Handbook”, The MIT Press. [28]Manataki, A. & Chen-Burger, Y-H., (2009). “Analysing Supply Chain Strategies Using Knowledge-Based Techniques”, In: Lecture notes in Computer Science, vol. 5559/2009, pp. 697-704. [29]McCarthy, WE, (1982). “The REA accounting model: a generalized framework for accounting systems in a shared data environment”. Accounting Rev 57, pp. 554–578 July. [30]R Mayer, M Painter and P deWitte, (1994). “IDEF family of method for concurrent engineering and business reengineering applications”, Knowledge Based Sytems Inc., USA (1994). [31]Murata, T., (1989). “Petri Nets: Properties, analysis and applications”. Proc. of the IEEE, 77(4):541--580, 1989. [32]Nguyen, T., Perkins, W., Laffery, T. and Pecora, D. (1987). “Knowledge Base Verification”, AI Magazine 8: 2, 65–79. [33]Noran, O.S., (2009). “Business Modelling: UML vs. IDEF.” http://www.cit.gu.edu.au/~noran/Docs/UMLvsIDEF.pdf, last viewed on 01-08-2009. [34]A. Osterwalder and Y. Pigneur, (2002). “An e-Business Model Ontology for Modeling e-Business,” Proceedings of the 15th Bled Electronic Commerce Conference, 1–12, Bled, Slovenia (June 2002). [35] K. Panton, C. Matuszek, D. Lenat, D. Schneider, M. Witbrock, N. Siegel, B. Shepard, (2006). “Common Sense Reasoning – From Cyc to Intelligent Assistant”. In: Y. Cai and J. Abascal (Eds.): Ambient Intelligence in Everyday Life, LNAI 3864 (2006) 1–31. [36]Provan, K. G., & Gassenheimer, J. G., (1994). “Supplier commitment in relational contract ex- changes with buyers: A study of interorganizational dependence and exercised power”. Journal of Management Studies, 31: 55-68. [37]Ryser, J., and M. Glinz, (2000). “Using Dependency Charts to Improve ScenarioBased Testing”, Proc. of TCS2000 Washington D.C., June 2000. [38]Schreiber, G, de Hoog, R, Akkermans, H, Anjewierden, A, Shadbolt, N and Van de 121

Velde, W, (2000). “Knowledge Engineering and Management”, MIT Press. [39]Seddon, P. B., G. P. Lewis, et al. (2004). "The Case for Viewing Business Models as Abstraction of Strategy." Communications of the Association for Information Systems 13: 427-442. [40]Sowa, J, (1999). “Knowledge representation: logical, philosophical, and computational foundations”, Brooks/Cole Publishing, Pacific Grove, CA. [41]Uschold, M, Healy, M, Williamson, K, Clark, P and Woods, S, (1998). “Ontology reuse and application” Proceedings of the 1st International Conference on Formal Ontology in Information Systems(FOIS’98) 179–192. [42]G. Vaidyanathan, (2005). “A framework for evaluating third-party logistics”, Communications of the ACM 48 (1) (2005), pp. 89–94. [43]Van den Poel, Dirk and Joseph Leunis, (1999). “Consumer Acceptance of the Internet as a Channel of Distribution.”Journal of Business Research 45: 249–256. [44]Wagner, G., (2000): “Agent-Object-Relationship Modeling”. In: Proceedings of the 2nd International Symposium: From Agent Theory to Agent Implementation, April . [45]Peter Weill, Thomas W. Malone, Richard K. Lai, Victoria T. D'Urso, George Herman, Thomas G.Apel, , and Stephanie L. Woerner, (2006). “Do some business models perform better than others?” MIT-Sloan School of Management. [46]Yoo, J. and Bieber, M., (2000). “Towards a Relationship Navigation Analysis”. In Prooceedings of the 33rd Hawaii International Conference on System Sciences. [47] E. S. K. Yu, J. Mylopoulos, (1993). “An Actor dependency model of organizational work with application to business process reengineering”. In Proceedings of COOCS'93- Conference On Organizational Computing Systems, Milpitas, USA, 1993

122

Appendix A ER and Process Models The figures are printed from KBST-EM. In the case of the UML diagrams, as was mentioned earlier, Hardy's graphical limitations call for a different usage of swim lanes, which are modelled as blue rectangular boxes. These boxes denote the participating roles in a process, and are linked to activities via appropriate links, in order to show which activity lies in which swim lane. Entity-relationship models The entity relationship models for the four businesses can be seen in figures 51-54. Process models The process models and their decompositions for the four businesses can be seen in figures 55-65. Note that the E-Commerce and Publisher models share their 'Sell books via electronic store' sub-process, so only the E-Commerce process model will be shown. The difference between the two lies in the way orders are processed. In the case of the electronic store retailer, if the book is out of stock, the business has to contact its supplier. This though is not the case for the Publisher, who does not have a supplier, and thus processes its orders internally.

123

Figure 51: ER model for Physical Store Based Business 124

Figure 52: ER model for E-Commerce Based Business 125

Figure 53: ER model for Publisher Business 126

Figure 54: ER model for Auction-Based Business 127

E-Commerce Based Business Processes

Figure 55: Top process for E-Commerce Based Business

Figure 56: Decomposition of 'Buy books to stock and to order' for E-Commerce Based Business

128

Figure 57: Decomposition of 'Sell books via electronic store' for E-Commerce Based Business

129

Figure 58: Decomposition of 'Identify potential customers' needs' for ECommerce Based Business

130

Figure 59: Decomposition of 'Inform potential customers' for ECommerce Based Business. Note that the upper "Finish" node denotes the end of the process, while the lower "Finish" node is a 'Finish (decomposition)' node

131

Figure 60: Decomposition of 'Obtain order in electronic store' for E-Commerce Based Business

Figure 61: Decomposition of 'Receive payment in electronic store' for ECommerce Based Business

Figure 62: Decomposition of 'Deliver product purchased over internet' for E-Commerce Based Business 132

Auction-Based Business Processes Since all the models share a common rationale over their creation, only the subprocesses that have the most differences will be presented.

Figure 63: Top process for Auction Based Business

133

Figure 64: Decomposition of 'Broker books via internet' for Auction Based Business

134

Figure 65: Decomposition of 'Manage auction' for Auction Based Business

135

136

Appendix B Dependency Rules The full set of dependency rules is listed here, and their definitions are given in first order logic form. (1) Contract dependency This type of dependency is fundamental to inter-business relationships. Its derivation is rather simple, as it presupposes that there exist two businesses connected with a contract relationship in the ER model. By capturing this dependency we are capturing a long-term business inter-dependency that has to be fulfilled by both parties equally. This makes it not symmetric. The formal rule, given in first order logic is Business(A) /\ Business (B) /\ contract(A,B) => contract_dependency(A,B) (2) Dependency between resource owner and resource user This dependency presupposes the existence of a resource (dependum), i,e. an instance of the resource ontology, which is owned by one role (dependee) and used by another (depender). A resource owner-user dependency between roles A and B over a resource C exists when A owns C and B uses C, and it means that B depends on A, as the owner of C, to use C. The relationship ontology includes classes that describe ownership and usage relationships, and this way the dependency rule is activated. In first order logic the rule is given by the following expression Role(A) /\ Role(B) /\ Resource(C) /\ own(A,C) /\ use(B,C) => resource_owner-user_dependency(A,B,C) (3) Dependency between resource creator and resource user This is considered to be a fundamental type of dependency, appearing in both process (activity) dependencies and actor dependencies. The user of a resource has to rely (depend) 137

on the creator of the resource for its existence / availability. Role(A) /\ Role(B) /\ Resource(C) /\ create(A,C) /\ use(B,C) = >resource-creator-user-dependency(A,B,C)

(4) Dependency between object owner and object user This is a specialized type of 'resource owner-user dependency' and exists when the resource C is an instance of the class 'Object'. Role(A) /\ Role(B) /\ ObjectC) /\ own(A,C) /\ use(B,C) =>object_owner-user_dependency(A,B,C)

(5) Dependency between facility owner and facility user This is also a specialized type of 'resource owner-user dependency' and exists when the resource C is an instance of the class 'Facility'. Role(A) /\ Role(B) /\ FacilityC) /\ own(A,C) /\ use(B,C) => facility_owner-user_dependency(A,B,C)

(6) Dependency between resource seller and buyer This type of dependency exists when two roles, independently of their role type, act as buyer and seller of the same resource. This is a generic type of seller-buyer dependency that doesn't specialize on the type of resource Role(A) /\ Role(B) /\ Resource(C) /\ buy(A,C) /\ sell(B,C) => resource_seller-buyer_dependency(A,B,C)

(7) Dependency between product seller and buyer This type of dependency exists when two roles, independently of their role type, act as buyer and seller of the same product. This is a specialized type of the 'resource seller-buyer dependency' Role(A) /\ Role(B) /\ Product(C) /\ buy(A,C) /\ sell(B,C) => product_seller-buyer_dependency(A,B,C)

138

(8) Dependency between product producer and buyer This type of dependency is specific, in that the prerequisites limit its context, in comparison to other types of dependency. The role that buys a product depends on the producer of the product. Note that this doesn't necessarily hold that the producer is also the seller of the product. Also, there is a semantic connection with 'resource creator-user dependency' but can't be directly asserted within our context, because it would mean that 'selling' is a specialized type of 'using' which is not clear as to its validity Role(A) /\ Role(B) /\ Product(C) /\ buy(A,C) /\ produce_product(B,C) = >product-producer-buyer-dependency(A,B,C)

(9) Dependency between service producer and buyer This dependency exists when a role offers a service to another role. Because services are modelled as resources, this dependency can hold independently of anything else that is prescribed within the business context of two related businesses (such as contracts, other types of dependencies etc.). Note that 'landlord-leaser dependency' is a specialized dependency of this type. Business(A) /\ Role(B) /\ Service(C) /\ produce_services(A,C) /\ buy_services(B,C) => service-producer-buyer-dependency(A,B,C)

(10) Dependency between customer and business over the distribution channel (store) This dependency captures the information that a product buyer is dependent upon a business for the use of the business's store (physical or electronic). Essentially, this dependency captures the fact that a person who uses a physical or an electronic store to buy a product, depends on the business that operates within that store for the store's existence and accessibility. product_seller-buyer_dependency(A,B,C) /\ Customer(A) /\ Facility(D) /\ operate_within(B,D) => customer-store_dependency(A,B,D) Note that this dependency rule is activated when a dependency of the type 'product sellerbuyer' already exists, and therefore we don't have to check the classes of A, B and C again.

139

(11) Business to Business contract dependency This dependency is a specialization of a simple 'contract dependency', where both involved parties are businesses. This is a rather generic dependency as well, but provides a categorization that can be useful, in order to distinguish b2b contracts from contracts between two parties that are not both businesses (e.g. author-publisher). contract_dependency(A,B,C) /\ Business(A) /\ Business(B) => b2b_contract_dependency(A,B,C) (12) Contract dependency between a business and its supplier This dependency is a specialization of a contract dependency, where the contract is between a business and a supplier of the business. The supplier is considered to be mainly a Wholesaler. contract_dependency(A,B,C) /\ Business(A) /\ Wholesaler(B) => supplier_contract_dependency(A,B,C) (13) Contract dependency between a business and a Landlord As was noted in the beginning of this thesis, the concept Landlord is used in the sense that is adopted in the MIT business classification schema, and does not only refer to landlords of physical locations, but other types of service-offering businesses. contract_dependency(A,B,C) /\ Business(A) /\ Landlord(B) => landlord-services-contract-dependency(A,B,C) (14) Contract dependency between a business and a service-selling contractor This dependency is a specialization of a contract dependency, where one participant is a business and the other is a Contractor. contract_dependency(A,B,C) /\ Business(A) /\ Contractor(B) /\ service-producerbuyer-dependency(A,B,S) => contractor_services_contract_dependency(A,B,C)

(14) Tenancy contract dependency This dependency captures the information of a contract being between a landlord and a tenant. This means that the rule is activated in the case there is a contract dependency between a role and a physical landlord. contract_dependency(A,B,C) /\ Physical_Landlord(B) => 140

tenancy_contract_dependency(A,B,C) (15) Contract dependency between publisher and author This dependency captures the existence of a contract dependency, in which participants are the publisher and the author. Note that this is not a business-to-business type of contract dependency, since the author is not considered as a business. contract_dependency(A,B,C) /\ Publisher_Business(A) /\ Author(B) => publisherauthor_contract_dependency(A,B,C) (16) Dependency between a wholesaler and a retailer This dependency exists whenever a retailer buys an object that the retailer sells Wholesaler(A) /\ Retailer(B) /\ Object(C) /\ buy(B,C) /\ sell(A,C) => product_wholesaler-retailer_dependency(A,B,C) (17) Dependency between a retailer and a customer This dependency exists whenever an end-customer buys a product that a retailer sells. Retailer(A) /\ Customer(B) /\ Object(C) /\ buy_product_as_end-customer(B,C) /\ sell_product_as_retailer(A,C) => product_retailer-customer_dependency(A,B,C) (18) Dependency between a product producer and the distributor of a product This dependency captures the information that a distributor buys a product that a creator produces. Creator(A) /\ Distributor(B) /\ Object(C) /\ produce_product(A,C) /\ buy_product(B,C) => product_producer-distributor_dependency(A,B,C)

(19) Dependency between a product producer and an end-customer that buys the product This dependency occurs whenever there is a product that is produced by a creator and is bought by the end-customer. Therefore, it captures the information that the end-customer depends on the producer of the product, when the end-customer buys it. Creator(A) /\ Customer(B) /\ Object(C) /\ produce_product(A,C) /\ buy_product_as_end-customer(B,C) => product_producer-customer_dependency(A,B,C) 141

(20) Dependency between a financial landlord and a buyer of the landlord's financial services This dependency occurs when a role buys financial services from a financial landlord, and therefore is a specialization of the 'services producer-buyer' dependency. Financial_Landlord(A) /\ Role(B) /\ Financial_Service(C) /\ produce_as_landlord(A,C) /\ buy_service(B,C) => financial_service_producer-buyer_dependency(A,B,C) (21) Dependency between a contractor and a buyer of the contractor services This dependency occurs when a role buys contractor services by a contractor. This dependency is different from the corresponding contract dependency, because it captures different information, namely the depending derived by the actual exchange of contractor services. Contractor(A) /\ Role(B) /\ Contractor_Service(C) /\ produce_as_contractor(A,C) /\ buy_service(B,C) => contractor_services_producer-buyer_dependency(A,B,C)

142

Appendix C Knowledge-Based System Decisions In this appendix, some of the decisions made for the KBS will be presented. A visual insight to the system's internal structure can be seen in figure 69. The notation used in UML activity diagrams (with the changed swim lane approach) can be seen in figure 66. Representation of diagram objects In figures 67 and 68, there can be seen parts of the code that handles the representation of ontology cards. Only these two bits of code are shown, because the logic behind the other representation functions is the same. In the following tables, the corresponding facts for each diagram object are shown. These facts are asserted in the CLIPS knowledge base, and this way they represent the corresponding diagram objects. Table 19 shows the facts for Ontology diagrams,in Table 20 the facts for ER diagrams are shown, and in table 21 the facts for activity diagrams are shown. The variables within the facts in table 19 store the desired information in each case. For example, the fact (ontology class ?name ?image ?card) stores the class's name (?name), the class's diagram image unique id (?image), as well as the id of the class's host card (? card).

143

Figure 66: UML activity diagram notation in KBST-EM

Figure 67: This is the code used to represent diagram objects of Ontology cards. Notice that there are two types of assertions taking place each time. A general assertion to capture the information of the object, and a specialized assertion to capture specifically the class or instance that is retrieved.

144

Figure 68: This is the code used to represent 'Subclass Of' links of Ontology cards.

Ontology Item

Representation Fact (ontology class ?name ?image ?card)

class (ontology instance ?name ?image ?card)

instance

(ontology Subclass-Of ?nameTo ?nameFrom)

Subclass Of

(ontology Instance-Of ?nameTo ?nameFrom)

Instance Of generic item

(ontoObject (objectType ?type) (imageId ?image) (objectId ?obj) (name ?name) (cardId ?card))

Table 19: Representing Ontology items

145

ER - Diagram Item

Representation Fact

(er-diagram entity ?name ?image ?obj ?card)

entity (er-diagram attribute ?fromImg ?fromName ?img ? attName)

attribute (er-diagram relationship symmetric ?img ?relName ? fromImg ?fromName ?toImg ?toName ?card))

non-directional (symmetric) relationship (er-diagram relationship not-symmetric ?img ?relName ? fromImg ?fromName ?toImg ?toName ?card)

directional (not-symmetric) relationship generic item

(erObject (objectType ?type) (imageId ?image) (objectId ? obj) (name ?name) (cardId ?card) )

Table 20: Representing ER diagram items.

146

UML Activity Diagram Item

activity

Representation Facts (activity-diagram activity ?image ?name FALSE ?topcard ?card)

(activity-diagram process-object ?image ?name ?topcard ?card)

object

control flow link

object flow link – object creation

object flow link – object use

activity decomposition

(activity-diagram Predecessor-Of ?toId ?toName ?fromId ?fromName ?card ?card)

(activity-diagram activity-creates-object ?fromId ?fromName ?toId ?toName ?card)

(activity-diagram activity-uses-object ?toId ?nameTo ?fromId ?nameFrom ?card)

(activity-diagram activity-decomposition ?image ? name ?expansion ?top-card ?card)

(activity-diagram activity-performed-by ?fromId ?nameFrom ?nameTo ?card ?top-card)

swim lane Table 21: Representing UML Activity Diagram items

147

Figure 69: Internal structure of the system 148

Appendix D A Walkthrough Example In this appendix, a walkthrough example will be described for one business model case. More specifically, we will consider the entity-relationship model of the Physical Store Based Business. The ER model's logical representation will be produced and shown as CLIPS facts, as well as the produced dependency facts and diagrams. The case of the process models will not be considered, because the rationale is the same.

Handling ER diagrams Given an ER diagram in KBST-EM the system produces its logical representation, and then triggers the appropriate rules of the knowledge-base. The various diagram nodes (entities and relationships) are mapped to the ontology by creating them as instances in the ontology. By running the representation function, these will be given a logical representation in the CLIPS knowledge base, in the form of facts, as described in chapter 4. Entities The derived facts that describe the entities follow the form: (er-diagram entity ?name ?imageId ?objectId ?cardId) ?imageId:

the id of the diagram image that corresponds to the entity

?objecId:

the id of the diagram image's object (this is a Hardy technicality)

?cardId:

the id of the card within which the entity exists

The derived facts that represent entities in the Physical Store Based Business ER model are: (er-diagram entity Warehousing Services 156521 156519 148485) (er-diagram entity Financial Services 156496 156494 148485) (er-diagram entity Store Design Services 156460 156458 148485) (er-diagram entity Shopfitting Contractor 148996 148994 148485) 149

(er-diagram entity Financial Landlord 148984 148982 148485) (er-diagram entity Warehouse Contractor 148669 148667 148485) (er-diagram entity Wholesaler 148633 148631 148485) (er-diagram entity Physical Book Product 148508 148506 148485) (er-diagram entity Customer 148505 148503 148485) (er-diagram entity Physical Store 148502 148500 148485) (er-diagram entity Physical Store Landlord 148499 148497 148485) (er-diagram entity Physical Store Based Business 148496 148494 148485) The derived facts that describe the relationships between the entities follow the form: (er-diagram relationship ?symmetricity ?relImageId ?relName ?fromImageId ?fromName ?toImageId ?toName ?cardId) ?symmetricity:

if the relationship is directional, then it is not-symmetric. If it is not directional, then it is symmetric

?relImageId:

the diagram image id of the relationship node

?relName:

the name (string) of the relationship

?fromImageId:

the image id of the relationship's “from” node

?fromName:

the name of the relationship's “from” node

?toImageId:

the image id of the relationship's “to” node

?toName:

the name of the relationship's “to” node

?cardId:

the id of the card within which the relationship exists

The derived facts are: (er-diagram relationship not-symmetric 156527 buy services 148496 Physical Store Based Business 156521 Warehousing Services 148485) (er-diagram relationship not-symmetric 156524 produce as a contractor 148669 Warehouse Contractor 156521 Warehousing Services 148485) (er-diagram relationship not-symmetric 156502 produce as a landlord 148984 Financial Landlord 156496 Financial Services 148485) (er-diagram relationship not-symmetric 156499 buy services 148496 Physical Store Based Business 156496 Financial Services 148485) 150

(er-diagram relationship not-symmetric 156485 apply services to object 156460 Store Design Services 148502 Physical Store 148485) (er-diagram relationship not-symmetric 156466 buy services 148496 Physical Store Based Business 156460 Store Design Services 148485) (er-diagram relationship not-symmetric 156463 produce as a contractor 148996 Shopfitting Contractor 156460 Store Design Services 148485) (er-diagram relationship not-symmetric 149555 legal ownership 148499 Physical Store Landlord 148502 Physical Store 148485) (er-diagram relationship symmetric 148999 contract 148496 Physical Store Based Business 148996 Shopfitting Contractor 148485) (er-diagram relationship symmetric 148987 contract 148496 Physical Store Based Business 148984 Financial Landlord 148485) (er-diagram relationship symmetric 148700 contract 148496 Physical Store Based Business 148633 Wholesaler 148485) (er-diagram relationship symmetric 148672 contract 148496 Physical Store Based Business 148669 Warehouse Contractor 148485) (er-diagram relationship not-symmetric 148642 sell product as wholesaler 148633 Wholesaler 148508 Physical Book Product 148485) (er-diagram relationship not-symmetric 148636 buy product as retailer 148496 Physical Store Based Business 148508 Physical Book Product 148485) (er-diagram relationship not-symmetric 148570 sell product as retailer 148496 Physical Store Based Business 148508 Physical Book Product 148485)

151

(er-diagram relationship not-symmetric 148567 buy product as end customer 148505 Customer 148508 Physical Book Product 148485) (er-diagram relationship not-symmetric 148553 produce as a landlord 148499 Physical Store Landlord 148502 Physical Store 148485) (er-diagram relationship not-symmetric 148531 lease 148496 Physical Store Based Business 148502 Physical Store 148485) (er-diagram relationship not-symmetric 148520 operate within 148496 Physical Store Based Business 148502 Physical Store 148485) (er-diagram relationship symmetric 148511 contract 148496 Physical Store Based Business 148499 Physical Store Landlord 148485) Applying dependency rules Next step is for the inference engine to try to match the created logical representations with the left-hand sides of the rules that are defined in the knowledge base. The derived dependencies are of the following form: (dependency derived er-diagram ?symmetricity ?dependency-name ?depender-name ?dependee-name ?dependum-name ?cardId) The derived dependency facts are: (dependency derived er-diagram not-symmetric "customer-store dependency" "Customer" "Physical Store Based Business" "Physical Store" 148485) (dependency derived er-diagram not-symmetric "product seller-buyer dependency" "Physical Store Based Business" "Wholesaler" "Physical Book Product" 148485) (dependency derived er-diagram not-symmetric "product seller-buyer dependency" "Customer" "Wholesaler" "Physical Book Product" 148485) 152

(dependency derived er-diagram symmetric "contract dependency" "Physical Store Based Business" "Wholesaler" "Contract" 148485) (dependency derived er-diagram not-symmetric "services producer-buyer dependency" "Physical Store Based Business" "Financial Landlord" "Financial Services" 148485) (dependency derived er-diagram symmetric "contract dependency" "Physical Store Based Business" "Financial Landlord" "Contract" 148485) (dependency derived er-diagram not-symmetric "services producer-buyer dependency" "Physical Store Based Business" "Warehouse Contractor" "Warehousing Services" 148485) (dependency derived er-diagram symmetric "contract dependency" "Physical Store Based Business" "Warehouse Contractor" "Contract" 148485) (dependency derived er-diagram not-symmetric "services producer-buyer dependency" "Physical Store Based Business" "Shopfitting Contractor" "Store Design Services" 148485) (dependency derived er-diagram symmetric "contract dependency" "Physical Store Based Business" "Shopfitting Contractor" "Contract" 148485) (dependency derived er-diagram not-symmetric "landlord-leaser dependency" "Physical Store Based Business" "Physical Store Landlord" "Physical Store" 148485) (dependency derived er-diagram not-symmetric "resource creator-user dependency" "Physical Store Based Business" "Physical Store Landlord" "Physical Store" 148485) (dependency derived er-diagram not-symmetric "facility owner-user dependency" "Physical Store Based Business" "Physical Store Landlord" "Physical Store" 148485) (dependency derived er-diagram symmetric "contract dependency" "Physical Store Based Business" "Physical Store Landlord" "Contract" 148485) 153

(dependency derived er-diagram not-symmetric "product seller-buyer dependency" "Customer" "Physical Store Based Business" "Physical Book Product" 148485) (dependency derived er-diagram not-symmetric "product seller-buyer dependency" "Physical Store Based Business" "Physical Store Based Business" "Physical Book Product" 148485) As an example of this, consider the case where the physical store business buys a book product as a retailer, whereas a wholesaler sells the book product. This can be seen in the following figure. In this case, the following facts will be derived.

Figure 70: A simple case of a business buying a product and a wholesaler selling the product (er-diagram entity Wholesaler 148633 148631 148485) (er-diagram entity Physical Store Based Business 148496 148494 148485) (er-diagram entity Book Product 148508 148506 148485) (er-diagram relationship not-symmetric 148642 sell product as wholesaler 148633 Wholesaler 148508 Book Product 148485) (er-diagram relationship not-symmetric 148636 buy product as retailer 148496 Physical Store Based Business 148508 Book Product 148485) There is a dependency rule that is activated whenever a set of facts of the above form is asserted. This rule produces the 'product buyer-seller' dependency between the Physical Store Based Business and the Wholesaler, over the Book Product. Therefore, the following fact will be derived: (dependency derived er-diagram not-symmetric "product seller-buyer dependency" "Physical Store Based Business" "Wholesaler" "Physical Book Product" 148485) 154

Producing the dependency diagram After the dependency facts are derived, the system goes on to produce the dependency diagram for this business model's entity-relationship diagram. The produced diagram can be seen in Appendix E. The generic dependency set, described in chapter 4, was used for the derivation of this diagram. The output is also produced in text form, in a text file, the content of which is shown in the following lines: Dependency Model - Physical Store Based Business - Entity Relationship Diagram -------------------------------------------------------------------The following dependencies were found: -------------------------------------------------------------------customer-store dependency landlord-leaser dependency resource creator-user dependency facility owner-user dependency product seller-buyer dependency product seller-buyer dependency product seller-buyer dependency product seller-buyer dependency contract dependency contract dependency contract dependency contract dependency contract dependency services producer-buyer dependency services producer-buyer dependency services producer-buyer dependency -------------------------------------------------------------------Total Number of Dependencies: 16

155

156

Appendix E Dependency Diagrams The following figures show the derived dependency diagrams for the E-Commerce Based Business, Publisher Business and Auction-Based Business. The order of the diagrams for each business type is: 1.Resource dependency diagram derived from ER model 2.Object-flow dependency diagram derived from process model 3.Task dependency diagram derived from process model

157

Figure 71: Physical Store Based Business dependency diagram from ER model

158

Figure 72: Physical Store Based Business object flow dependencies between activities for subprocess 'Sell books via physical store'

159

Figure 73: Physical Store Based Business task dependencies from 'Sell books via physical store' subprocess

160

Figure 74: E-Commerce Based Business dependency diagram from ER model 161

Figure 75: E-Commerce Based Business object flow dependencies between activities for subprocess 'Sell books via physical store'

162

Figure 76: E-Commerce Based Business task dependencies from 'Sell books via electronic store' subprocess

163

Figure 77: Publisher Business dependency diagram from ER model

164

Figure 78: Publisher Business object flow dependencies between activities for subprocess 'Sell books via electronic store'

165

166

167

Figure 81: Auction Based Business object flow dependencies between activities for subprocess 'Broker books via internet'

168

169