Applying Business Strategy Models in Organizations

608 views

Published on

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.

Published in: Software, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
608
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • Applying Business Strategy Models in Organizations

    1. 1. Lidia Lopez, Xavier Franch Applying Business Strategy Models in Organizations
    2. 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. 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.
    4. 4. OSS STRATEGY MODELS
    5. 5. OSS Adoption Strategies  Context: RISCOSS Europan Project –Risks assesment for OSS Adoption  Modeling OSS involvement 5 Applying Business Strategy Models in Organizations. i* Workshop, 15-16 June 2014.
    6. 6. OSS Acquisition 6 Applying Business Strategy Models in Organizations. i* Workshop, 15-16 June 2014.
    7. 7. OSS Integration 7 Applying Business Strategy Models in Organizations. i* Workshop, 15-16 June 2014.
    8. 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.
    9. 9. Modeling OSS strategies Strategic actors Strategic dependencies High-level goals Strategy requirements 9 Applying Business Strategy Models in Organizations. i* Workshop, 15-16 June 2014.
    10. 10. INSTANTIATING OSS BUSINESS MODELS
    11. 11. Organizational Model 11 Applying Business Strategy Models in Organizations. i* Workshop, 15-16 June 2014.
    12. 12. Applying OSS Acquisition 12 Applying Business Strategy Models in Organizations. i* Workshop, 15-16 June 2014.
    13. 13. Instantiating OSS Acquisition Model 13 Applying Business Strategy Models in Organizations. i* Workshop, 15-16 June 2014.
    14. 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. 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.
    16. 16. CONCLUSIONS FUTURE WORK
    17. 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. 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. 19. Lidia López – llopez@essi.upc.edu www.essi.upc.edu/~gessi @gessi_upc Thank you

    ×