Exploring REA and Open-edi Business Frameworks for Service Modeling

Abstract

Contemporary business collaborations foster enterprises to make their offerings available to partners and consumers as e-services. In this setting, high-level enterprise models, such as business models, provide an economically aware perspective for elicitation of business services, and thereby, e-services. Recently, REA and Open-edi business frameworks have been jointly considered to provide the Open-edi Business Transaction Ontology (OeBTO) for exploring concepts, relationships and actors involved in business collaborations. In this study, we use these frameworks and supporting architectures to propose a service-centric business model. From a model-based development perspective, the model that we propose is intended to be transformed to a system-centric service model, and further to Web service specifications and coordinations. The purpose of this study is primarily aimed toward an explorative and business-founded identification of services. An example from the insurance business sector is used to argument the way we ground and apply our proposed method.

Keywords

• business model
• REA
• Open-edi
• OeBTO
• business collaboration
• business services
• service engineering

1 Introduction

Over the last few years, it has been extensively argued by the industry community that model-based development is a best practice in software service engineering [ 1 ]. So far, SOA and the following Web services technology have succeeded in aligning with process models, enabling thereby loosely-integrated and reusable task automations. In such service solutions, the business perspective is captured on a tactical, that is, procedural level.

Business models offer some important advantages compared to process models, because they can capture a high-level description of a whole business in a single and easy-understandable view. Using a business ontology, such as for instance REA [ 2 ], e3 value [ 3 ], or BMO [ 4 ], the business modeler can elicit the actors involved in a business scenario and explain their relations formulated in terms of economic resources exchanged between those actors.

In the service-oriented business sector, capturing the consumer needs for economic resources plays an essential role in the elicitation of the services that will deliver these values, seizing thereby a desired competitive distinction. Another important aspect concerns the identification of an explorative service portfolio by spanning all the phases of a business transaction lifecycle, which, according to the International Organization for Standardization (ISO) Open-edi initiative [ 5 ] involves planning, identification, negotiation, actualization and post-actualization.

Recently, the ISO has set an effort on integrating REA and the Open-edi concepts to create Open-edi Business Transaction Ontology (OeBTO), for specifying the concepts and relationships involved in collaborative business transactions. In its essence, the framework captures the economic commitments realized by economic and business events issued by the partners, along the collaboration lifecycle in the Open-edi sense.

Following the previously outlined needs of the service engineering, in this study, we consider the use of the REA business framework and OeBTO to define a servicecentric business model and a method for its creation. Being rooted in the two welldefined and stable ontologies, we believe that the proposed model forms a solid basis to be, from a model-based development perspective, transformed to a SOA model and further to Web services.

The rest of the paper is organized as follows. Section 2 gives the overviews on the used ontological frameworks, and related research. In Section 3 we present our proposal for identification and modeling of business services. Its main points are illustrated further in the section using an insurance business example. Section 4 concludes the paper and gives suggestions for further research.

2 Related Work

In this section, we describe REA, Open-edi and OeBTO models; in addition to that, we give a brief overview of the research related to the design of e-services from a business perspective.

2.1 The REA Business Framework

The Resource-Event-Agent (REA) framework was originally formulated by McCarthy [ 2 ] as a knowledge basis for accounting information systems and focused on representing increases and decreases of value in an organization. Over the time, the framework has been semantically enriched to form a value-based foundation for defining business models of enterprises.

The core concepts in the REA ontology are resource, event, and agent. It is assumed that every business activity can be described as an event where two agents exchange economic values, i.e. resources. To acquire a resource, an agent (i.e. actor) has to give up some other resource. For example, in a goods purchase, the buyer has to give up money in order to receive some goods. Conceptually, two events are taking place: one where the amount of money is given away and another where an amount of goods is obtained. This combination of events is called duality and is an expression of an economic reciprocity - an event receiving some resource is always accompanied by an event provisioning another resource. Lately, Hruby has argued that application models developed based on the REA ontology can capture duality containing more than two economic events [ 6 ]. For instance, in banking, a loan receipt may be compensated with both an interest payment and a loan return.

In the study [ 7 ], the REA framework has been further extended to capture additional granularity levels of the business activities of enterprises. The resulting framework has integrated three vertical layers (Figure 1): - Value chain – this layer describes the configuration of the top-level, that is, valueadded business processes of an enterprise. Each business process identified here has a set of inputs (economic resources given or consumed) and a set of outputs (economic resources taken or acquired). - Business Process (decomposition) – this layer explores every top-level process as an aggregate of the reciprocal economic events issuing exchanges of resources, owned or acquired by the involved agents. - Business events (workflow) – the layer specifies an ordered sequence of the activities (i.e. business events) needed to accomplish the business processes and the transfers of economic resources represented on the above two levels. One of the vital aspects of the described three-layered REA framework concerns the capability for tracing low-level events to top-level business process in the value chain, and opposite, i.e. mapping the realizations of the processes and economic components down to business events.

2.2 Open-edi Business Transaction Ontology (OeBTO)

From the life-cycle perspective, business collaborations typically span a number of phases. ISO Open-edi initiative [ 5 ] considers a collaboration as consisting of five phases (activities): planning, identification, negotiation, actualization and postactualization. In the planning phase, the customer and the provider are engaged in activities to identify the actions needed for selling or purchasing goods and services. The identification phase involves the activities needed to exchange information among providers and potential customers regarding selling or purchasing goods and services. During the negotiation phase, contracts are proposed and completed. Detailed specifications of goods and services, quantity, price, terms, and conditions are determined in this phase. If required, the parties involved may make bids and put forward counter offers. The actualization phase includes all the activities necessary for exchanging goods and services between involved actors as agreed during negotiations. The post-actualization phase encompasses the activities and associated exchanges between involved actors after the major resources are provided.

Recently, the core elements of the REA ontology and the Open-edi proposal have been jointly considered to create a more comprehensive ontological framework, OeBTO, for specifying the concepts and relationships involved in collaborative business scenarios [ 8 ].

Figure 2 shows the Open-edi Business Transaction Ontology (OeBTO). It extends the basic REA ontology with a number of concepts aimed to facilitate the modeling of business collaborations. Economic Event in the model represents an activity that transfer an Economic Resource between Partner agents. An Economic Commitment stipulates Economic Events that are planned or scheduled to occur. The Economic Contract represents a legally enforceable agreement between collaborating parties; it bundles reciprocating commitments where a buyer and a seller agree to fulfill by performing reciprocal economic events. The Agreement element represents a concept similar to Economic Contract. However, unlike Economic Contract, Agreement is not legally enforceable. Business Transaction element in OeBTO represents a predefined set of business activities. These activities are aimed to accomplish an explicitly shared business goal of collaborating parties and are terminated based on the economic contract between involved business agents. Business Transaction Phases defines the set of fundamental collaboration stages - planning, identification, negotiation, actualization and post-actualization, associated with a Business Transaction. These phases are further decomposed down to Business Events, which represent activities that collaborating agents use to communicate the progress through their Business Transaction. Location in the ontology designates the site where an Economic Event occurs. Economic Claim element in the model facilitates the information regarding situations where an economic event occurs without its requited correspondence to another economic event. In addition to these concepts, the ontology also contains concepts such as Resource Type, Role, Location Type, and Economic Event Type, which model abstract specifications for the concepts modeling actual occurrences.

Following [ 8 ], economic resources may be classified as goods, rights or services. Goods are tangible resources including, for, instance materials or funds; services are the provisioning of value-adding activities by a provider to a consumer, such as transportation or warranty; rights are intangible resources related, for instance, to the ownership of intellectual products.

2.3 Related work on Business Services

Following the paradigm of model-based system development, a number of research studies have reported proposals for e-service design. Many of them had set the major focus on a system-centric abstraction level, to define enterprise-wide models of technology-independent e-services, such as in [ 9 ] and [ 10 ]. Some other studies have augmented the starting abstraction level by considering the business process perspective as a basis for creating a business-oriented service model, which is further mapped to SOA-aligned, or SOA-like e-services at the system level [ 1 ]. Being focused solely on the process (i.e. operational) perspective on the business level, the aforementioned studies have not considered the business viability of e-services.

Lately, research in both academic and industrial communities have implied that when designing service-oriented software solutions, the starting point should be the business models of enterprises [ 11 ], [ 12 ], [ 13 ] and [ 14 ]. This fact, according to the referred studies, is shifting the focus of large scale e-service design to the context of economic resource transfers. In [ 14 ], using the e3 business ontology, the authors explore consumer needs and resource exchanges to evaluate the profitability of the identified resource offerings. Our approach differs from those studies in the way that we set our focus on a structured analysis of business transactions, relying on the OeBTO standardization effort, to identify the activities occurring between the actors in a hierarchical manner, and finally expand them along a number of collaboration phases to get a reach business service portfolio. We also believe that our approach facilitates a needed refinement in elicitation of business activities and thereby services, followed by a clear traceability between different abstraction layers.

3 Three-layered Framework for Service Elicitation

In this section, we first explain our method for the identification of business services of an enterprise that relies on the use of the three-level REA enterprise model and the Open-edi Business Transaction Ontology (OeBTO). After, we illustrate the method with an example from the insurance business sector.

3.1 Method

Following the presentation of the extended REA framework given in Section 2.1, the specification of an enterprise comprises the decomposition of business activities along three granularity levels: value chain, business processes and business events. Value Chain Specification In service industries, the traditional Porter’s value chain [ 15 ] has been found as non-fitting, as the resulting chain analysis based on the five, production-rooted, primary activities often blurs the focus off service-centric value creations. In [ 16 ], it is argued that present enterprise value configurations conform to three generic types: the traditional value chain, value shops and value networks. The later two configurations suit to service environments – value shops model the activities and resources to resolve a particular customer problem, while value networks create values by organizing and facilitating exchanges between a set of customers. Each of the three configurations promotes a different set of primary activities. The insurance business taken as the illustration example in this study conforms to the value network configuration assuming that the essence of its value creation lies in an indirect linkage and an organization of insurance customers through a common pool of assets and funds. Following [ 16 ], the primary activities of the value network are: - Network promotion and contract management consisting of activities associated with inviting potential customers to join the network, the initialization, management, and termination of contracts governing service provisioning and charging. - Service provisioning consists of activities associated with establishing, maintaining, and terminating links between customers and billing for value received. - Network infrastructure operation consists of activities associated with maintaining and running a physical and information infrastructure. The activities keep the network in an active status, ready to service customer requests. Thereby, when creating a business model, and considering any of the three value configurations, we outline the first design guideline: Guideline 1: To fulfill the top, value-chain layer of the REA framework for an enterprise of interest, identify a suitable value configuration, and using its classification for the generic primary activities, elicit the value-adding processes for the enterprise.

The OeBTO model, as described in Section 2.2 and illustrated in Figure 2, captures the notion of business transaction; it has been argued in [ 17 ] that in a collaborative setting, the business transaction being defined as a predefined set of activates, can be equalized with the concept of the business process as defined in the REA three-layered framework. Following this, for a business collaboration, once the value-adding business processes are outlined using Guideline 1, they will be captured by the Business Transaction element in the OeBTO model as given in Figure 2. Business Process Specification At this layer, every process specified on the top is explored to elicit the agents involved in the process and the economic events resulting in the exchange of economic resources. The events itself are stipulated from the commitments agreed between the collaborating agents as we have explained in Section 2.2. (see also Figure 2). We have explained that in a REA business model, when offering a resource, an agent expects in return some other resource, which can be, as we have explained in Section 2.2, goods, services or rights. Thereby, each duality of economic events in the process is considered as an economic symmetry and as such, gives rise to a candidate service - we name it aggregated service, because it needs to be further expanded on the next layer of the framework, to discover actual business services belonging to- and realizing that service. Thus, every service elicited at this layer is considered as an economic aggregator of the business services that will be actually created to realize and/or support the delivery of economic resources between the agent offering a resource (i.e. the provider) and the other agent giving away another resource as a compensation (i.e. the consumer).

Guideline 2: To specify the middle, process level of the REA framework for an enterprise of interest, explore every top business process identified by Guideline 1, to elicit the economic events, resources and the agents offering or receiving the resources. Define an aggregated service for each duality of economic events. Starting from this point, the OeBTO model shown in Figure 2 is extended with a new element, aggregated service (see Figure 3). The element is, as explained above, associated with a duality of economic events, the resources being exchanged by these events and the involved agents (considered as playing the roles of the service provider and the service consumer).

Business Event Specification At this layer, a workflow for the resource exchanges defined in the middle architecture level is expanded along all the Open-edi business transaction phases, i.e. planning, identification and negotiation, actualization and post-actualization to elicit candidate business services and business events. Every aggregated service specified on the business process level is decomposed to a number of the business services, following the rules: 1. For every business phase of interest, a single business service is defined.

Commonly, negotiation, actualization and post-actualization phases are recognized in any business collaboration, while planning and identification are considered as optional. 2. Depending on the economic resource type being offered to the consumer, business services in the actualization phase differ. When the resource is a service, then it will directly identify the business service; when the resource is a good, then a business service provisioning the custody of that good and/or evidence document for the good ownership will be added; finally, in case the resource is a right, the business service will be created to provision the evidence document for that right.

According to the OeBTO model (Section 2.2), the notion of the business event is used to represent the atomic business activities occurring at the third framework layer. Thereby, in our view, a business service is an aggregation of business events, that is, once a business service is defined, it can be further decomposed to smaller workflow tasks, i.e. the business events, which business partners need to accomplish in every phase of the collaboration. A business service may, as common, require for certain input objects and provide in return some outputs; the object can be information, or physical items. Following this argumentation and the rules to the above, we propose the instruction for the elicitation of the last framework layer: Guideline 3: Decompose every aggregated service defined at the middle REA layer to a number of business services on the lowest architecture layer, along the five business collaboration phases, by following the two decomposition rules outlined to the above. For every business service, define input and output objects, if such exist. Finally, refine the business service to a number of business events.

In this step, the OeBTO model shown in Figure 2 is extended with the business service element (see Figure 3). The service may bring an input and an output object, and encloses a number of business events.

In service-oriented business interactions, it is the provider who offers certain functionality and the consumer who utilizes it. Before the provisioning of a service, the two parties need to come to an agreement that specify the obligations related to service provisioning. In the OeBTO model (see Section 2.2), the decision what capabilities and constraints the economic resources will be offered, how they will be compensated and under what conditions, are modeled with the notions of economic contract and economic agreement. Thereby, in the service modeling context, we consider contracts and agreements to include, in addition to legal aspects, requirements for provisioning of services. In our extension to the original OeBTO model, we define the element business policy that is specified from an agreement and includes directives related to the execution of services, that is, business services and containing business events. A business policy can be further refined to either business rule or service policy. A business rule restricts the workflow, that is, the control flow of the business events, while a service policy includes sets of constraints and capabilities of a business service to describe how the service and the client will interact. To summarize, the method proposed in this section extends the original OeBTO model to capture the business service perspective and its core aspects, such as functionality, composition and policies. From a model-based system development perspective, by defining a set of transformations, the service-aware OeBTO model as shown in Figure 3 can be considered as the input for creating a system-, i.e. UMLbased service model (or simply, an e-service model). At this stage, there is a number of service-oriented UML profiles, which in the MDA context provides a common way to focus toward a specific architectural style [ 9 ].

3.2 Application

In this section, we illustrate the method presented in Section 3.1, using an example from the insurance business. We consider three agents: insurance provider, insurance broker and a customer. To obtain information about insurance policies, customers can either approach the insurance broker, or the insurance provider. The insurance provider is responsible for providing information about the available insurance policies to insurance brokers and to customers. Once the customer identifies the insurance policy that fits him, he obtains an insurance contract from the insurance provider. Additionally, the insurance provider is responsible for collecting monthly payments from customers and for managing customer insurance claims.

Following Guideline 1 and the classification of the primary activities of the value network configuration defined in the previous section, we identify the following business processes belonging to the Value Chain REA layer. - Insurance Sales process for managing insurance contract with customers (Network promotion and contract management) - Payment Handling process for collecting payments from customers for the insurance services they receive and handling payments regarding customer claims (Service provisioning). - Claim Handling process for receiving and approving customer insurance claims (Service provisioning). - Marketing Management process for managing the provisioning of insurance policy information to insurance brokers and for managing insurance information updates to existing and new customers (Network infrastructure operation).

By following further Guideline 2, the Insurance Sales process elicited above is explored to identify economic events and associated resource exchanges belonging to the Process Specification. Here we identify, two economic events; Provide Insurance Contract – Obtain Right to Invoice defined from the Insurance Provider perspective (see Figure 4). The former economic event is responsible for provisioning the economic resource Insurance Contract to Customers whereas the latter is responsible for receiving the resource Right to Invoice from the Customers. The obtained duality gives a rise to an aggregated service Provisioning of Insurance Contract.

The elicited aggregated service is, by following Guideline 3, further expanded to identify business services and aggregated events. As it was mentioned in the method section, here we consider planning, identification, negotiation, actualization and postactualization phases to identify business services and events. - (Planning) Considering the case where a customer directly approaches the Insurance Provider to get information about insurance policies, we identify the business service Insurance Information Provisioning. This business service composed of two business events; Accept Customer Contact and Provide Insurance Policy Information (see Figure 4). - (Identification) In this phase, we identify the business service Customer Information Acquisition for establishing a literal relationship with the customers who wish to obtain an insurance contract. This business service is further expanded to identify two business events: Obtain Customer Decision and Obtain Customer Information (see Figure x). - (Negotiation) The business service Contract Formation is identified to support the formation of an insurance contract realizing the aggregated service in the Business Process Specification layer. We identify two business events Offer Insurance Contract and Obtain Contract Acceptance (see Figure 4) for the identified business service. - (Actualization) For supporting this collaboration phase, we identify the business service Invoicing Right Acquisition corresponding to receiving the right to invoice to customers for the insurance contract they obtained from the Insurance Provider. This business service aggregates the business events Send Customer Copy of the Contract, Obtain Invoicing Information and Update Customer Insurance Information (see Figure 4). - (Post-Actualization) In the last phase, we identify business service Customer Information Sharing which is responsible for passing customer information further to Payment Handling, Claim Handling and Marketing Management processes. This business service constitutes the business events Provide Customer Invoicing Information (Right to Invoice) and Provide Customer Details (see Figure 4). Following what has been stated in Section 3.1, we finalize the model by identifying the business rules that will govern the execution of the workflow specification, and the service policies constraining the offering of the business services elicited above. For instance, a service policy for the business service Insurance Information Provisioning can be defined as “A customer request for insurance information should be fulfilled within five working days”. Additionally, “Customer information should be validated before issuing an insurance contract” is an example of a business rule that governs the ordering of the workflow events.

4 Conclusion

In this paper, we have proposed a method for identification of business services, based on the exploration of business models, from a collaboration life-cycle perspective.

In our approach, we have used Open-edi Business Transaction Ontology (OeBTO) proposed by the International Standardization Organization (ISO), as a conceptual basis. The ontology uses REA as business ontology for specifying the concepts and relationships involved in business collaborations along the major life-cycle phases as they are defined by Open-edi. A rationale for choosing OeBTO lies in two facts: a) the components of the REA business model are sufficiently well-defined, stable, and well-known; and b) service environments require for an exploration of business collaborations, which is the essence of Open-edi effort.

Our method guides the business service modeler to expand the REA business modeling framework along three abstraction layers, starting by identifying valueadding business processes of an enterprise; then expanding these processes to define the economic resources that will be exchanged between particular agents and published as top-level, aggregated services; and finally, expanding the aggregated services along the planning, identification, negotiation, actualization and postactualization phases to elicit business services. The composition and the use of the defined business services is guided by the business rules and service policies as directed from the commitments and obligations elements belonging to OeBTO.

The major strength of the proposed method is the use of the REA three-layered framework and OeBTO for identifying an entire enterprise-wide service portfolio on the business level, defined well-enough to be transformed further to a system-centric, i.e. an e-service model.

Topics for our future research are focused on a model-driven perspective to software service development. Thereby, the next research steps include creation of transformation rules from the business service model as proposed in this paper to a SOA-aligned e-service model, with capturing both declarative and behavioral service aspects.

References

1. Rosen , M. , Lublinsky B. , Smith , K.T. , Balcer , M.J. 2008 . Applied SOA : Service-Oriented Architecture and Design Strategies , Wiley Publishing Inc. Indiana.

2. McCarthy W. E. 1982 . The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review .

3. Gordijn J. , Akkermans J.M. and Vliet J.C. van. Business Modeling is not Process Modeling. Conceptual Modeling for E-Business and the Web , LNCS 1921 , Springer-Verlag, pp. 40 - 51 .

4. Osterwalder , A. , Pigneur , Y. ( 2002 ). An e-business model ontology for modeling ebusiness . In Proc. 15th Bled Electronic Commerce Conference , Bled, June 2002 .

5. ISO/IEC. 2002 . ' Operational aspects of Open-edi for implementation' . ISO Standard 15944- 1.

6. Hruby , P. Model-Driven Design Using Business Patterns. Springer Verlag. ISBN: 3-540- 30154-2

7. Geerts , G. , McCarthy , W.E. , 2002 . An Ontological Analysis of the Primitives of the Extended-REA Enterprise Information Architecture , The International Journal of Accounting Information Systems , Vol. 3 , pp. 1 - 16 .

8. ISO/IEC. 2007 . ' Business transaction scenarios - Accounting and economic ontology' . ISO Standard 15944-4.

9. Johnston , S. 2005 . 'UML 2.0 Profile for Software Services' . IBM Cooperation , Available at http://www.ibm.com/developerworks/ ration-al/library/05/419_soa/. Last accessed 01.15 . 2010 .

10. López-Sanz , M. , Acuña , C. J. , Cuesta , C.E. , Marcos , E. 2008 . 'UML Pro-file for the Platform Independent Modelling of Service-Oriented Archi-tectures' . LNCS: Vol 4758 (pp. 304 - 307 ). Springer Berlin / Heidelberg.

11. Baida , Z. , Gordijn , J. , Saele , H. , Akkermans , H. , Morch , A. 2005 . 'An Ontological Approach for Eliciting and Understanding Needs in e-Services' . Proceedings. Seventeenth International Conference on Ad-vanced Information Systems Engineering (CAiSE 2005 ). LNCS Vol. 3520 (pp. 400 - 414 ). Springer-Verlag.

12. Cherbakov , L. , Galambos , G. , Harishankar , R. , Kalyana , S. , & Rackham , G. 2005 . Impact of Service Orientation at the Business Level . IBM Systems Journal , Vol. 44 ( 4 ) (pp. 653 - 668 ). IBM Corp.

13. Anderssson B. , Johannesson P. , & Zdravkovic J. 2007 . Aligning Goals and Services through Goal and Business Modeling . The International Journal of Information Systems and eBusiness Management (ISEB) , Special issue on Design and Management of Business Models and Processes in Services Science , Vol. 7 (pp. 143 - 169 ). Springer Berlin/Heidelberg.

14. Gordijn , J., van Eck, P. , Wieringa , R. 2009 . Requirements Engineering Techniques for eServices . In D Georgakopoulos and M.P. Papazoglou (Ed.), Service-Oriented Computing: Cooperative Information Systems series (pp. 331 - 352 ). The MIT Press. Cambridge.

15. Porter , M. ( 1998 ). 'Competitive Advantage: Creating and Sustaining Supe-rior Performance' . The Free Press.

16. Stabell , C. B. and O. D. Fjeldstad ( 1998 ). Configuring value for competitive advantage: on chains, shops, and networks . Strategic Management Journal . Vol. 19 , pp. 413 - 437 .

17. Gailly , F. , Poels , G. 2009 . Using the REA Ontology to Create Interoperability between ECollaboration Modeling Standards . Proceedings. Twenty First International Conference on Advanced Information Systems Engineering (CAiSE 2009 ). LNCS Vol. 5565 , pp. 395 - 409 . Springer-Verlag.