Chapter 1 Introduction

Chapter 2 Business Model Ontology Refinement and Visualization

This chapter has two parts, the first part covers the refinement work which was done to BMO, and the second part takes an overview at available tools to represent visual models like the BMO.

2.1 Business Model Ontology Refinement

Refinement of the model was done between the first and the second prototype but since the model is introduced here, it is a good opportunity to explain the choices applied to the model during the development of the application.

Since BMO’s definition in the thesis of A.Osterwalder in 2004 , the BMO has been used and adapted in different versions (figure 2.1 (a.)). These changes are mainly due to the usages made of the model, notably by Y.Pigneur for the e-Business course at HEC Lausanne (figure 2.1 (b.)) and by A.Osterwalder for his activity with Arvetica in the private banking sector (figure 2.1 (c.)). As can be seen on figure 2.1 (d.) the terminology as well as the position of the elements has changed. Links have sometimes become arrows even if the meaning is still bidirectional. The detailed attributes that were define for each element in the thesis have somewhat bean put aside. This is mainly explained through the usage which is only putting the title of each element on a sticky note and then assigning it to one of the nine blocks.

Figure 2.1 illustrates four distinct version of the BMO. Subfigure 2.1 (a.) is the initial canvas proposed by Osterwalder in his thesis. It defines not only the blocks but also instances of each block and has two additional blocks actor and profit. Subfigure 2.1 (b.) shows another layout of the initial canvas and has already dropped the special blocks. This presentation which is closer to the strategy map visualization is used vertically to allow for alignment with the IT infrastructure. Subfigure 2.1 (c.) simplifies the initial canvas and changes the wording of the block to be more non-technical. The introduction of arrows can also be observed pointing all from the left to the right. Subfigure 2.1 (d.) expands on subfigure 2.1 (c.) but has the position of the blocks changed to have more symmetry between the left and right hand sides.

(a.) Initial version [ Osterwalder, 2004]

(b.) e-Business version [ Pigneur, 2007]]

(c.) Simplified [ Osterwalder, 2008a]

(d.) Latest version [ Osterwalder, 2008b]
Figure 2.1: Variations of Business Model Ontology visualizations

To facilitate development with clear defined objects and their attributes, a meeting was held together with Y.Pigneur and A.Osterwalder to define these conventions. The result can be observed in figure 2.2 and the attributes are listed in the next section.

For the current position of the blocks the last version used by A.Osterwalder was chosen, mainly due to the fact of the nice symmetry it provides between the left side and right side. Another argument in favour of moving the position of the partner network is that more and more businesses enfasis the importance of partnerships over internal resources, especially in the service area. As for the terminology the choice was also to use the publicly tested wording and the one that will be available in the future book. Only the central block is a bit of a dilemma. If the user is business savvy offer could be replaced by the more precise name value proposition.

As stated before, links are all bidirectional never the less we decided to draw arrows to help with the naming of the relation. Except links connecting to cost and revenue, every link has a unique verb that can be used to identify it and its direction, or inverted to follow the link into the other direction.

During this session an idea was to test if arrows could be used to simulate either the flow of the product or the flow of money or even highlight the central role of the value proposition / offer. But as can be seen in figures 2.3 or 2.4 this syntax overloads the model and does not provide a strong additional value. Therefore, the naming of links was principally intended to be used internally, if identification is required.

2.1.1 Decided Terminology for this Project

A business model has four perspectives (offer, client, activity and financial). Each perspective regroups one or more blocks. There are nine blocks or building blocks in a business model. An element is one instance of a block; it represents a sticky note of the physical BMO method. An element can have different details depending of the building block he is in.

All elements share the name and optional description property. In addition, here is the list of properties that has been decided to be kept or added to the original definition of the model.

  • Partner Networks: none or perhaps partner importance
  • Key Activities: none
  • Key Resources: ResourceType defined as TANGIBLE, INTANGIBLE, HUMAN, FINANCIAL, OTHER
  • Cost Structure: costSum, percentage
    priceLevel defined as FREE, ECONOMY, MARKET, HIGH_END
  • Client Segments: criterions or personas
  • Client Relationships: relationshipType defined as ACQUISITION, RETENTION, ADDON_SELLING, AUTOMATION
    priceLevel defined as FREE, ECONOMY, MARKET, HIGH_END
  • Distribution Channel: priceLevel defined as FREE, ECONOMY, MARKET, HIGH_END

2.1.2 Assisted Construction

Another aspect of the model used in the developed application is the construction sequence proposed in the draft from Osterwalder, A. (2007) ’How to Describe and Improve your Business Model to Compete Better’.


  1. Client Segment (Customer)
  2. Offer (Value proposition)
  3. Distribution Channel (Channel)
  4. Client Relationships (Relationships)
  5. Revenu Flows (Revenu)
  6. Key Resources (Capability)
  7. Key Activities (Value Configuration)
  8. Partner Network (Partner/Partnerships)
  9. Cost Structure (Cost)

This sequence and the additional questions which are proposed in the mentioned document have been taken and used to create what will be called the wizard mode.

Figure 2.2: BMO with financial links

Figure 2.3: BMO with links centered on offer

Figure 2.4: BMO with activity links

2.2 BMO and Other Visual Modelling Tools

Until now BMO was mainly applied as brainstorming tool on paper or on whiteboard in combination with sticky notes. The primary users are Arvetica and HEC Lausanne, but due to the simplicity, the powerful expressiveness, the fact that the model is free and mainly the good evangelism job done by its creator, Alexander Osterwalder, on his web site and talks. The model attracts more and more users, enough that different individuals have created or intent to create a support application for it. Although none of the current versions seem to be a good replacement for the paper based interaction.

The simple prototype that is available on the web (figure 2.5), is more a proof of concept than a real application and for now focuses only on imitating the sticky notes in a virtual form.

Figure 2.5: Simple web prototype

Figure 2.6: IBM prototype in Microsoft Visio™

Another version is done internally by IBM and use Microsoft Visio™ as platform (figure.2.6). This allows storing more information than the paper based version, but comes with the burden of a generic modelling tool like Visio™. Meaning, the user has to be proficient with the program and moving or creating links between the elements or even adding information can sometimes be complicated for a non-technical user.

Figure 2.7: Sticky note BMO on a wall (Arvetica)

Figure 2.8: BMO Amazon in PowerPoint™

From the original thesis of the BMO there is also an owl file available which can be edited with programs like Protégé. Sadly, as with the Visio™solution the visual representation is very abstract and even if all the information and links are present and browsable, it is hard to get an overview picture of the model. Protégé also being a generic Ontology editor has too many unused options which clutter the interface for the novice user.

Digital versions of the paper based BMO are either captured with a photograph or recreated on a PowerPoint™ presentation. Figure 2.7 illustrates a normal paper based workshop session and figure 2.8 shows the final PowerPoint™ output after tedious work of transcribing and aligning shapes. An application that can recorded and help create the model directly in a digital form is certainly useful, but must not be a burden or take away the brainstorming capabilities provided by the paper based version. Naturally an electronic version will be a bit slower or a bit less forgiving than simply working with the physical artefacts. Therefore, the application should provide other benefits to justify its usage over the traditional way. Before turning to the requirements of such an application, here is an overview of other models and their digital applications in comparison. See table 2.1 and 2.2 for comparison and figure 2.9 for screen captures.

Table 2.1: Overview of desktop applications
Application Main Model Pros Cons
Sticky notes generic fast, can be used everywhere, low tech hard to share, lack of interactive filtering, no additional properties for storing information
PowerPoint™ generic somewhat digital version of sticky note, limited skill necessary model agnostic, editing, no properties
Visio™ generic and specific (with templates) Relations and properties can be defined made for developers, no view mode
Protégé Ontology editor powerful, simple for ontology’s hard for users without knowledge of ontology
Consideo-modeler complete workflow end to end solution from design to simulation Specific to its workflow, knowledge of the application and the workflow required
StrategyMap StrategyMap Guide through the steps knowledge of the application and the model required
MindManager MindMap Flexible way to represent information for some information too loose representation
Table 2.2: Overview of web applications
Web application Main Model Pros Cons
MindMap,,, MindMap Same as desktop version, easy sharing No real-time collaboration
Lombardi BluePrint Process process outlining, web based and collaborative, intuitive hosted service
Figure 2.9: Screenshots of applications mentionned in the overview

Strategy Map (a.)

Lombardi BluePrint (b.)

Protégé (c.)

[MindManager (d.)

Consideo-modeler (e.)

Consideo-modeler (f.)

From this quick, very shallow, overview of applications that digitally support in one way or another a model, we can see some common observations.

Generic applications need specific knowledge to identify the right tools to be used and sometimes lack the visual forms to accurately represent the model. As for the specific applications designed to support their specific model, they have the visual representation but are too often not very user-friendly. This can be explained by the fact that they are geared towards the experts and try to have options for every variation allowed by the model.

Web technologies have evolved enough to allow applications to be created for the web and therefore facilitate collaboration and sharing, as shows the example of Lombardi BluePrint or the many online MindMap services.

As a small experience reproducing a BMO model in a mindmap (see figure 2.9 (d.)), shows the information can be represented and there are possibilities to add comments and move elements easily form one topic to the other, but the relationships and the structure of the BMO does not really emerge.

The corollary of this small overview is that for our application there has to be a compromise between complexity and usability. A novice user has to be able to create his business model as easily as on paper and the prototype has still to have enough advanced options to allow experts to do more than with a digital capture of a paper version.

Chapter 3 Design of The Prototype

tm/chapter2.txt · Dernière modification: d-m-Y H:i de boris = chi`s home Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0