This paper addresses one part of business and IT-alignment by proposing a method to align goal models and business models. The method takes as input a goal model and a business model, and outputs a business model that is aligned with the explicit goals of a business actor. The method builds on previous work with the same approach but extends that work in at least two ways: the syntax of some method constituents is altered and a way to combine them is introduced. The result is an improved method that better support a modeller when designing business models based on goal models.
Generally, the raison-d’Œtre of ICT in an organization is to support the organization’s business goals and this is often materialized as IT-systems for support of operational processes. The goals should therefore be made so explicit that supporting IT-systems can be aligned with them. A problem then is how to formulate business goals so that the alignment can be made. One solution approach is to utilize models that focus on dierent aspects of an organization and its collaborations. Addressing the problem then amounts to aligning a chain of models.
A common view is that goal models are used in the earliest phases of business and information systems design, where they help in clarifying interests, intentions, and strategies of dierent stakeholders answering to the why of the business. Business models give a high level view of the activities taking place in and between organizations by identifying agents, resources and the exchange of resources between the agents. So, a business model focuses on the what of a business. Process models focus on the how of a business, as they deal with operational and procedural aspects of business communication, including control ow, data ow and message passing.
The purpose of this paper is to present a method for addressing one part of the problem of aligning the IT-resources with the goals of an organization the alignment of goal models and business models. The method approach is to use templates for formulating goals and apply rules for business model transformations. The method builds on work presented in [1]. As that work outlined the method on a high level a research question was how to make it more formalised. This work extends previous work in several ways, most notably in the amount of formalism used. In this paper we illustrate the extended method in a case application making use of two well known modelling techniques; for goal modeling we use i? [2] and for business modelling we use e 3value [3].
The amount of research and literature pointing out the importance of business and IT alignment is vast. Notable examples of approaches for alignment through model use can be found in [4], [5], and [6].
This paper is structured as follows: the method is presented in section 2. An illustration of the method by its application on a small case is in section 3. Finally, the concluding section 4 contains a discussion of the results and directions for future research. 2
A Method for Goal and Business Model Alignment A common problem in goal modelling is that goals are dicult to formulate, i.e., the formulations of goals often become loose, highly abstract and unfocused. In [7], the authors argue that goal models become unfocused because goals range from the value propositions of an enterprise to general goals of economic sustainability. However, largely all means in goal models (a means is an action carried out to attain a goal) relate to the acquisition, production, maintenance, or provisioning of economic resources. As mentioned in section 1, business models describe the use and exchange of resources that are of economic value for agents participating in collaborations. We exploit this relation between means and business model notions when formulating the following method for goal model and business model alignment. 2.1
The method, originally introduced in [1] but here substantially extended, takes as input an as-is business model and a to-be goal model and produces a new to-be business model conforming to the goal model.
The method has two main steps, where the rst concerns goal modeling and the second concerns business modeling. In the rst step, it is the responsibility of a goal modeler to construct a goal model using business model notions; in particular the means are formulated according to a template structure (see Sect. 2.2). In the second step, it is the responsibility of a business modeler to make use of the means supplied by the goal modeler by applying transformation rules to a business model. If the business modeller do not have required information to apply a rule, then this information must be elicited in order to continue. The method can be outlined as: 1. The goal modeler constructs a goal model using the means templates.
For each means template, there will be exactly one transformation rule telling how means of this template will inuence the to-be business model. The means templates can be categorized into three main groups based on their eects on the to-be model: templates leading to the introduction of new business model components, templates leading to the deletion of certain business model components, and templates requiring changes at the process level (see Sect. 1). While the rst two groups have a visible eect on the to-be business model, the eects of the means in the third group is not visible in this model but will only have impact on a process model. 2.2
A means template is formulated according to the following grammar: MEANS_TEMPLATE ::= COMPULSORY_PART | COMPULSORY_PART ’[’ OPTIONAL_PART ’]’ COMPULSORY_PART ::= ’< ’ event ’, ’ resource ’, ’ DIRECTION ’,’ A_OR_CE ’> ’ DIRECTION ::= ’from’ | ’to’ | ’in’ A_OR_CE ::= agent | value activity OPTIONAL_PART ::= E E ::= E ’AND ’ T | T | COMPULSORY_PART T ::= T ’XOR ’ F | F | COMPULSORY_PART F ::= other_event value_activity | other_event resource ’,’
DIRECTION ’,’ A_OR_CE | ’( ’ E ’) ’ | COMPULSORY_PART The compulsory part of a template 3 is represented by a 4-tuple <Event,Resource,DIRECTION,Agent> . This part may be followed by an optional part providing complementary information about the consequences of the compulsory part. In the compulsory part, DIRECTION indicates the direction of an event, thus enabling us to distinguish between dierent situations (e.g. a resource moving from or to an agent). Notice also that the COMPULSORY_PART introduces the possibility to combine templates. 2.3
The following list of nine templates follows the list proposed in [1]. It covers goals
related to the acquisition, production, maintenance, or provisioning of resources
for a business actor.
3 In this paper the notation Ti is the abbreviation for Template number i
1. <start offering, resourcej , to, customeri > [(start using
existing value activityk XOR start producing resourcej in value activityk XOR start
procuring resourcel from providerp) AND receive compensation from customeri]
Template 1 is used to express an exchange of an economic resource between
agents. The main part represents the oering of the resource. There are three
possible consequences in this template and they appear before the exchange
showing the origin of the resource that is exchanged:
(
[(stop procuring resourcel from providerp XOR stop producing resourcej in value
activityk)]
Template 2 is used when an agent desires to stop oering a resource to another
agent. The two possible (mutually exclusive) consequences are:
(
After that, the main actor provides a compensation to that agent.
[(stop oering resourcel to customeri) XOR (start producing resourcej in value
activityk)]
Template 4 focuses on stopping the acquisition of a resource from an agent. There
are two possible consequences (mutually exclusive). The rst of is to consider
whether the agent stops procuring from all of its providers or not.
(
5. <start producing, resourcej , in, value activity k> [start oering resourcej, to, customeri] Template 5 shows the consequences of starting the production of a resource in a value activity. The only eect is that the main actor must oer the resource to other agent(s).
6. <stop producing, resourcej, in, value activityk>
[(start procuring resourcej from providerp) XOR (stop oering
customeri)]
Template 6 shows the consequences when an agent stops the production of a
resource in one of its value activities. There are two mutually exclusive
consequences:
(
7a. <increase fraction of production of, resourcej, in, value activityk> 7b. <decrease fraction of production of, resourcej, in, value activityk > Template 7 is to increase (7a) or decrease (7b) the capacity of the production of a resource. According to [1], this template and template 8 has normally no structural eects on the business model.
8. <insource fraction of production of, resourcej, in, value
activityk>
[(start producing resourcej in value activityk XOR increase production of resourcej
in value activityk) AND (stop procuring resourcej from outsourcero)]
Template 8 shows what is happening when the production of a resource from
a value activity is insourced. There are two possible consequences (mutually
exclusive):
(
9. <outsource fraction of production of, resourcej, in, value
activityk>
[(stop producing resourcej in value activityk XOR decrease fraction of production
of resourcej) AND start procuring resourcej from outsourcero]
Template 9 captures the consequence of an outsource of production. An
outsource is leading to:
(
In both cases, the main actor must start procuring the resource.
One transformation rule is associated with each template. A rule has two parts called the primary and the secondary action. The primary action is related to the compulsory part of the template. The secondary action is related to the optional part of the template. When applied, both parts of the rule aect the design of the business model.
The elements of the secondary action are either possible precursors of an event (i.e., what is needed to enable the event in a compulsory part of a template), or the possible consequences (i.e., what is done after a compulsary event). In other words, elements of the secondary action can both trigger or be triggered by events.
For space reasons we present here the rule that is associated with the 1 st template and omit the rules associated with templates 29. Table 1 gives the rule associated to the template 1:
Primary action: (a) IF actor customer i is not present THEN add the actor customer i. (b) Add one value exchange for resource j (in an existing or new interface) from the principal actor to customer i.
Secondary action: (c) Add a new value exchange from customer i to the principal actor (as compensation for the resource j oered by the principal actor).
Connect the new value exchanges to an existing or new value activity of resourcej within the customer i. (d) IF start using THEN connect to the existing value activity k
to the new value exchange. (e) ELSE IF start producing THEN call T5 and apply associated rule.
= { T5.resourcej /T1.resourcej , T5.value activity k/T1.value activity k } (f) ELSE IF start procuring THEN
IF Prev(T5) THEN connect value activity k to the value exchange of resource j.
Call T3 and apply associated rule. ={T3.resourcej/T1.resourcel, T3.providerp /T1.providerp,
T3.value activity k/T1.value activity k}
It is important to notice that templates may be combined with other templates. We also say that a template may call another template. For example, the template matching with the oering of a resource is able to call the template responsible for the production of the resource to oer. In the rules, a function Prev(P i) has been introduced to avoid the possible issues of redundant changes. For example, if a rule says that an actor should be introduced, then the function Prev(P i) is used to ensure that, in case templates are combined, the actor is not introduced twice.
Variables in templates are substituted before application analogously to how substitutions are carried out in Prolog [8]. For a better readability, the method distinguishes the initial substitution ( i) from those done when an additional template in a rule ( i) is called.
The calls (or combinations) between the templates can be represented within a tree for better visualization. While traversing the tree, the rules are modifying the as-is business model. Arriving at the right-most leaf of the tree (the nal node), the as-is business model will be completely transformed and will be aligned with the goal model. Figure 1 shows an example of a substitution tree. Consistency checking of combinations of templates is important. In an automated process, the matching templates found by the goal modeler in the to-be goal model have to be consistent. For instance, a business modeler must not declare a <stop offering, resource, to, agent > without a previous <start offering, resource, to, agent >.
In order to address consistency the notion of scheduling conditions is introduced. A scheduling condition is an expression of a particular combination of templates on which precondition must be checked to ensure its legality. A list of such conditions is highly context dependent. For instance, one combination may be allowed in one organization, while the same combination in another organization is forbidden. It is, however, interesting to sketch out and give an example of how one such listing can be done.
A scheduling condition has two parts. The rst part is the combination part represented by two template symbols together with an inx composition operator . This operator is used to express that a particular template can be combined with another. The second part is the conditional which contains a guard expression. Following is an example list of scheduling conditions. The rst item, for example, express that template 2 can be combined with template 1 when the resource of T1 is equal to the resource of T2 and the agent of T1 is equal to the agent of T2.
Ti T2 T4 T6 T7a T7b T8
Tj T1 T3 T5 T9
T1.resource=T2.resource and T1.agent=T2.agent T3.resource=T4.resource and T3.agent=T4.agent T5.resource=T6.resource and T5.value activity=T6.value activity production(T7a.resource) 100% production(T7b.resource) 0%
T9.resource=T8.resource and T5.value=T6.agent
The scheduling conditions may be organized and visualized in an implication array (Fig. 2). Template names are on the vertical and horizontal axes of the array. Implication dependencies are indicated by putting a symbol in the intersecting cell of a template column and row. Three symbols are used to indicate the implication direction 4. A square indicate that the direction is from vertical to horizontal, a diamond from horizontal to vertical, and a bullet for a combination of both directions.
When drawing the array, two kinds of call between templates can be written: the explicit or the implicit calls. The explicit calls are highlighted in grey scale in the array. They regroup calls to some templates made from a rule associate 4 The implication symbols are chosen to allow for gray-scale printing: ; ; . to another template. For instance, the rule associated to T4 can call T2 and T5. For these explicit combinations, there is no need of scheduling rules because the calls are made from inside the rule and ensure in this way, the satisfaction of the precondition. For implicit calls, scheduling rules with preconditions need to be considered. In the implication array three implicit calls has been added and highlighted.
A link from the start to the stop (because it is only possible to stop something that has been started before) ( ).
A link between increase from decrease (in both directions) ( ).
A link from outsource to insource (because it is only possible to insource something that has been outsourced before) ( ).
Notice that a,c,e, and f are not templates but other_events as mentioned in the BNF grammar and that the implications between those events are informal. We call those implications informal as they are merely for expressing implications in a language more natural to use. An analysis of the links between the templates is interesting because it makes it possible to avoid redundant changes on the tobe business model within the templates, thanks to the Prev(Ti) function. 3
In this section we illustrate the method by applying it in a small case study (adapted from [1]). Due to space constraints it is not possible to show all models. We will, however, detail four templates matched with the means of a to-be goal model, one application of a rule associated with one of those templates, and the nal output. 3.1
The case involves a Massive Multiplayer Online Gaming (MMOG) provider as the main actor. In this kind of game, thousands of players can participate via Internet and compete with each other. Two other actors interact with the MMOG provider: an Internet Service Provider (ISP) playing the role of a business associate, and the players as its customers. The MMOG provider has mainly two responsibilities: producing the game content by itself and distributing the game client application on CDs. Thanks to the ISP, the MMOG provider can distribute the information needed to play via the Internet. The revenue model for the MMOG company is based on fees collected to get access to the game server. This payment gives the right to access to the game. Obviously, the players need to be connected to the Internet in order to play.
For future development of its business the MMOG provider plans to change its goals and add new activities to support them: 1. Easier distribution of CDs by outsourcing the production of CD delivery to a shipper. 2. Reduction of its cost of content creation by outsourcing 50% of the game content creation to users. 3. Reduction of story boarding cost by procuring game stories from customers. 4. Increase the number of users by oering free trial games. 3.2
To apply the method the goal modeller rst has to draw the to-be goal model by introducing the changes into an as-is goal model. In the new goal model, new means are highlighted, matched, and formulated according to the means templates. After that, the rules associated to these templates are applied on the as-is business model to produce an aligned to-be business model as output. To-Be Goal Model Figure 3 represents the to-be goal model of the MMOG company. This goal model was the as-is model that, when updated, became the to-be goal model. Eight new elements have been highlighted by rectangles. Four of them are means (hexagonal) and four are so called soft goals (rounded rectangle).
New Means in the To-Be Goal Model From the MMOG provider’s as-is goal model complemented with new goals according to the listing in the case description, we got the to-be goal model (Fig.3). Four new means are identied:
Thanks to the usage of -substitutions, those means can match with some templates. The substitutions will have as eect instantiation of the terms: value activityk, resourcej , . . . . The means 1, 2, 3, and 4 are respectively matched with the templates 9, 3, 9, and 1. The matching can be done thanks to substitutions chosen by the business modeler: 1={fraction/100%, resource j/CD delivery, value activity k/transport CD, outsourcer o/shipper} 2={resourcej/innovative game stories, provider p/customer, value activity k/create content, compensation/payment} 3={fraction/50%, resource j/game content, value_activity k/create content, outsourcer o/Customer} 4={resourcej/free trial game, customer i/customer, value activity k/distribute game, compensation/attention}
Table 2 shows the 9 th template and the substitution matching with the 1 st means. 9. <outsource fraction of production of, resourcej, in, value activityk> [stop producing resourcej in value activityk AND start procuring resourcej from outsourcero]
={fraction/100%, resource j/CD delivery, value activity k/transport CD, outsourcero/shipper }
Application of Rules Four rules associated with the means templates highlighted in the to-be goal model are used to transform the as-is business model into an aligned business model. Due to space constraints, only the rule associated the 9th template is presented here. Also, to save space, only the applied part of the rule is included in the following listing. In reality more rules than this one should be applied (one rule for each template). Alignment of Means 1 (application of template 9 and its associated rule) 9. <outsource 100% of production of, CD delivery, in, Transport CD > [stop producing CD delivery in Transport CD AND start procuring CD delivery from Shipper ] Primary action: a. IF actor Shipper not present THEN create actor Shipper.
Secondary action: b. IF ((stop production) AND (outsourcing = 100%)) THEN call T6 and apply part (a) and (b) of associated rule
= {T6.value activity k/Transport CD,T6.resource j/CD delivery} d. Call T3 and apply associated rule
= {T3.resourcej/CD delivery,T3.provider p/Shipper, T3.value activity k/Distribute content}
6. <stop producing, CD delivery, in, Transport CD > [(start procuring resourcej from providerp) XOR (stop offering resourcej to customeri)] Primary action: a. Delete the duality with the value exchange from the Transport CD concerning the CD delivery within the principal actor. b. IF CD delivery is the only value object produced in the Transport CD THEN delete the Transport CD
3. <start procuring, CD delivery, from, Shipper > [(start using CD delivery in Distribute content ) AND (start providing Payment to Shipper )] Primary action: a. IF actor Shipper is not present THEN add the actor Shipper. b. Add a new value exchange for the CD delivery from Shipper to the principal actor. Secondary action: c. Add a new value exchange from the principal actor to the Shipper (as Payment for the CD delivery oered by the Shipper ).
Connect the new value exchanges to an existing or new value activity of CD Delivery within the Shipper d. IF start using THEN connect the new value exchanges of CD delivery to the existing Distribute content activity.
The chain of templates called for the transformation of the as-is business model can be visualized as a tree. The rst level represents the templates related to the new means templates indicated in the to-be goal model. The tree is then traversed in a pre-order walk: rst the parent is visited and then the left child before the right child. Figure 4 shows the tree with each template called. Output: The To-Be Business Model Figure 5 represents the business model of the MMOG provider that is aligned with the to-be goal model. The gure is the as-is business model 5 where some transformations have been done by applying transformation rules. Newly added constructs in the model have been highlighted in the gure. The detailed example of a rule application resulted in the introduction of a new actor (Shipper) and constructs related to it. 5 Notice that the as-is business model is omitted due to space restriction.
In this paper we have addressed one part of the problem of business and IT alignment. We have done so by proposing a method that aims at aligning goal models and business models. The method takes as input a goal model and a business model, and outputs a business model that is aligned with the explicit goals of a business actor. The method builds on previous work presented in [1] and the benets of that method still applies; clear and uniform goal formulations, wellfounded business model design, and a high level of traceability. But this work extends the previous method in at least two ways. First, the syntax of both the the means templates and the rules was claried resulting in better methodological support through reduced ambiguity. Second, combining templates to an arbitrary level is now possible. This enables a modeller to express whole chains of actions (or scenarios) that aect the design of business models.
Future research include investigations about the completeness of both the set of templates and the set of rules. For instance, as presented one template is always associated with one rule. This is very convenient as it constrains a modeller to arrive at only a small number of end results. It may, however, be that this is overly constraining and that more options should be open for the modeller. Another direction for future research is the proposed implication array. This array expresses the legal (or illegal) combinations of templates paving the way for consistency checking in the method. In order to do this checking the nature of the combinations must be understood. Some implications are always true, but some are true only in special cases. For instance, for a particular organization one combination of templates may be allowed while for another the combination is forbidden.