A Generic Constraints-based Framework for Business ... - CiteSeerX

A Generic Constraints-based Framework for Business Modeling Min Li and Chris. J. Hogger Department of Computing Imperial College London SW7 2AZ UNITED KINGDOM {minli, cjh}@doc.ic.ac.uk

Abstract. The potential benefits of logic-based modeling methods encourage business organizations to construct models offering flexible knowledge representation supported by correct and effective inference. However, owing to the problems of encoding expertise, the ambiguities in business concept formulation and the diversity of possible evaluation methods, there is no clear consensus on how best to apply logic-based formalization to informal or semi-formal business modeling. Our work aims to build a formal generic model framework comprised of sub-models that formulate distinct core aspects of business. The framework employs logical constraints to represent and compute the key relations among business entities, and offers scope for clarifying the semantics of other existing frameworks by translating them into this one. The paper outlines our framework and presents a synthetic case study to illustrate its nature and operation. Keywords business modeling, logical constraints, business concepts formulation

1

Introduction

A business model embodies the logic underlying the operation of business organizations. It should enable one to understand and predict ”how a business company is organized, what it sells, how it delivers products and services, how it adds value” [1]. Undoubtedly, business models are playing an ever more important role in the competitive, dynamic and increasingly uncertain economic society. However, owing to the problems of encoding expertise, the ambiguities in business concept formulation and the diversity of possible evaluation methods, there is currently no clear consensus on how best to formalize concepts that may be articulated only informally or semi-formally within the business community. This paper describes our attempt to represent some of these concepts in the declarative but executable framework of logic programming, including constraint logic programming. Our aim is to do this at a level of abstraction capable of representing sufficient concepts to enable useful model instances to be built and evaluated whilst at the same time not becoming so overwhelmed with detail and specificity that we forfeit generality and transparency.

While most existing research on business modeling concentrates upon very specific business domains, our interest is in conceptual and logical aspects of business in general. Our ultimate aim is to achieve a generic model which provides a semantic basis, and hence a means of comparison, for the many specialized modeling frameworks already existing. To pursue this aim we survey some existing frameworks for business modeling and seek to capture their common essentials in our generic model. Starting with some instance of the generic model, modelers can then further instantiate and elaborate this to create their own more specific and detailed models. We outline the functions evolved in each sub-model and describe how they contribute to the overall model. In particular, we illustrate the representations and executions of business plans and constraints with simple examples. The contributions of this paper can be summarized as follows: – a decomposition of the notion of a ”business” into four separable bodies of logical constraints-covering, respectively, schedule, artifacts, finance and human organization-and a fifth body of meta-constraints expressing business rules intended to cohere the other four; – a generic, transparent and executable scheme for representing business plans and constraints having a simple and well-defined semantics and exploiting the computational power of constraint logic programming. – a simple and fully automatic simulator to simulate a typical business procedure, displaying required information and data through dynamically generated business assets. In section 2 we discuss some related work. Section 3 outlines overall structure of our own model. We explain how business plans and constraints are represented and executed in sections 4 and 5 respectively. Section 6 outlines design and implementation considerations for simulating holistic business procedure. Finally, in section 7 we review the work undertaken, and our future intentions for the framework.

2

Related Work

It is evident that expressive power and logical transparency are key factors for a business company in choosing their models. Chen [2] in AIAI presented research on formal enterprise modeling using a supporting tool named KBST-BM. However, it aims from an engineering perspective at a relatively lightweight logical framework in lacking strong logical formalization of key business concepts and relationships. Gordijn [3] proposed an ontology-based conceptual model named e3value, focusing on modeling conceptualization and ontology of e-business. Loucopoulos [4] advocated the management of shared knowledge and the use of a conceptual modeling paradigm to support enterprise changes. Osterwalder [5] [6] summarized the conceptual business modeling method and presented Business Modeling Ontology (BMO). His work connects with ours especially in relation to

the components of business models, providing a good starting point in extracting the business essentials for our generic framework. More generally, there exists a growing research community which is focusing on defining and classifying business concepts, analyzing business components, developing business representation tools [7], [8], [9], and [10]. We share a similar motivation with them in business conceptualization. Recently the Business Rules Team carried out a standard called ”Semantics of Business Vocabulary and Business Rules (SBVR)” [11], which provides possibilities to share the meaning and semantics of business vocabulary and rules. SBVR is independent of any model-driven architecture and is intended to provide a common bridge between business and business models. When investigating business modeling, it is inevitable to refer to what might be termed the ”software engineering” imperatives of business analysis and design. Early approaches to this included Structured Analysis [12], [13] and the Vienna Definition Method [14]. Structured analysis is a general method for both business modeling and system modeling. It combines hierarchical data flow diagrams, sum-of-product data specification, local functionality specification and subsequently, entity-relationship diagrams. It further defines several analysislevel artifacts which together form the structured specification for models. The method provides a general bridge between business modeling and the general philosophy of disciplined software engineering. By comparison, VDM is a particular program development method based on formal specification. It begins with a very abstract specification and develops this into an implementation. Each step involves data reification and operation decomposition. Data reification develops abstract data types into more concrete data structures, while operation decomposition develops the (abstract) implicit specifications of operations and functions into algorithms that can be directly implemented in a computer language of choice. The design of our own framework was somewhat inspired by the ideas of VDM. We started from an abstract level of business concepts and their inter-functions, and then effectively performed reification and decomposition to reach a layer of acceptable detail. More specialized frameworks exist to address particular aspects of the business modeling task. The ARIS language and tool set [15] employs so-called event process chains to capture and standardize business processes, facilitating the tasks of analyzing and re-designing them. The nearest correlate of these event process chains in our own framework is our plan structure and associated temporal constraints. Another example is Form-Oriented Analysis [16] applicable to businesses employing submit-response protocols, e.g. as seen in many webbased business applications. The interactions are modeled in a structure called form chart which effectively formalizes a finite-state machine. Through this artifact it becomes possible to elicit, in a reverse-engineering style, a semantically well-defined specification and structuring of the logic underlying the business. However, the task of ascertaining the nature and rationale of any given enterprise through the use of systematic software engineering methodologies has not so far been our main focus. Our work could perhaps best be compared with

the development of expert system shells, whose main contribution was to establish workable representations and reasoning systems capable of accommodating the rationales of arbitrary application domains, after those rationales had been elicited and shaped by domain specialists and software engineers. In short, our framework offers logical formulations and reasoning mechanisms constituting a generic approach to business modeling aiming to provide a high-level, transparent and flexible means of expressing the diverse entities and constraints typically encountered in business.

3 3.1

Model Structure Defining the Model

A business model can be comprehended as an abstract expression of the business logic of an enterprise. The business model design translates a strategy into a business model blueprint. Then it has to be financed through internal and external funding after finally being implemented into an actual business enterprise [5]. By analyzing the existing definitions of ”business” and ”business model” [1], [2] and [5], we give our summarized definition of ”business model” as follows: A company’s business model is a conceptual model that consists of a set of functional elements and their inter-functional relationships, representing a company’s logic of business and profit making. Here, the logic of business and profit making refers to the mechanism by which a company offers value to customers and the structure of the firm and the partner networks for creating, marketing and delivering this value and relationship capital to generate profitable and sustainable revenue streams [5]. 3.2

Model Decomposition

In principle, the business of an enterprise can be formulated as a purely declarative theory expressing various business entities, their properties, inter-relationships and controls [17]. Achievable goals of the enterprise can then be identified with logical consequences of the theory, and derivations of those goals can be interpreted as particular simulations of the enterprise. However, such a theory may turn out to be highly non-deterministic in practice. A more practical approach is to replace parts of that theory by business plans which, though still expressed declaratively, are inherently more deterministic to the extent that they embody some preconceived commitments to the control and interdependence of events. We decompose our conceptualization of a business model into five sub-models in a general manner: the business plan model, the artifacts model, the organizational model, the financial model and the business rule model. We will describe these in more detail in sub-section 3.3. Concretely, they consist primarily of logical constraints, interpreted as business requirements. For each of the first four, its constraints refer only to the particular entities associated ”naturally” with it. For instance, the organization model would not normally contain constraints

referring to financial assets as well as to artifacts such as physical assets. By contrast, the business rule sub-model has a more global character, containing constraints that typically refer to entities within the other four, its purpose being to integrate the overall logic of the enterprise and cohere the other four at the same time . An example of a business rule is the constraint that ”this product can be sold in this period only to customers in these territories owing to licensing restrictions”. It is not difficult to understand that this sample rule contains the requirements at least from organization and artifacts sub models. Figure 1 shows the five sub-models, indicating the central role of the business rule model in cohering the other four. Its effect is to induce dependence between these other four, since their constraints must be satisfiable not only locally to themselves but also globally to the holistic business architecture.

Business plan model

Organization model

Business rule model

Financial model

Artifacts model

Fig. 1. A rule-centric business model framework

All these sub-models need to be further detailed and decomposed, as we shall outline and discuss in section 6. 3.3

Sub-model Features

The business plan model serves chiefly to constrain the temporal flow of actions performed as the business proceeds and, in order to anchor such constraints, it includes also a set of business plans each comprising a set of actions. Each action expresses some event that variously consults, manipulates or relates essential entities such as artifacts, finance or personnel, and is tagged by temporal parameters expressing the period over which the action is undertaken. A plan is treated as a repeatable pattern of activity, so that multiple instances of it may arise as the business proceeds. We refer to each such instance as a process. Our representation of plans in this paper is mainly adapted from that used in [17], [18] and [19] and is described in section 4.

The organization model contains constraints expressing relationships between the participants engaged in the business. Participants include internal human resources and also external participants such as suppliers, customers and partners in other businesses. The artifacts model constrains the non-human resources handled by the business. These resources may be physical in nature, such as materials and components used in manufacturing, or bureaucratic such as electronic records and communications. The constraints typically express, at the least, the attribute schemas of such entities but may also go further by specifying their concrete instances. The detailing of artifacts and their assumed constraints can be pursued using a variety of logical design frameworks. These include description logics [20] exploiting key relations such as ”contains” - e.g. ”this artifact contains these sub-artifacts” - and ”is a” - e.g. ”a house is an instance of a building”. The financial model constrains the financial aspects of the business, including its costs, profits and revenue streams. One existing method of formulating these constraints would be through the e-business value model proposed Gordijn et al [3]. The business rule model is the key part of the whole structure, cohering and interacting with the other four. It behaves effectively as their meta-theory, expressing the higher-level policies devised by senior managers or other strategy handlers.

4

Business Plans

As noted above, the business plan model describes sets of business actions and the temporal constraints imposed upon them. It derives from a simpler precursor described in [17] which modeled a business as a collection of plans, each of these being a logic program representing some set of actions together with some control imposed over that set. The output of the model, whether by inference or simulation, simply comprised the logical consequences of the union of the plans. The current framework is process-oriented, permitting each plan to spawn multiple processes. Figure 2 shows one plan among many in a model we have recently built of a simple tool-hire company. This plan describes the logic of seeking in the company’s records an existing, but as yet unprocessed, customer request for a tool of some specified type and, if finding such a request, duly processing it. Provided the request is acceptable, in that the tool type is known to the company’s current inventory, the plan seeks a corresponding physical tool within its current stock. If such a tool is found then it is hired to this customer; otherwise some such tool must be already hired out to some previous customer, in which case the plan reserves it for the current customer. In either case the company incurs some administrative expense which the plan records. Each ”action” clause in a plan is a meta-declaration having an inner term, such as hire(request, tool, hiring, t4), which is interpreted as an object-level predicate whose meaning is defined by some logic program held in a separate

% plan "toolhire" action(toolhire, 1, acquire(request, toolrequest, outcome1, t1)). action(toolhire, 2, yes(outcome1), testacceptable). action(testacceptable, 1, copy(inventory, t2)). action(testacceptable,2,acceptable(request,inventory, tool), tryhire). action(tryhire, 1, acquire(tool, any, outcome2, t3)). action(tryhire, 2, yes(outcome2), dohire, doreserve). action(dohire, action(dohire, action(dohire, action(dohire,

1, 2, 3, 4,

action(doreserve, action(doreserve, action(doreserve, action(doreserve,

hire(request, tool, hiring, t4)). hireadmincost(expense, t5)). recordexpense). publish(hiring, nc, t6)). 1, 2, 3, 4,

reserve(request, reservation, t7)). reserveadmincost(expense, t8)). recordexpense). publish(reservation, nc, t9)).

control(toolhire, seq). control(tryhire, seq). control(testacceptable, seq). control(dohire, seq). control(doreserve, seq).

Fig. 2. A tool-hire plan

component of the model called the action knowledge base (AKB). The arguments of the predicate are treated in the implementation as ontological variables. Like action(tryhire, 2, yes(outcome2), dohire, doreserve), some ”action” clauses are conditional in nature, diverting control to one or other constructs. Figure 3 explains the relations implicated within plans, blocks and actions. Simply to put, these three objects have very similar structures in form except that if we use tree structures to express their relations, they are denoted by different types of nodes in a tree. A single plan node is denoted by the root node, a whole plan refers to the sub-tree originated from the corresponding root. The leaf nodes represent the atomic actions we mentioned above. The mid-nodes denote exactly what we call functional blocks. What worth mentioning is that the arc arrows across the sibling relations indicate the sequential order of the corresponding executions, while being concurrent without these arrows. We do not spell out here the entire grammar and surface syntax of the plan language. The essential point is that a plan establishes relations between variables as defined in the AKB. From the operational viewpoint, execution of the model consists of spawning and running processes generated from the plans. Each process is an instance of a plan having its own binding environment for its variables. The temporal variables become bound to the times at which their associated actions are performed. Spawning and advancement of processes is controlled by constraints in

Plan1

Function block

Function block

action

action

Plan2

Function block

Function block

Function block

action

action

Function block

action

action

action

Fig. 3. A tree structure to indicate some plan semantics

the business rule model. In the present example, these constraints are such that processes are first executed to build up the company’s stock of tools and to initialize such things as accounts and pricelists, after which customer request processes then follow. As these get underway, other processes are spawned to deal with these requests in a concurrent but suitably-coordinated manner. The assets of the business are represented separately as structures incorporating preserved bindings of selected process variables. They function as one of the means by which processes interact and exchange resources, and they survive in the runtime environment after their originating processes have terminated. The model includes provisions for controlling the rights that processes have to access and modify existing assets.

5

Representing and Executing Business Constraints

An additional and significant control over processes’ behavior and outcomes is the use of separately defined constraints over their ontological variables. These constraints are defined by, variously, Prolog programs or finite-domain constraint logic programs. They are an important means of expressing business requirements, constraining such aspects as the attributes of assets and the scheduling of process actions. They are operated on by a constraint evaluator running concurrently with the software that drives the spawning and progression of processes. The model supports a number of modes for coordinating constraint evaluation with process execution, the default mode being that which re-evaluates the constraints whenever a process action binds or further instantiates any ontological variable. However, the power of finite-domain CLP allows other modes, such as that in which constraints are evaluated (as far as they can be) in advance of process execution, for instance to restrict the possible time schedules. Figure 4

shows a simpler plan named p1 for a manufacturing company, and will be used to illustrate the role of the constraints.

action(p1, action(p1, action(p1, action(p1, action(p1,

1, 2, 3, 4, 5,

stock). make(m1, c, [a, b], (st5, et5))). test (ts1, c, (st6, et6))). dispatch(d1, ds1, c, t7)). service).

action(stock, 1, stock_a). action(stock, 2, stock_b). action(stock_a, 1, stock(s1, pr1, a, t1)). action(stock_a, 2, ship(sh1, a, (st2, et2))). action(stock_b, 1, stock(s2, pr2, b, t3)). action(stock_b, 2, ship(sh2, b, (st4, et4))). action(service, 1, sell(sd1, c1, d, t8)). action(service, 2, serve(sd2, c1, d, (st9, et9))). control(p1, seq). control(stock, con). control(stock_a, seq). control(stock_b, seq). control(service, seq).

Fig. 4. A simple manufacturing plan

Here, p1 starts by performing two tasks concurrently. Each one stocks and then ships a raw product. Raw product a is stocked by stockist s1 from provider pr1 at t1, and then shipped by shipper sh1 during the period extending from start-time st2 to end-time et2. A similar treatment is applied to raw product b. After this, the raw products are made into c by manufacturer m1 from st5 to et5. Before c is dispatched by d1 to ds1 at time t7, it is tested by ts1 from st6 to et6. Concurrently with the above, other actions are executed which sell a product d from sd1 to customer c1 at t8 and then provide a service by sd2 for that product from st9 to et9. Any required constraint is identified by a logical goal of the form rel(Args) where rel is defined in a separate rulebase of business requirements. Args typically comprises ontological variables belonging to one or more processes. Depending on the definition for rel, the effect of the constraint on any one of these variables may be to restrict the variable’s binding to a particular value or to restrict it to a particular finite domain of possible values. The ultimate intention of the business requirements is to ensure that its assets (which term we use in a very general sense) are generated, scheduled and managed in the manner desired. Not all constraints need to be declared explicitly. Basic temporal constraints are implicit in that we have, for instance, start < end for any temporal pair (start, end) in an action.

For the above plan, explicitly declared constraints and their associated definitions might appear in the requirements rulebase as shown in Figure 5.

constraint (const1, max_duration(st2, et2, 3)). constraint (const2, max_duration(st4, et4, 2)). constraint (const3, to_customer(d, c1, cl1)). .. max_duration(S, E, D):- domain ([S, D, E], 1, 1000), E-S