Lidia López, Xavier Franch: Applying Business Strategy Models in Organizations. 7th i* Int. Workshop held at CAiSE 2014. Paper at http://ceur-ws.org/Vol-1157/paper6.pdf.
Abstract. Increasing adoption of Open Source Software (OSS) in information system engineering has led to the emergence of different OSS business strategies that affect and shape organizations’ business models. In order to obtain the specific organizational model for a concrete organization that is adhering to a specific OSS business strategy, we need to instantiate the general knowledge included in this business strategy. This paper describe the process in which this general knowledge is instantiated and define a set of operations over i* models to implement the instantiation concept. Although conceived in the field of OSS, the approach is generalizable to any kind of business strategy.
Tech Tuesday - Mastering Time Management Unlock the Power of OnePlan's Timesh...
Applying Business Strategy Models in Organizations
1. Lidia Lopez, Xavier Franch
Applying Business Strategy Models in
Organizations
2. Agenda
Introduction
OSS Business Strategy Models
OSS Business Strategies applied to Organizations
Conclusions and Future Work
2
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
3. Introduction
Business Model: the way to create value and achieve
revenues
Business Goals
Business Strategy: how a company competes in a
given market
Business Strategy is the way to achieve Business Goals
Goal: Business Model goals evaluation
i* to conciliate both
3
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
8. Other OSS Strategies
Creating a new OSS Project
– From scratch: Initiative, Release
– From an existing: Fork
Controlling an existing OSS Project: Take over
8
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
13. Instantiating OSS Acquisition Model
13
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
14. Instantiation Operations
Rename Actor
Rename Intentional Element
Rename Dependum
Choose alternatives
Refine Intentional Element
14
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
15. Tool Support
Iterative process
– Look for annotated elements
– Instantiate elements
iStarML
– No new elements
– New properties for the models elements
• Question
• Operation
15
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
17. Conclusions
i* for business models & strategies aspects
5 Instantiation operations
– Renaming elements (3)
– Choosing alternatives (1)
– Refining model adding new elements (1)
i* models annotated: Operation & Question
17
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
18. Future Work
Validating operations (RISCOSS Use Cases)
Review instantiation operations
– Choosing subtasks
– Merge models
Matching operation (organization & business)
18
Applying Business Strategy Models in Organizations.
i* Workshop, 15-16 June 2014.
19. Lidia López – llopez@essi.upc.edu
www.essi.upc.edu/~gessi
@gessi_upc
Thank you
Notas del editor
First I’m going to give you a short introduction in order to understand the motivation of our work.
Then, I will introduce our work presenting you a set of business strategy models
After that, the main contribution of this work is how these business strategy models can be applied to the Organizational model in a concrete Company
I will finish this presentation making some conclusions about our ongoing work and some future work
To start the presentation I need to define what a Business model is: Business models describes the way that a Company creates value and achieves revenues. Concretely, it includes the organization business goals.
On the other side, we have business strategies, that describes the approach the Company has to adopt in order to compete in a given market. So, the business strategy includes the tasks and resources needed to achive the Business Goals included in the business Model.
Having as a main goal the evaluation of the achievement of the Business Goals in a certain organization, we need to conciliate both information in te same model. We decide using i* modeling language because i* allows describing both kind of information and we can take advantage of the exisiting evaluation mechanisms to achive our goal of evaluating the Business Goals.
To ilustrate the idea of combining business strategy and business models I’m going to use the set of business strategies that we have defined in the context of the European Project RISCOSS.
RISCOSS is defined to give risk assesment to companies that are adopting open source software. These strategies focus on the way how the Company is involved in the OSS Project that produces this OSS, we have defined a set of business strategies. We have modeled these strategies using i*
The strategy that requires less involment is what we named OSS Acquisition. The Company “takes” the component from the OSS Community and do not give anything in return
Integration is an strategy that requires a little more involvement than acquisition.
In this case, we can see that there is also dependencies from the communty to the Company, not only otherwise. For example, in this case the Company should provide bug reports, patches and new features requests.
Other strategies are defined for the case of the need of creating a new OSS Project (initiative or release if the OSS Project does not exist and fork for existing ones), in these cases the business strategy models include the task and subtask create OSS Project and Community.
Or when the Company need to take over the evolution of an exisiting OSS Project including some management taks
In these strategy models we found:
2 strategic actors for the business model: OSS Community and the Adopter company
Some dependencies between both actors.
In the Adopter SR diagram there are:
the high-level business goals (from the Business Model): Benefit from co-creation, OSS evolves toward Desired Features and OSS involvement
And the low-level goals and tasks that correspond to the concrete OSS business strategy requirements. In this case:
Acquiring some skills: user, technical and management
Contribute to the community: bug reports and patches
The requirements affect to the high-level goals in some way: in this case contributing OSS helps to the OSS involvement needed if the company wants that the component evolves to its desired features
One characteristic of these business strategy models is that they are generic models containing some alternatives that cannot be applicable to all the organizations. For example:
How the component is going to be used (deployed as is or integrated in other software)
What kind of contribution the organization is willing to make, only reporting bugs or providing some patches
This “generic” feature arise the necessity of instantiating these “generic” models when a business strategy is being applied to a concrete organization
In order to ilustrate this instantiation process, I’m going to use a mini example…
The Business Model for the Company Acme contains the goals and tasks related to develop and maintain its product “Road Runner Locator”.
In order to reduce costs, to know where the Road Runner is, the Company decides not to implement the Geographical Information System that its product needs. For this example, the Company decides to Acquire an OSS GIS Component.
After including all the elements from the OSS Acquisiton Strategy model to the Acme’s business model we can appreciate that:
Some elements have been included as decomposition of the task Acquire GIS OSS Component
There is also a new actor (the OSS Community) and some dependencies related to it
In order to adapt the OSS Acquisition model, this model has been annotated, pointing out which elements need some shapes to be correctly included in the Acme’s business model.
In this example we see 3 kinds of shapings:
RENAME: some elements need to be “named” properly: the acquired component and the community that produce it
CHOOSE: some alternatives has to be decided: the component is going to be deployed or inegrated in other software
REFINE: if the software is going to be integrated, some other elements should be included
In order to apply these instantiation operations, the modeler needs to give some feedback. The elements, besides the operation to be applied, are annotated with a question that the modeler needs to answer
This model shows the instantiation after the elements OSS component and community are renamed and the alternative “integration” is choosen
This model needs more instantiation, at this point the elements coming from the “integrate in Software Artifact” model should be included in the organizational model in the same way that the Acquisition business model had been included previously.
The process ends when there is no more annotated elements.
To sum up, we have define the following instantiation operations
As part of the validation, we have implemented a library (in the context of the RISCOSS product) that included 2 the functionalities:
The first one that looks for annotated elments and retrieves the questions to be answered to shape these elements
And the one that, using the answers, shape the model and looks for the more annotated elements.
This tool uses iStarML to represent the i* models
These annotations are included as new properties for the already defined tags:
The operation to be applied
The question to be answered in order to applied the operation
I’m concluding, summarising the main results presenting by the paper:
We have used i* models for describing business models and business strategies
We have defined 5 instantiation operations
We have used some annotations in the i* model elements in order to identify over which elements these operations has to be applied
From now on, we need to:
validate the operations modeling the RISCOSS Project use cases
complete the set of operations, for now we have explore the necessity of operations for choosing subtasks and merging models
Include some matching operation in order to suggest the best business strategy depending on the organization business model.