Jan 20-21, 2005Weiss and Amyot, MCETECH 051 Designing and Evolving Business Models with the User Requirements Notation Michael Weiss (Carleton University) and Daniel Amyot (University of Ottawa)

Jan 20-21, 2005Weiss and Amyot, MCETECH 052 Motivation Companies need to constantly adjust their business models to changes in their environment However, companies have investments in existing business processes that need to be preserved What is needed is a lightweight approach for evaluating business model alternatives that helps mitigate the risks that come with changes We propose that the User Requirements Notation (URN) meets these needs

Jan 20-21, 2005Weiss and Amyot, MCETECH 053 Business Process Modeling Structured method for describing and analyzing opportunities for improving the business objectives of multiple stakeholders (definition of roles and of activities that contribute to business goals) Business Process Software Architecture Business Model Stakeholders

Jan 20-21, 2005Weiss and Amyot, MCETECH 054 User Requirements Notation URN is a semi-formal, lightweight method for modeling and analysis of user requirements in the form of goals and scenarios Combines two existing notations –Goal-oriented Requirements Language (GRL) –Use Case Map (UCM) Emerging standard for reactive systems, with particular focus on telecommunications However, URN is also applicable to BPM –Weiss, Amyot: Business Process Modeling with URN. To appear in: IJEBR, 2005

Jan 20-21, 2005Weiss and Amyot, MCETECH 055 Goal-oriented Requirements Language Goals describe the objectives a system should achieve: why do an activity? Towards a higher, strategic level of modeling the current or future system and environment –Focus is very much on system evolution –Can explore opportunities and vulnerabilities

Jan 20-21, 2005Weiss and Amyot, MCETECH 056 Use Case Map UCMs model scenarios as causal flows of responsibilities that can be superimposed on underlying structures of components –What should this activity be precisely? Who is involved in this activity? Where/when perform the activity? Different structures suggested by alternatives in a GRL model can be evaluated by allocating responsibilties to UCM components components responsibilities

Jan 20-21, 2005Weiss and Amyot, MCETECH 057 Case Study Our case study is based on the Web Service Interoperability Organization (WS-I) example of a simple supply chain management system Actors –Consumers, Retailers, Warehouses, and Manufacturers Use cases and assumptions –Retailer offers electronic goods to Consumers –Retailer must manage stocks in Warehouses. –Retailer must restock a good from their respective Manufacturer's inventory, if the stock level …

Jan 20-21, 2005Weiss and Amyot, MCETECH 058 Our Objectives Given a set of business goals and informal requirements as a starting point –Explore links between goals and scenarios –Transform to linear scenarios to improve our understanding of the system (MSCs) –Then we will focus on business model design –Explore evolution of the business model We will name the existing business strategy: Sell to stock via warehouse and retailer –Code: R

Jan 20-21, 2005Weiss and Amyot, MCETECH 059 GRL Actor Diagram: R Strategy Actors Dependencies Goal model associated with an actor

Jan 20-21, 2005Weiss and Amyot, MCETECH 0510 UCM Model for Business Process (R) Agent: actor Team: role the actor plays

Jan 20-21, 2005Weiss and Amyot, MCETECH 0511 Links between GRL and UCMs GRL goals and softgoals can be refined into high- level tasks, which are usually mapped into –UCM responsibilities –UCM submap (plug-in) –UCM scenario definitions GRL actors can be refined into UCM components Traceable rationale for the scenarios and their responsibilities, explaining why they exist GRL models also enable analysts to link business or system goals to architectural alternatives –UCM component structures Also, document the rationale for a particular choice

Jan 20-21, 2005Weiss and Amyot, MCETECH 0512 Business Model Evolution Same scenario can be used to describe different business models and reason about them Consider strategic options available to a manufacturer who currently sells to stock These are actions that result in changing either one or both of the existing preconditions for the R strategy: –Small market share and Standardized product Exploring those options leads to several possible evolutions of the business model

Jan 20-21, 2005Weiss and Amyot, MCETECH 0513 Evolutionary Stages Evolution by application of strategies: differentiate product or increase market share R CompuSmart Micro Warehouse W Sam’s Club Converge WR Ingram Micro MicroAge MW Micron M Dell Gateway W assembles final product Standardized product M assembles product

Jan 20-21, 2005Weiss and Amyot, MCETECH 0514 GRL Actor Diagram: M Strategy

Jan 20-21, 2005Weiss and Amyot, MCETECH 0515 Alternative Architectures (1/2) Warehouse InventoryManagement Warehouse InventoryManagement:W Retailer OrderProcessing Retailer OrderProcessing:R Manufacturer Production Warehouse:M Manufacturer Production:M Warehouse:M Consumer a) CURRENT: Sell to stock via warehouse and retailer (R) b) Sell to stock via warehouse (W) Consumer Warehouse InventoryManagement:W Warehouse InventoryManagement:W Manufacturer OrderProcessing:W Production:M Warehouse:M

Jan 20-21, 2005Weiss and Amyot, MCETECH 0516 Alternative Architectures (2/2) Consumer InventoryManagement:M Warehouse:M OrderProcessing:M Production:M Manufacturer InventoryManagement:M Warehouse:M OrderProcessing:M Production:M d) Sell direct to consumer with internal warehouse (M) Consumer Warehouse InventoryManagement:W Warehouse InventoryManagement:W Manufacturer OrderProcessing:M Production:M c) Sell direct to consumer with external warehouse (MW) Warehouse:M

Jan 20-21, 2005Weiss and Amyot, MCETECH 0517 GRL Rationale Diagram Low Risk

Jan 20-21, 2005Weiss and Amyot, MCETECH 0518 Discussion Measure of success is achievement of two high-level goals: High Profitability and Low Risk Rationale diagram captures the preconditions of each business model alternative (M or R here) Not all companies will be able to evolve their business models as rapidly as they wish The rationale diagram indicates a key obstacle to evolving quickly: conflict with existing channels Advantage for new entrants over incumbents

Jan 20-21, 2005Weiss and Amyot, MCETECH 0519 UCM Maps for Business Process (M)

Jan 20-21, 2005Weiss and Amyot, MCETECH 0520 Scenario Analysis of R and M Strategies

Jan 20-21, 2005Weiss and Amyot, MCETECH 0521 Conclusion With URN we can model and analyse a business process at different levels of formality (goals, scenarios) One scenario can be used to describe different business models and to reason about them –Based on the separation of the definition of a scenario from its allocation to components in UCMs Basis for incremental business model evolution –GRL goal models enable the selection of appropriate architectures and help make the decision regarding the suitability of evolution Future work: linking goals and scenarios, research on value exchanges, business model patterns, business process composition, test generation.