The EA Metamodel behind the Business Model Generation

Back when Alexander Osterwalder was first working on the book “Business Model Generation,” I reached out to him to see if I could discuss the data elements he had chartered for his “Business Model Canvas.”  After all, from an Enterprise Architecture standpoint, he was making some pretty problematic assumptions, and missing some key opportunities, with respect to aligning to an established body of practice that he was probably unaware of.  The response, at the time, was basically: “I’m busy with the book… contact me later.” 

As an author myself, I know how difficult it is to change course on core elements of your idea, and collaborate, when you are half-way done with writing a book based on a dissertation that was completed over a year before.  So, I backed off.  I figured he would publish a dry, boring book on business models, like all the other dry, boring books on business strategy, and then I could contact him to work on an update for the next edition.

Little did I know how smart Alexander Osterwalder really is.  Boy did I underestimate this guy!  First off, he didn’t publish a dry tome on business models.   He published a very accessible and exciting book with rich graphical design.  Secondly, he involved a long list of folks, in a very public way, to contribute to the core ideas, giving him both credibility and momentum.  The result: his book has become the cornerstone of a small-but-energetic movement. 

Alas, the core problems that he started out with, when he was first working on his Ph.D. thesis, are still there.  He didn’t have the architectural input he needed in the beginning when creating the ontology, and his work has been a little “out of sync” with good metamodeling practices ever since.  As a result, when it comes time to connect his research to a larger body of emerging work, we have some challenges. 

To whit, at the Open Group EA Practitioners Conference in San Francisco (31-Jan-2012), I was discussing the notion of business models with a tool vendor whose tools are Archimate compliant and allow for flexible metamodels.  He had no metamodel for the Business Model Generation work.  Why?  Because no one had published a reasonable translation of the BMGEN ideas into Enterprise Architecture.  Similarly, when reviewing the VDML (Value Delivery Modeling Language) metamodel that is being proposed within the Object Management Group as an approach to business modeling, there is no good connection between the business model work of Osterwalder and the evolving work on value streams, capability modeling, and process improvement that forms the cornerstone of the VDML approach.

Time to fix this.  This post will attempt to describe the metamodel that I created for Osterwalder’s BMGEN when I was working to integrate his ideas into the Enterprise Business Motivation Model.  Note that I created this metamodel originally in 2009, and updated it in 2011 through collaboration with the Business Architecture Guild.  I have NOT had a conversation with Dr. Osterwalder on this topic yet. 

What is a Business Model

According to Osterwalder, the definition of a business model is this: “A business model describes the rationale of how an organization creates, delivers, and captures value.”  And further: “A business model can best be described through nine basic building blocks that show the logic of how a company intends to make money.”  Still further, “The business model is like a blueprint for a strategy to be implemented through organization structures, processes, and systems.”

The nine “building blocks” referenced by Osterwalder are:

1. Customer Segments
2. Value Propositions
3. Channels
4. Customer Relationships
5. Revenue Streams
6. Key Resources
7. Key Activities
8. Key Partnerships
9. Cost Structure

Osterwalder goes on to describe a simple visual mechanism for capturing these elements, which he calls the “Business Model Canvas.”  It is a simple table that can be captured on one page that allows the elements of the model to be easily elicited in a one-day business model workshop.  The following image was captured directly from the web site “businessmodelgeneration.com” and represents the Business Model Canvas.

The Business Model Canvas and it’s conceptual information model

There are a great many clues in the BMGEN book about the conceptual model implied by these elements.  Unfortunately, these clues are somewhat inconsistent.  We will do the best we can. 

From the definition above, it appears that a business model is described through these nine building blocks.  In information model terms, we would say that a business model is a composition of these nine elements.

However, when we look at the relationships between the elements, it is not always clear.  For example, in the conceptual model, key resources are “assets required to offer and deliver the previous business elements.”  Unfortunately, the “previous business elements” includes about half the elements.  Also, cost structure (singular) is the result of the other elements.  This makes for a rather odd conceptual model, that doesn’t look much like the model that Osterwalder himself proposed in his thesis.   In the model below, the green boxes are the nine elements.  The red elements are described in the text as subtypes but not modeled. The yellow boxes are referred to by the elements, but are never actually captured in Osterwalder’s Business Model Canvas.   Unfortunately, one of these elements is the Voice of the Customer (VOC)!  Another is the organization itself.  Should these elements be excluded?

The model that I derived from reading the book is as follows (click on the image to enlarge).

The model above represents the relationships between concepts captured in a single two-page spread in the book Business Model Generation that introduces the Business Model Canvas.  This model is wildly complex and needs to be rationalized.  I will walk through the process that I followed to rationalize this model.

Rationalization phase 1: Fixing the Relationships

In this step, we will look for missing elements, add actual relationships that were not captured in the text, and then remove transitive elements that remain.

Step 1: Look for Missing Elements

For each relationship, look to make sure that it makes sense from an abstraction standpoint.  There are two gaps that jump out of the model above.

First is the relationship between value proposition and organization.  According to the model above, there is a one-to-many relationship between organization and value proposition: one organization can have more than one value proposition.  This is true, but modeling it is problematic.  Organizations actually have relationships with every single element, not just value propositions.  Every element is part of the business model.  We know, from simple observation, that most organizations have more than one business model.  But the concept of the business model itself is not on the diagram.  So we will create the concept of a business model and INCLUDE every element on the diagram.  The organization will relate to the business model (one to many).  This addresses the problem.

The second gap in Osterwalder’s model is that he describes a value proposition, but not a product or service.  In other words, the business is valuable, but we never model the product or service that we are going to deliver in order to make it valuable.  Huge Mistake.  Probably the biggest flaw in the Business Model Canvas.

(Note: the diagram below includes the results of all three steps of rationalization phase 1.  Please refer to it for the following two steps as well. Click the image to see it at full size.)

Step 2: Look for Missing Relationships

In the original model, there were a number of relationships to cost structure, but there were very few relationships to revenue streams.  These seem like parallel concepts.  So I considered the different elements that should impact revenue just as much as they impact cost structure.  First off, if key activities and key partnerships impact the costs, why would they not impact revenue?  Clearly, activities of the organization will impact revenue as well as cost.  Similarly, the partnerships clearly impact revenue just as they impact costs.  (Note that the Osterwalder canvas does not distinguish between supply chain partners and sales partners.  They are all just partners).

Some of the additional relationships added:

• Channels target segments.  For sales and distribution channels, we are targeting specific customer segments. 
• Key activities impact revenue streams
• Key partnerships result in revenue streams

In the model above, added relationships are marked in red.

Step 3: Remove Transitive Relationships

A transitive relationship is one that makes sense to a person, but doesn’t make sense in an information model.  A transitive relationship is derived from an intermediary, and more correctly implied through other relationships.  For example, the text indicates that customer relationships result in the cost structure.  However, it is not the customer relationship itself that drives costs, but the resources required to maintain it.  Therefore, the relationship, in the model, between customer relationship and cost structure is transitive.  We can safely drop it.

Also, the relationship between segments and resources is transitive.  Each segment requires resources, of course, but it does so because of the customer relationships demanded for those segments.  This is also a transitive relationship.

In addition, with the addition of the "missing” relationship between channels and revenue streams, there is no need for the transitive relationship from value proposition to revenue stream.  Clearly, the revenue stream is realized through channels. 

Rationalization Phase 2: Simplify Modeling

When rationalizing a metamodel, it is important to consider the result.  What are you going to do with the metamodel?  Metamodels are used to define how the elements of a model work together.  In effect, you are describing a language.   The terms of the metamodel are like the parts of speech of a language.  They can relate with one another in specific ways, but they describe the structure of the language, not it’s content. 

That said, the more terms that we add to a metamodel, the more complex our resulting models will be.  As a metaphor, if you want your language only to have simple sentences, reduce the number of parts of speech.  If there were no adverbs, consider how much simpler our sentences would be.  On the other hand, you never want to simplify your language so much that it cannot convey the ideas you need it to convey. 

If the English language were stripped of adverbs, we would lose the ability to say things like:

Shall I compare thee to a summer's day?
Thou art more lovely and more temperate:
Rough winds do shake the darling buds of May,
And summer's lease hath all too short a date…

   (William Shakespeare, Sonnet 18)

So we have to have as many parts of speech as we need, but no more and no less.  (Or to quote Einstein: Make everything as simple as possible, but not simpler.)

To make our model simple, we need to look for places where we have two (or more) entities where one will do.  After all, an adverb can modify a verb and another adverb.  We could have had two different “parts of speech” there (one for modifying verbs and another for modifying other adverbs) but that would have made it difficult to use the concept of an adverb to analyze sentences.  Similarly, if we have two concepts that "overlap” or can be simplified down to one, we should do it for the sake of making simpler models.

How do we know when two metamodel entities need to be simplified to one?  When both entities have the same relationships with surrounding objects.  Specifically, entities A and B can be combined into a new entity AB if every relationship between A and [C, D, E,…] is matched, one for one, with a relationship between B and [C, D, E, …].  What does that look like? 

The model above is the same as the previous one except that I simply hid the elements that I did not want to illustrate, and moved things around for effect.  By doing this, it is pretty clear that the relationships between “revenue streams” and all if its neighbors is parallel to the relationships between “cost structure” and it’s neighbors.  Therefore, while it is perfectly appropriate (and in fact useful) to capture these as different “things” on a business model canvas, I maintain that they should be modeled as one object: Cost and Revenue Model. 

There is one more opportunity for simplification.  The notion of customer relationship and customer problem or need.  This may very well be a problem of my own making as Osterwalder’s model doesn’t have a “customer problem” element, so it is entirely possible that he meant to include that concept in the “customer relationship” area.  The “duplication model” for the customer area looks like this.

Combining customer relationship and customer need into a generalization of “Customer Demands and Relationship” provides the last change in this phase of the rationalization process.  Note that once these changes were made, the link from Value proposition to Customer is now transitive through the new element, so it is dropped.  The model, at this point in time, looks like this:

Also, for the sake of modeling simplicity, you may notice in this model that I dropped the subtypes for “channels.”  When metamodeling, it is a good idea to avoid subtypes that are simply lists of example types with no distinct relationships of their own.  The exception to that rule would be to illustrate the fact that a term commonly used in business literature is, in fact, a subtype of some other generalization.  (an example would be the term “Strategy” which is a subtype of “Driver” in the full EBMM).

You may also note from the model above that act of “generalizing” the concepts of Cost structure and Revenue streams into a single object required me to generalize their relationships as well.  Therefore, when we used to say that a channel “results in” a revenue stream, we can now say that a channel “drives” both revenue and cost models. 

I also removed, from this view, the organization object.  That relationship sits at a higher layer.

Rationalization Phase 3: Aligning to Architectural Terminology

All this work was simply an analysis of the model on its own terms.  However, terms already exist for these items, and the field of Enterprise Architecture is honing in on many of them.  If we don’t recognize the common terms that already exist in industry, then we will have a difficult time integrating the Osterwalder Business Model with anything else.  I am aware that Dr. Osterwalder read, and cited, a great deal of literature in developing his original ontology.  However, the literature that he read, and cited, came to him from academic and research papers.  It did not come to him from practical business discussions.  There are very few things I am certain of, but one thing I can state with certainty: most business people don’t give a flip about the terminology in academic papers. 

Terminology matters.  If we mean the same thing, but use different terms, then we will get confused when speaking with one another.  This is the primary reason that biologists, chemists and physicians around the world have agreed on names that are shared even across language and culture boundaries.  Enterprise Architecture is not there yet, but we should at least agree among the authors within the English language about two different words that apply to the same concept.

That said, we also have to be careful.  Specifically, in this effort, I considered using the term “business capability” to use in place of “key activity.”  For one thing, the point of a “key activity” is to describe those actions that are demanded by the business model to be performed by the business (as opposed to one of the partners).  In other words, it is not an outsourced activity.  For that reason, a business capability (which includes the notions of “process", “information”, and “role”) is a very close parallel.  Unfortunately, in business architecture, the concept of a business capability plays a very specific role in the planning process.  It is needed in an overall business architecture model in a very specific and rigorous way. 

One of the basic rules of metamodeling, derived from information architecture, is to minimize or eliminate situations where a single term appears twice in the same model.  I knew that the “capability” term needed to exist as part of the relationship between “business initiative”, “business process”, and “business application.”  Therefore, I really couldn’t use that term again as part of the business model package.   That said, the concept of a “key activity” is too limited for business modeling.  We are doing more than capturing activities.  We are capturing the need to be able to perform an activity, along with all the underlying information, processes, and systems that it will require.  As a compromise, I chose the term “Required Competency” to capture the meaning of this element.

In addition, the business model canvas uses plural terms, where models should always use singular terms since the notion of plurality is assumed through the act of modeling.  (This is derived from information architecture principles).

One major variation added at this point is the renaming of “Key Partnerships” to two elements: “Business Partners” and “Partner Type.”  This change is mirrored on the customer side by renaming “Customer segments” as “Customer Types”.  This parallel naming convention is designed to allow us to use the same metaphor (“a type of thing”) for both partners and customers.  The notion of segment is not often used when referring to partners.  In addition, the notion of a “key partnership” assumes that we will capture the instance of the partnership (e.g. a partnership with Amazon.com) instead of the TYPE of the partnership (e.g. partnership with an online retailer). 

For a  business architect to use the business model to perform analysis, it is helpful to break these two concepts apart.  For example, if we say that “amazon.com” is a key partner, we may be happy.  On the other hand, if we say that “amazon.com” is a key partner, of type “online retailer,” we may ask ourselves if we should develop partnerships with other retailers.  After all, a partner type with only one partner could be considered a “single point of failure” for the business model.  By separating these concepts, weaknesses like this one are easier to spot.

Other naming issues were not so difficult. 

Osterwalder’s name	EBMM Name	Reason for variance
Key Resources	Resource / Asset	Strategy literature often refers to assets or required assets.  Added the synonym.
Key Partnerships	Partner Type	see above
Customer Segment	Customer Type	see above
Key Activities	Required Competency	see above

Final changes in this phase involve two changes in relationships, both as transitive. 

• With the change of “Key Activities” to “Required Competencies” we changed the scope of the entity.  It now includes not only activities but also the information and systems needed to deliver the value proposition.  Therefore, the relationship between value proposition and “key resources” is moved become a relationship between value proposition and “required competency.” 
   
• The relationship of “channels require key resources” is true, but is now no longer interesting at the level of abstraction of the model.  With the gradual changes like “customer type” and “partner type”, the level of abstraction of the entire business model has been rising.  The business model elements can now describe a business model in an organization that has many business models, some of which share partners, customers, and resources with each other.  This is a typical situation in most organizations.  However, in order for an organization to develop a channel, key people will have to understand how EVERY other element is impacted.  This is also true of customer types, partner types, products, etc.  At a very detailed level, everything impacts everything.  So this model consciously and intentionally excludes relationships that are simply “not interesting” from the viewpoint of analysis, innovation, and improvement.  For this reason, this relationship is dropped.
   

Rationalization Phase 4: Aligning to Architectural Frameworks

The most important framework, from an ontological sense, is the Zachman Framework.  John Zachman, recognizing the importance of his seminal work on the definition of metamodels, even renamed his work “The Enterprise Ontology.”  While there is some debate about whether the Zachman framework is useful without methods, there is no debate about its importance in Enterprise Architecture.  All other metamodels produced to date have made an attempt to describe the differences and similarities that they have with the Zachman Framework.

Therefore, I took the time to examine the new Business Model mechanism and compare it with the Zachman Framework and noticed that the element of “Location” is simply missing from Osterwalder’s canvas.  For the purpose of developing the core concepts of a business model, it may not be needed, and it is therefore defensible.  However, from the standpoint of analysis for weaknesses and opportunities, or for examining the impacts of Porter’s Five Forces on the model, it is essential that we add in the location elements. 

The final evolution of the Business Model area in the Enterprise Business Motivation Model (v3.8) is:

 

Integrating into a larger model – the EBMM

In the Enterprise Business Motivation Model, there are twelve core elements.  They are illustrated in the following view.

As you can see from this view, the Business Model is one of the core elements.  A business model is treated, at the top level, as a single entity.  All of the work that we have done in this effort was to rationalize the components of the business model.   Effectively, I was creating an understanding of how the business model elements themselves relate to one another.  However, NONE of them relate to other entities in the Enterprise Business Motivation Model.  The reason for this is simple: no company ever implements their business model.

I will say that again.  No company ever implements their business model.  Not directly, anyway.

Why?  Because a business model is just a model.  It is not reality.  It is a gross generalization of “how things should work.”  It reflects the intent of the owners, but not the reality of the business.  There is always a gap between where the business actually is, and where the business model says that the business should be.   This is a good thing and sometimes a bad thing.

The positive aspect of this is that the owners of the company can change the business model readily, and then ask the organization to change to follow suit.  In doing so, the owners are like the captain on a large ship telling the pilot to take a particular heading.  The captain doesn’t turn the ship.  The pilot does, and the ship doesn’t turn right away… it takes time.  The course taken by a large vessel in the open ocean is “approximately” the same as the planned course (on a good day), but is rarely exactly the same.  The same applies for business as well.  The business model is a high level abstraction that indicates the intent of the owners, not the implementation of the organization.

The negative aspect is that the implementation of a business model may wander, over time, to be quite different than the intent of the owners.  This is especially true when new products or services are introduced, but the owners do NOT take the time to consider the impact on the overall business model.  As a result, the implementation (the business itself) may be quite a bit less efficient, elegant, and effective than the business model would imply.  The assessment of the business model, in the EBMM, is a way to capture both the difference between the intent and the reality, and the difference between the intent and the needs of a dynamic marketplace.

Relating Business Models to other Business Architecture Elements

As you can see from the core elements diagram above, the concept of a business model is CENTRAL to the Enterprise Business Motivation Model.  This is not true of any other metamodels in use today.  This renders most of those metamodels problematic at best, including Archimate, VDML, Essential, and TRAK.  The need to align to strategy is simply incomplete without the concept of a business model.

Why do we need the concept of a business model in order to align initiatives to business strategies?

Because, in large organizations, there is no such thing as a single strategy.  It is perfectly valid to create an overall performance goal, but strategies, described at the level of the enterprise, apply unequally to each of the business models within the enterprise.  In fact, it is quite normal for a CEO to announce a series of “strategies” for the entire enterprise that, when examined in detail, are actually contradicted within the context of one of the business models within that enterprise.

For example, I was taking a long look at Air New Zealand recently.  This is an airline in the “low cost airline” model, largely owned by the New Zealand government.  In my analysis, I found NINE different business models at play in Air New Zealand.  Not one, or two, or three.  Nine different business models.  (This is not particularly surprising to me.  My examination of Microsoft uncovered more than twenty business models). 

The performance goal, set by the CEO, is to improve profitability of the airline by more than $195M (NZD) per annum by FY15.  That is a very well articulated goal.  Hats off to the CEO. 

However, the strategies described do not apply equally to all nine business models.  The strategies that I gleaned from the Interim Report for 2012 include very important elements like “reducing fuel costs” and “innovation on loyalty products.”  However, one of the business models of Air New Zealand is an airline training academy where pilots, mechanics, and ground crew can learn their jobs.  Those strategies apply to the core businesses (passenger and cargo) but not to the training business.  This is normal and expected.  (Please don’t construe my words as a criticism of ANZ.  I have never seen an annual report that provided the strategies for anything OTHER than the business models that provide the lion’s share of the business revenue.)

Therefore, when a business architect is working within the organization, trying to align the initiative to strategy, it is imperative to know WHICH STRATEGIES APPLY.  If you don’t capture the business model as an element in your business architecture, you cannot map strategies to business models to know which initiatives are actually well aligned (to their business model) vs. initiatives that are poorly aligned and should be scrapped.

Don’t be fooled.  Failure to capture the complete list of business models in the business architecture is an error that is easily avoided.

Comments

• Anonymous
  August 23, 2012
  Really nice, and shows the importance of models and also touches on combining frameworks which is also key, as there is no one size that fits all. To obtain a 360 view of the business you need the full set of business models, without them you are possibly only looking at a single perspective. You must be able to look through a variety of lenses only then can you say you have a true business model :-) I would also add until the business can own the models in a simple way, the process becomes complex.  Simplifying the approach but also having models which are described in business terms across the business model truly aligns all parts of the business and starts to the build the 360 views we all strive for.

• Anonymous
  August 26, 2012
  The comment has been removed

• Anonymous
  August 26, 2012
  @John, I send you a note on LinkedIn to follow up. --- Nick

• Anonymous
  September 06, 2012
  Great post Nick... I recently completed a business architecture design & planning exercise with a LoB utilizing the Business Model (inspired by Alex's work) as the primary model from which change should be captured and strategies and investment decisions aligned to.  Would love to pass some of the overview work your way for your feedback and potential inspiration.  I faced a good bit of the challenges you seem to have solved or are trying to solve in utilizing the canvas and underlying information architecture.  I have leveraged your Motivation model in the past to help rationalize my thinking and would like to give back per se... It was very successful, but trying and complicated at the same time.  Biggest lesson I learned was no matter how close you feel you are to capturing the heart of motivation, leaders are still the key to success.  Having them on-board and unifying strategies is paramount.  I believe agreement on the business model and/or changes to it provide the means for unification to take place. Let me know if that would work for you and how I can pass along my work.  Either way your post is spot on.

• Anonymous
  October 01, 2012
  A recent experience with poor customer service has got me thinking about the role of EA in addressing

• Anonymous
  January 31, 2013
  In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture