Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 1

Designing and Evolving Business Models with theUser Requirements Notation

Michael Weiss (Carleton University)

and

Daniel Amyot (University of Ottawa)

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 2

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, 2005 Weiss and Amyot, MCETECH 05 3

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 ProcessBusiness Process

Software ArchitectureSoftware Architecture

BusinessBusiness Model Model

StakeholdersStakeholders

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 4

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, 2005 Weiss and Amyot, MCETECH 05 5

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 andvulnerabilities

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 6

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, 2005 Weiss and Amyot, MCETECH 05 7

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, 2005 Weiss and Amyot, MCETECH 05 8

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, 2005 Weiss and Amyot, MCETECH 05 9

GRL Actor Diagram: R Strategy

Actors

DependenciesGoal modelassociated withan actor

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 10

UCM Model for Business Process (R)Agent: actor

Team: role theactor plays

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 11

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, 2005 Weiss and Amyot, MCETECH 05 12

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, 2005 Weiss and Amyot, MCETECH 05 13

Evolutionary Stages• Evolution by application of strategies:

differentiate product or increase market share

RCompuSmart

Micro Warehouse

WSam’s ClubConverge

WRIngram Micro

MicroAge

MWMicron

MDell

Gateway

W assembles final product

W assembles final product

Standardized product

M assembles product

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 14

GRL Actor Diagram: M Strategy

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 15

Alternative Architectures (1/2)Warehouse

InventoryManagement

Warehouse

InventoryManagement:W

Retailer

OrderProcessing

Retailer

OrderProcessing:R

Manufacturer

ProductionWarehouse:M

Manufacturer

Production:MWarehouse:M

ConsumerConsumer

a) CURRENT: Sell to stock via warehouse and retailer (R)

b) Sell to stock via warehouse (W)

ConsumerConsumer Warehouse

InventoryManagement:W

Warehouse

InventoryManagement:W

Manufacturer

OrderProcessing:W

Production:M

Warehouse:MWarehouse:M

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 16

Alternative Architectures (2/2)

Consumer

InventoryManagement:MWarehouse:M

OrderProcessing:M

Production:M

Manufacturer

InventoryManagement:MWarehouse:M

OrderProcessing:M

Production:M

d) Sell direct to consumer with internal warehouse (M)

ConsumerConsumer 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, 2005 Weiss and Amyot, MCETECH 05 17

GRL Rationale DiagramLowRisk

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 18

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, 2005 Weiss and Amyot, MCETECH 05 19

UCM Maps for Business Process (M)

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 20

Scenario Analysis of R and M Strategies

Jan 20-21, 2005 Weiss and Amyot, MCETECH 05 21

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.