Towards Objective Business Modeling in Enterprise Engineering ...

Towards Objective Business Modeling in Enterprise Engineering – Defining Function, Value and Purpose João Pombinho1,2, David Aveiro3, José Tribolet1,2, 1

CODE - Center for Organizational Design & Engineering, INESC INOV, Rua Alves Redol 9, Lisbon, Portugal 2 Department of Information Systems and Computer Science, Instituto Superior Técnico Technical University of Lisbon, Portugal 3 Exact Sciences and Engineering Centre, University of Madeira, Funchal, Madeira, Portugal [email protected], [email protected], [email protected]

Abstract. Current Enterprise Engineering state of the art does not fully address concerns such as bootstrapping and reengineering a working organization from the business perspective. It is currently focused on ontology, the constructional vision, rather than the function. We argue that the function design deserves no less modeling effort, as the construction design draws upon it. To this aim, a change of approach is necessary. By combining knowledge from DEMO, Service Science and e3Value, this paper presents conceptual contributions towards modeling the contribution perspective of a system in an integrated way, namely by defining Function, Value and Purpose. These concepts are first defined in the context of a dual party relationship and then applied to chains of two or more elements. By coupling with an innovative application of the Generic System Development Process, an extension of existing Enterprise Engineering theory is proposed, in a way we believe will assist in improve its current state of the art and widen its application scope. Keywords: Enterprise Engineering, Purpose, Value, Function, Market

1

Introduction

Modeling organizations as complex systems keeps gaining importance and is an everincreasing challenge as 1) boundaries between organizations are increasingly more dynamic and 2) the complexity of the combination between organizations and their support systems as a result of increased ICT support. These two factors contribute to the lack of coherence and consistency among the various elements of an enterprise and, in turn, to the failure of strategic initiatives [1, 2]. Enterprise Engineering (EE) is an emerging discipline that aims at intellectually managing complexity with the objective of creating systems that operate as a unified and integrated whole [3]. It entails the creation of theories, models and methodologies for analysis, design, implementation, and governance of enterprises.

However, current EE state of the art does not fully address concerns such as bootstrapping and reengineering a working organization from the business perspective, mainly because it is currently focused on ontology, the constructional vision, rather than the function. Particularly, the Design and Engineering Methodology for Organizations [4] (DEMO) has no structure or method definition of that supports the initial stage of the system lifecycle from a business perspective. The function perspective deserves no less modeling effort, especially as the construction design draws upon it. Furthermore, we argue that not having traceability between system function and construction impairs bootstrapping, maintainability and evolvability of the modeled enterprise. This paper presents the groundwork of an extensional approach addressing the function dimension objectively. It includes new concepts and their positioning on an overall framework, as an additional perspective that is integrated with current EE theory and methodology. The paper is structured as follows: Section 2 presents problem analysis with a Library as motivation example. Section 3 outlines an innovative approach to framing borganization development in DEMO. Section 4 builds on that by defining and discussing individual concepts. Section 5 extends the previously defined concepts into a system chain. The paper closes with conclusions and contribution summary in Section 6.

2

Problem Statement and Approach

2.1

Background - the relevance of the non-constructional perspective

It is important to differentiate two aspects of system development1: teleological, concerning its function and behavior, a black-box perspective; and ontological, about its construction and operation, a white-box perspective [5]. This distinction is important, as it forces both 1) the separation of these concerns and 2) their articulation. The argument provided in [4] regarding the absurd in asking a mechanic to disassemble a car according to its functional description (with items such as lighting, power, steering and brake systems) in not entirely valid in this context: there is a physical, chemical, electric system that was purposefully designed to reach a function. It is on the shoulders of that work that a mechanic performs its activity. In reality, during the mechanic’s mental process of diagnosing and solving problems, this mapping must necessarily be made as the customer is not expected to be able to pinpoint the constructional elements affected by a functional failure. We acknowledge a space for argument may remain, related to function design being a craft and not an exact science, and also due to the fact that a design is, by definition, sub-optimal. Nevertheless, this should not discourage from making an honest effort to model the functional (or, in fact, the whole non-constructional) perspective, should that activity provide usable and interesting results. Ultimately, someone will perform the functional/constructional mapping and if it is done with asymmetrical/incoherent information (in either direction), the invitation to failure is inevitable.

1

We consider system development to be comprised of both design and engineering activities.

Dismissing the functional perspective in favor of focusing on the constructional perspective has impacts on scoping and collaboration with other system development stakeholders; particularly, the notion of purpose is frequently dismissed as a strategic concern. We are not aware of structured definitions of purpose that can be used as input to a system development process, neither traced back from a developed system, compatible with the models of a system’s construction in formality and detail. For instance, Goal-Oriented Requirements Engineering (GORE) [6] approaches directly and effectively address the traceability issue but do not provide a formal model of the contribution that enforces bidirectional coherence between goals and construction. 2.2

Library Example

In order to clarify the problem space, a practical scenario based on the classical DEMO Library case [4] will be used for instantiation. In this example, the elements of the system dealing with the membership (solid line-bounded area in Fig. 1) are not justifiable as bringing direct value to the customer - who only wants to get hold of a book. However, as it can be seen in Fig. 1, this is all but clear in the ontological (construction) model:

Fig. 1. Library example – Construction analysis. Regarding the core business of providing reading content: 1) the core service is concealed in the area marked by a dashed line, obscured inside a loan transaction; 2) inside the solid black line, a sacrifice of the customer in obtaining the service and its support (sub)system; finally, the area bounded by points encloses a support process that may need revision, for instance, in a change scenario of going digital. About the Membership Management subsystem, one must ask if there is really a customer who wants a membership or was this subsystem included in the Library as the manifestation of a strategy to get a fixed amount of income to face, for instance, stocking management? Is this still a problem if the organization does not pay for the books and space? Is it done for profit or simply as a response to the cost of keeping a large library? Is it part of the Library concept, i.e., every library also offers it by definition? Under what conditions this decision should be reviewed?

We must conclude that in current EE state of the art, the construction of a system resulting from the development process is a compiled structure that obscures the system/subsystem relations and their motivation, because they were created from a flat description of the operation of the organization, instead of a sequential bootstrap or an incremental design step. 2.3

Problem Statement

In this paper, we are particularly interested in exploring the relation between teleology and ontology in the context system development. In DEMO, this corresponds to the functional perspective and constructional perspective, respectively. We note that a function is served by a number of constructions. The tree of possible constructions of the system being developed, let’s designate it as object system (OS), for satisfying a given function is structured by successively restricting their degrees of freedom while introducing constraints. These constraints are the result of applying both functional and constructional principles to the requirements, which are derived from the construction of a using system (US). The model of the US and the way requirements are expressed, namely their abstraction level, is also a constraint over the solution. The fact that the DEMO methodology begins by using a description of an organization works skips a very important part: why was it assembled that way? This need for explicit, structured reasoning may be a nice to have in modeling a snapshot of the organization lifecycle but is critical when dealing with change. For instance, the current construction of a system has a role as an input of its own change process. But, if it does not provide enough information of why each element of the system belongs to it – the reasoning behind its inclusion as a piece of the solution – besides rework it will likely imply risks in cohesion and coherence of the system resulting from the development driven by the as-is/updated hybrid functional model. DEMO's approach to the business-organization, is about ontology, the constructional vision, rather than the function. As mentioned in the previous section, DEMO does not currently address, or even aim at addressing, the function perspective in detail. However, we argue that the function should not be dismissed on the basis of its apparent subjectivity. Therefore, the main question is: how to (more) objectively represent the teleological perspective of a system? Our proposal consists in introducing the market concept into system modeling activities in order to support dynamics and mediate teleological and ontological visions of a system. The hypothesis is that a system is a value chain itself and can be further decomposed in a value model within the system’s scope. For instance, using the Library example from Fig 1, each subsystem necessarily has a functional model. 2.4

Approach

The relevance of a new perspective other than construction and function is discussed in [7] by exploring the dualities Subjectivity/Objectivity, Function/Construction and Black-box/White-box. While construction and function perspectives are characteristic of an isolated system, another perspective must exist to model the relation of that

system with other systems. Let’s designate it by contribution perspective , also named as valuation perspective in [8]. This perspective addressed the relation of a system with systems belonging to its environment, i.e., its stakeholders. We argue that this perspective is not necessarily subjective and can be addressed in an integrated way with the other two. To this end, we aim at combining Information Systems and Enterprise Engineering, which are relatively recent disciplines, with other disciplines that study Enterprises, such as Management and Economics. The latter group incorporates hundreds of years of experience in the form of theories, trial and error exercises and practical cases. These are not necessarily correct nor are necessarily usable in integration with EE, but the opposite is also to be proven true. Therefore, we developed efforts to integrate knowledge from theories about the same object on a common ontology. Particularly, contributions were integrated from Marketing - Service Science and Economics - Value Theory. Methodologically, a selection of the relevant theories about the main concepts identified in [9], service, value and purpose, was followed by relevance and compatibility validation and finally incorporated as mutual restrictions on either side (DEMO and e3Value; DEMO and Service System).

3

A Change of Paradigm - Facing the Market

3.1

The Generic System Development Process

The Generic System Development Process (GSDP), included in DEMO’s theory set, is shown in Fig. 2. Following the overview presented at section 2.3, it begins with the need by a system, the US, of a supporting system, called the OS.

Fig. 2. Generic System Development Process [4] From the white-box model of the US, one determines the functional requirements for the OS (function design), formulated in terms of the construction and operation of the US. Next, specifications for the construction and operation of the OS are devised, in terms of a white-box model (construction design). The US may also provide constructional (non-functional) requirements. Choices are then made with each transition from the top-level white-box model towards the implementation model. However,

nothing is prescribed about the rationale behind these choices. It is clear that system design decisions, either implicit or explicit, remain solely, and certainly not forever, in the minds of the participants in the process. The sheer complexity can quickly cross the limits of human handling or simply enough time passes and the limitations of human memory are exposed. It may then become impossible to know the rationale of past decision, its impacts and dependencies in both today’s scenario and in designing the to-be. Where to start addressing this issue? 3.2

Who is the using system of the B-organization?

We fully agree with DEMO’s application of the distinction axiom, i.e., layered Architecture for B-I-D, in a single organization. But, as it was demonstrated in the example presented at the Problem Statement section, this structure does not include the rationale for having a particular set of actor roles, transactions, and dependencies among them. These concerns clearly belong to the B-organization level. It is not surprising that no support for functional modeling of the B-organization exists, as [5] defines the market as US of the B-organization. Still according to [4], the following classifications applies to systems  an homogeneous system is a system in one system category – which determines the type of elements in a system and their relations;  an heterogeneous system is a layered nesting of homogeneous systems. This seems to imply that the US of the B-organization, the market, is of another system type. However, we must assert that the US is another B-organization. Then, we must wonder: if the US definition applies to heterogeneous systems, why should it not apply to homogeneous systems? Can’t a homogeneous system be treated like a heterogeneous one, operating in layered manner? In fact, it can be shown that a certain ITransaction regarding a system is a B-Transaction of the system supporting it [10]; let us designate this as the relativity principle, and conclude that same reasoning can be applied to the remainder relations. This seems plausible even empirically, as a support process from an organization is, by definition, its provider’s core business. Working on the hypothesis that it should be not limited to heterogeneous system types, our investigation reached the frontier with the market. But what is its system category? Is it not a social system? In fact, using the GSDP for connecting homogeneous systems instead of heterogeneous systems it is a simplification and, therefore, should pose no harm. The only explanation lacking is why one would want to do it. As we have already seen, the GSDP is a structured and conceptually well-defined process for system development – a prime structure for registering the rationale of the design process, step-by-step. However, this process (or a specialization) generally occurs implicitly and (possibly) incompletely, leaving no trace of the rationale besides the memories of the participants in the process. We argue that the B-organization can and should be designed and engineered within the scope of EE and, therefore, propose to apply the GSDP for connecting B-organizations by co-developing US and OS pairs, i.e., develop US and OS as two B systems (see Fig. 3).

B B

I

B

I

D

I

D

D

Fig. 3. Conceptual B-organizations co-development Modeling US and OS as B-organizations, therefore at the same modeling layer, enables recursive application of the GSDP, as further explained in section 5.3. This approach implies a paradigm shift from single versus multiple (yet coherent) systems engineering. In fact, this is what happens in real settings but is hindered by the difficulty that humans have dealing with this kind of complexity in dynamic settings. By providing useful theory and logical instruments over the next sections, we hope to contribute to improving the state of the art.

4

A Simple Market: One Buyer, One Seller

The GSDP was chosen as a reference, because it has articulate and clear primitive concepts that reflect the essential systems development. By providing it with a social setting, relating two social systems begins with a reason to enter an exchange that justifies a relation between two different actor roles. For simplification purposes, let us begin our presentation of the non-functional perspective by analyzing the relation between two systems, designated by S1 and S2. S2 is being developed to support S1; so, in the context of the GSDP they assume the roles of OS and US, respectively. In the next section, we will explore this relation from purely systemic, service, value and teleological perspectives. 4.1

Function

The concept of function has many definitions and different application areas, such as Mathematics and General Systems Theory. The strict notion of function is not subjective - it is related to the notion of observable behavior. As presented in the GSDP, a given construction is made to support a function. The function is, then, dependent on construction. Still according to [4], the function of a concrete system is the set of services it is able to provide. We believe these are distinct concepts; service will be presented next. Continuing, it is said that functional models, characteristic of disciplines such as management and organizational science, are useful for the purpose of using/controlling a system but inadequate for bringing about changes. We agree if they include everything which is not constructional. It need not be so: while the function specifies the system’s relation with elements on its environment, in terms of inputs and outputs, purpose specifies what usage is

given to the system’s function, from a specific external actor’s point of view. Value emerges from the relation: it is attributed to a system function by a stakeholder in regard to a specific purpose. The point must be made that it is important to segregate contribution-oriented notions from function definitions as they have a different nature and positioning regarding a system and its environment. The functional perspective is frequently seen as fuzzy. As we have seen, it is not: questions such as what is a system used for or why was it chosen can and should be formalized - elsewhere! 4.2

Introducing Service

In [11], the concept of service system is introduced, central to both Service Science (SS) [12] and Service-Dominant (SD) logic. It is defined as “a configuration of people, technologies, organization and shared information, able to create value to providers, users and other interested entities, through service”. Service as a process involves using an actor’s resources for the benefit of serving another actor. In SD-Logic, resources are differentiated between 1) operant, which create benefit by acting upon other resources, such as competences and capabilities; and 2) operand, which must be acted on to provide a benefit, such as natural resources and goods. Using the formal definition for a system’s construction, from [4]: 1. only operant resources are part of the composition of a social system; 2. value creation is done through the production of a system towards its environment, through services. A system is a service system if and only if it is possible to initiate a transaction with some agent that (legitimately) assumes the role of provider of the services exposed by that system. In other words, every resource can be part of a service system as long as it contributes to the objectives of the system and there is a person (generally its owner) who brings it into a solution market, thus bringing it to potentially fulfilling the role of operant resource, in SD-Logic terminology. The service concept builds on the function by framing it in transactional semantics, exchanging contract and operation conditions; for instance, defining the conditions for loaning a book in the library – ex: nr. of days, legal dispute forum, cancellation mechanisms, eventual costs for unexpected scenarios such as loss, etc. These combinations could be advertised as part of the function but would it make unnecessarily complex and render it so customized to the particular organization that its offering would probably not be comparable to other solutions. The contributions from Service Science and SD-Logic regarding value are briefly presented in the next section. 4.3

Introducing Value

The same service can be used to different objectives – depending on the solution chain it belongs. The value concept is therefore critical in relating the services provided by a system and a specific stakeholder. It depends on the alternatives available for a given purpose. Value is, therefore, an emergent property from the relation between the function provided by a (support) system and the purpose another system has for

that function, as in SD-Logic’s Foundational Principle 10 [13] Value is always uniquely and phenomenological determined by the beneficiary. We devise our specification of the concept of value from e3Value [14] and DEMO. On one hand, e3Value allows expressing the value context of any DEMO transaction, as a manifestation of purpose; on the other hand, system construction modeling is supported by tracing value-production from e3Value to Coordination/Production Facts/Acts level in DEMO [15]. e3Value is directed towards e-commerce and, as such, embodies concerns about economic viability as restrictions. Particularly, an actor is defined as being perceived by his environment as an economically independent entity. Economical independence refers to the ability of an actor to be profitable after a reasonable period of time, or to increase value for him. Modeling the rationale behind a system’s composition, as the solutions market concept presented in [16] requires a broader modeling scope. Thus, we chose to relax this important restriction of economic independence in the stage of composition's design. The main common concept between DEMO and e3Value is that of a transaction between two actors. The service value concept is based on e3Value by relating the buyer/seller dual-party semantics to DEMO’s US and OS. Actors are the active elements of both social systems and value networks. In DEMO, an actor is a subject fulfilling an actor role in a transaction type. The initiator and executor actor roles are bound by their common interest in bringing about a production result. In e3Value, both actors (provider and requester) are bound by the willingness to share value objects with the concept of reciprocity. The transaction concept represents the relationship between actors by associating value ports of different directions. A unitary DEMO transaction relates to a value exchange in e3Value. A value transaction involves at least two value exchanges, according to the principle of economic reciprocity – fairness of the exchange implies value transmission in both directions. LIBRARY CA01

CA00 T01

Customer

Loan Book

Library Kernel

T02 Payment

Fig. 4. e3Value and DEMO simplified Library Examples In the examples on Fig. 4, it is the Reader’s choice to use the Library to get a Book in exchange for Money. Obviously, there can be alternative solutions to get a Book. The fact that it is a choice is important, as it positions the Customer as a US [4] and, therefore, being the initiator of the transaction. Another association critical to the alignment is between production fact (DEMO’s Transaction Result) and value object’s exchange, as the production of each service transaction determines its effective contribution to the value chains it participates in.

The principle of economic reciprocity makes it necessary for DEMO’s transactions to have a counterpart. Actually, their production fact is related to value object transmission. In the simplified Library example, the requested production facts are:  R01 - book loan (possession of a physical book copy) has started  R02 – book loan was paid (money) For this simple case, it is trivial to relate the production fact and value object. However, it can be hard in the cases where the value-orientation is not present in the transaction definition and it is necessary to make value explicit. For instance, the implicit value objects of R01 and R02 are now explicit, in bold, inside brackets. In e3Value, a value port represents the offer (outbound value port) or demand (inbound value port) of a value object to the environment. Two or more value ports of different directions are grouped in value interfaces. This concept is critical as it represents the willingness of a system to present a demand or offer towards the market. In practice, it specifies the matching of the value interfaces as necessary for engagement. An offer is made effective by the production of a fact by performing a Value Activity. A restriction introduced by DEMO into e3Value is that one must specify which actor roles are authorized to perform coordination acts which correspond to certain value ports. For example, actor role book loaner is authorized to perform promise and state c-acts of T01, which correspond to an outbound value port. Additionally, book loaner also has to be competent to perform the p-act. Decomposing value exchanges down to these primitives explicitly connects the value model of the system with its construction. This decomposition is based on solid actor interaction theory. In summary: function, supported by construction, is exposed as a service in a market through one or more Value Interfaces. DEMO’s transactions correspond to Value Exchanges, which are aggregated in e3Value’s Value Transaction (with economic reciprocity). The main conceptual apports to DEMO are economic reciprocity and value co-generation; the later consists in the notion that value is created by interacting and, therefore, that it is within the scope of a transaction itself, not on good traded by its means – which increases the importance of the production fact semantics. Besides contributing to improve the semantics for value-oriented design, e3Value introduces the concept of chain, which is presented in the next section. 4.4

Introducing Purpose

In order to perform meaningful modeling and reasoning it is essential to establish the purpose as it is the base for designing and engineering the solution providing system. Purpose is: ‘(...) an object or end to be attained; what one intends to do or bring about’, according to the Merriam-Webster dictionary. When applied to systems, it may have two different meanings: one notion of purpose that reflects what it was designed for and other one that reflects what a system is effectively used for. For instance, a cell phone may be used as a flashlight, despite it was originally conceived as a communication device. In fact, as much as two-thirds of mobile phone users claim to do so, according to an inquiry by Sprint [17].

There is, then, an issue regarding balancing design time decisions with unknown usage conditions. The effective usage of a system arises from: 1) the needs and 2) creativity of actors as they procure and assembly solution providing systems to fulfilling those needs. Purpose is commonly considered only in the initial stages of the system, during design and engineering activities. This is contrary to the notion we have just introduced: by freezing design decisions without a structured value structure that is traceable to construction, it becomes hard, if not impossible, to reassess the rationale behind decisions in order to adapt and evolve the system. To tackle purpose modeling, we conceive not a relation between a system and an informal end-user - stakeholder - but a formal relation between two artificial systems. Therefore, modeling purpose brings about the need for considering the application of the GSDP to more than a pair of US/OS system roles, as presented next.

5

Extending the GSDP to System Chains

5.1

Motivation and Example

Exchanging value objects is the main reason two social actors engage and a transaction occurs. The question is how to model it in a uniform way that is reusable regardless of the relative positioning of the system on a chain? We argue that, by modeling each of the elements of a system as an actor role, each respective transaction represents the subsystem’s contribution towards its environment (the original system). This contribution must be valuable; otherwise it should not be part of the overall system. Let us take as an example the Membership Management subsystem of the Library. Its value to the Library system, let us define it as contribution value, is relative to the systems considered. In this case, the Library system uses the Membership Management system and is, in turn, used by a Customer Reader system. These two value framings pertain to two different levels of a valuechain: 1) the value that using Membership Management system has to the Library as a business, and 2) the value that using the Library System has to the Customer Reader. We argue that some of the value generated by the Membership Management system is, or at least should be, an enabler to releasing some kind of value to the systems downstream of the Library System. Therefore, the purpose of a given system element is related to the set of value contributions made downstream in the value chain. 5.2

Formal Concepts

A system chain is an ordered list of systems Si, with value exchanges between consecutive elements. Note that Si-1 is contained in the Environment Si. This definition is recursively applicable; in other words, for any given system Si, its environment is partitioned in both Si-1 and Si+1 – consecutively chaining two US and OS pairs. The set of services a system S can provide to its environment is directly related to what we designate as the Using System Set (USS). The USS of S is the set of systems

that are initiators of transactions of which S is executor. Therefore, the USS fulfills the demand role for S and S fulfills the offer role. For instance, the USS for the Library can be a customer loaning books and a retailer using the Library’s physical space for promoting a book. In turn, for S to deliver its services, it fulfills the demand role in relation with another set of systems which offer the services needed by S – its Object System Set (OSS). In this case, S assumes the role of demand and its OSS assumes the role of offer. For instance, an OSS of S can be a publisher and the owner of the Library’s physical space. A very interesting application of formally defining purpose of a system is that it can be (re)used for modeling the relation between a system and the elements that compose it. We argue that any given complex system can be decomposed into more granular systems: if a single element is part of a system’s composition, then it is necessarily connected by means of the system’s structure to other elements; therefore, these connections must represent the element’s contribution to the production of the system. Formally, a single element of a system is also a system (a sub-system of the original system), with a composition constituted by a single element, an environment formed by the other elements in the original system and a structure linking the element to the environment, as depicted in Fig. 5.

Composition of SN Environment of SN Not a part of SN

Fig. 5. The construction of a system - US/OS dualities and subsystem analysis We are now in position of completing the purpose definition. We argue that if we trace a system’s purpose recursively through the solution chain as function/construction pairs, the last one will be a function / black-box. Philosophically, if absolute truth is not attainable, these chains will end in the meaning of life (i.e., the last why) - traceable to the root of human intentions. Exposing those intentions, even with only partial objectivity will assist in modeling the associated systems. Therefore, we would like to add to the formal system definition from [4]: A production as the fact pertaining the contribution it makes to the production of the original system – its purpose, relative to that chain. One must wonder, if the contribution cannot be specified, then what is the reason for being part of the composition?

5.3

The System Within – Relativity & Recursion

The previous reasoning is rooted in two notions: 1) relativity and 2) recursion. The first one, relativity, because a given systems' white-box may be a black-box (or a set of black-boxes) in another referential of system types, e.g., the white-box model of a car still holds the chemical system of a battery as a black-box. Following the same reasoning, and having finer thresholds between system types, this reasoning can be applied to refine a given overall system model into layers. These layers can model MN relations between systems, e.g., the car can use a battery, solar power and gas as energy providing (sub)systems. Therefore, they end up forming a layered solution chain where the uppermost layers are dependent on the lower ones. Recursion regards the definition of the contribution of each (sub)system element to their main system (which is their US), and is related to the process of engineering these relations. In this way of reasoning, recursive applications of the GSDP would happen, positioning the father system as US and each subsystem as OS. This means rejecting a large, compiled white-box as a model for complex systems. They should instead be modeled as successive implementation levels (implying explicit solution choices), from problem to implementation of a solution, instead of a single effort of engineering - which will result in "hardcoded" implementation and loss of intermediate modeling elements and constructs. Still elaborating on the inputs of SD-Logic and e3Value, we note that in DEMO only operant resources are modeled, because the composition is entirely made up of actor roles; this way, the atomic service system concept from SD-Logic [11] is compliant with this definition. Therefore, modeling purpose as the contribution of a given system’s production to its environment (which is populated by neighboring nodes forming a value network) is a very powerful teleological concept that can be incorporated in SD-Logic conceptualizations. This repositions the issue of addressing the functional perspective from a mere “outside world” problem (which would even so be relevant) to a very relevant system engineering problem: representing components as economically independent parts of a solution. Furthermore, our proposal regarding the level of atomicity of system elements is a step further from the service system conception, by deliberately assuming an economically-independent perspective between producer and consumer and associating a person (actor role) to each component. This is especially differentiating as an approach for otherwise dismissed chains of technological components, such as software applications and infrastructure. This way, one has to make value exchanges explicit and objectively define themes which are generally found on a services contract, i.e., responsibility, assumptions, performance criteria, etc., effectively working at both service and value layers. Continuing on the Library example, let’s assume that managing the risk of non-return may be performed by an economically independent system, such as an external insurance company. Then, the value of insuring a book must be specified in order to setup the value exchange. This is a significant change from assuming the internal subsystem addressing that concern as it makes necessary to specify, for instance, how much of the original book value at loan initiation time can be recovered and how long after a book is assumed to be lost can the value be recov-

ered. This specification is necessary for scoping the service demand which is to be placed in the market. Clearly, it is also insightful for analyzing internal alternatives for addressing the same concern. In this way, this explicitation contributes to preparing to answer change events by developing system components more prepared to be swapped according to the offer. Obviously, there will be diminishing returns on modeling every component down to the nuts and bolts level in this aspect but, for a theory to be considered sound, such capability must exist if there is a case for doing so. This improved specification is justified by the fact that the network of enterprises collaborating in runtime cannot be assumed to be known upfront and, therefore, models should offer increased support for loose coupling from the business perspective.

6

Conclusion

Current EE state of the art approaches, particularly DEMO, are limited concerning non-constructional perspectives. We propose addressing this issue by:    

Distinguishing functional and contribution perspectives; Improving their objectivity by defining a set of concepts and their relations, namely function, value, and purpose; Integrating teleological and ontological system development by framing it in a value exchange context – introducing the concept of market, defining the relation between value interfaces and the constructional perspective; Defining the rationale of system development choices in terms of valuation of solutions in a market context, by recursively defining purpose of a system as its contribution to a specific chain.

We are confident that these concepts are very relevant since they can be reiterated at any system/sub-system relation, either at pure business level, business/ICT interface or inside complex ICT systems. The abstraction and flexibility enabled by the recursive application are especially relevant in ICT-intensive environments, as the access to components usable as pieces of a solution chain is increased by maturing technological advances, such as services based on the Cloud paradigm [18]. In conclusion, true alignment between business and its supporting systems can only be effectively pursued when in possession of a conceptual theory, together with the corresponding methodologies and applications, which integrate both the contribution, function and construction perspectives of a system. The contribution perspective must be clearly addressed by the EE discipline to improve its relevance in connecting to other disciplines, particularly Management, Marketing and Economics, only to name a few which directly address business modeling. Introducing Enterprise Engineering is a critical step towards bridging the gap between strategy and its implementation.

References 1. Kaplan, R.S. and D.P. Norton, Strategy Maps : Converting Intangible Assets Into Tangible Outcomes. 2004, Boston, Mass.: Harvard Business School Press. 2. Laudon, K.C. and J.P. Laudon, Management Information Systems: Managing the Digital Firm: Prentice Hall. 3. Dietz, J.L.G. Enterprise Engineering Manifesto. 2011 [cited 2012 January 24th]; Available from: http://www.ciaonetwork.org/publications/EEManifesto.pdf. 4. Dietz, J.L.G., Enterprise Ontology: Theory and Methodology. 2006: Springer. 5. Dietz, J.L.G., ed. Architecture - Building strategy into design. Academic Service, ed. N.A. Forum. 2008, Sdu Uitgevers. 6. Regev, G. and A. Wegmann, Where do Goals Come from: the Underlying Principles of Goal-Oriented Requirements Engineering, in 13th IEEE International Requirements Engineering Conference (RE’05). 2005, IEEE: Paris, France. 7. Op ’t Land, M. and J. Pombinho. Strengthening the Foundations Underlying the Enterprise Engineering Manifesto. in 2nd Enterprise Engineering Working Conference. 2012 (forthcoming). Delft, The Netherlands: Springer. 8. Op ’t Land, M., et al., Enterprise Architecture – Creating Value by Informed Governance. The Enterprise Engineering Series. 2009, Berlin, Germany: Springer. 9. Pombinho, J. and J. Tribolet, Service System Design and Engineering – A value-oriented approach based on DEMO, in 3rd International Conference on Exploring Service Science. 2012: Geneva. 10. Bardaa, P.J., On the relativity of enterprises – Essential DEMO Modelling for SOA. 2009. 11. Maglio, P.P., et al., The service system is the basic abstraction of the service science. Information Systems and E Business Management, 2009. 12. Lusch, R.F., S.L. Vargo, and G. Wessel, Toward a conceptual foundation for service science: Contributions from service-dominant logic. IBM Systems Journal, 2008. 47(1). 13. Vargo, S.L., R.F. Lusch, and M.A. Akaka, Advancing Service Science with ServiceDominant Logic: Clarifications and Conceptual Development, in Handbook of Service Science. 2010, Springer. 14. Gordijn, J., E. Yu, and B.v.d. Raadt, e-Service Design Using i* and e3value Modeling. IEEE Software, 2006. 23: p. 26-33. 15. Pombinho, J. and J. Tribolet, Modeling the Value of a System’s Production – Matching DEMO and e3Value, in 6th International Workshop on Value Modeling and Business Ontology. 2012: Vienna, Austria. 16. Pombinho, J. and J. Tribolet, Issues and Challenges in Dynamic Systems Design and Engineering - A Value-Oriented Approach, in 6th SIKS Conference on Enterprise Information Systems, SIKS, Editor. 2011: Delft. 17. Tsai, A. Sprint Survey Reveals 56% of Phone Users Do More than Talk. 2006 [cited 2012 26/02]; Available from: http://www.mobiledia.com/news/43052.html. 18. Smith, D.M., et al., Predicts 2011: Cloud Computing Is Still at the Peak of Inflated Expectations. 2010, Gartner.