/Tag: Business Model Generation

Alternatives to the EPSC Model

By |2016-07-10T00:45:26+00:00February 16th, 2015|Enterprise Architecture|

The Enterprise Partner Supplier Customer (EPSC) Model sits as a core concept of Enterprise Architecture.  It is so much at the core of everything we do that we seldom question it.  Is that healthy?  This post will discuss the core idea behind the EPSC model (differentiation by control) and alternative ways to think about enterprise boundaries.

First off, we only name things when we want to differentiate them.  As the old expression goes, “the fish discovers water last.”  In EA, we tend not to discuss the fact that we assume a particular model of enterprise identification and enumeration on a regular basis.  That’s because the model is built in to the things we say and do.  It’s built in to our business models and our service models.  It’s built in to the way enterprises create policies and budgets and govern efforts.  It’s so deeply ingrained that we rarely question it.  Well, it’s time for this fish to discuss the nature of water.  And to do that, we have to name it.  I’m naming it the EPSC model, which is an acronym for “”Enterprise Partner Supplier Customer”.  It looks like this:


The view that an enterprise is a bounded thing, with suppliers feeding in, customers getting the benefits, and partners in a peer-to-peer relationship… that’s the EPSC model.

The underlying assumption of EPSC is control.  In this model, there is typically OWNERSHIP CONTROL over the enterprise.  “Ownership control” means the same people OWN an influential number of shares in each of the organizations inside the box.  That is not necessarily controlling interest.  It is sufficient interest to ensure that the all the businesses inside the box get along well with each other.  It works because employees do what their bosses tell them to do.  Take that fundamental notion and expand it to the enterprise level and you get the assumption of ownership control.

Another form of control is ECONOMIC CONTROL which is typically the case when there is a huge size disparity between the suppliers and the enterprise itself with respect to the end customers.  This happens in retail a great deal. Walmart is a textbook example of “economic control” since their supply chain requirements can drive massive costs into their suppliers without any substantial backlash.  The fundamental model above is the same so I’m not going to redraw it.  It’s still EPSC.  Just with a really big “E”.

Why do we need alternative models?

The Internet has introduced some things we expected, and some things we didn’t.  We expected the introduction of easy communication and easy transmission of data.  What we didn’t expect: the creation of the commercial ecosystem as a differentiating factor in strategy.  In other words, the creation of a product by one company that is combined with another product to be consumed by a customer dependent upon both to solve the needs of a customer that is totally unaware of either one.  This is common now in the mobile applications space.  A mobile app may be created from unique capabilities of four or more companies that are not just peers, they are collaborating peers, all focused on producing the mobile application.  Yet the customer is unaware of the grouping.

The EPSC model is completely broken for understanding this space.  It simply fails.  Because there is no boss telling you what to do.  There are only customer opportunities.  It is organic and bottom up in its very nature.

And the moment we examine the “more than one” condition, we have to open the door to the possibility that there are more than two or three or ten.  How many alternative models are there?  I do not know.  No one has enumerated them and drawn distinctions (hey, doctoral candidates… want a dissertation idea?  Enumerate these).

I will brainstorm a couple of alternatives.  This is not a thoughtful investigation of models.  It’s a brainstorm.  Take it with a grain of salt.  But I encourage you to use the ideas to expand your own thinking.

The Dynamic Collaboration Model

The dynamic collaboration model involves a series of companies that have no common ownership but who collaborate on a very frequent basis to create positive value for customers that is achievable through the combinations of their products.


The key to success in this model is to focus on that dynamic collaboration and to build excellent feedback mechanisms with the customer.  This kind of model can fall apart of the customer loses confidence in the collection of companies to meet their needs, and it is vulnerable to attack from alternative collaborative groupings that build better feedback mechanisms.

What other models exist?

My knowledge is not wide enough to suggest that I understand other possible models.  Perhaps recognizing more than collaborative self interest is necessary to even perceive them.  I know that there are more than one, and I’m guessing that there’s more than two.  These are the two that I can see.  Please post your own ideas and we can collaborate.

What does this matter?

Well, I’d suggest that the strategy of Microsoft under Bill Gates reflected the dynamic collaboration model, but that the strategy under Steve Ballmer reflects the EPSC model.  We can see the gradual deterioration of value and innovation during this period.  Microsoft under Satya Nadella has shown signs of moving back towards the dynamic collaboration model.  Time will tell.  He inherited a very weird beast.

But just as important as understanding Microsoft, what does this say about Google, Amazon, Force.com, IBM, Oracle, and the hundreds of other competitors (and open source initiatives) that fill the technology space?

  • Oracle seems to play in the EPSC model.  What does that say about the future of Oracle?
  • Amazon clearly plays in the Dynamic collaboration space?  Does that ensure a bright future?  How important are each initiative in Amazon when vi
    ewed in this context?  While delivery to the neighborhood is necessary, are the drones needed?  Or is that just good buzz?
  • Google… plays in both.  (Kind of like Microsoft).  The EPSC model drives their revenue, but there’s a lot of initiatives in the dynamic collaboration space.  Is this an intentional transition, or just opportunism?
  • Facebook is primarily an EPSC business, with a very large base of users.  (See economic control above).  Will they make moves toward dynamic collaboration?  Can they survive if they don’t?

This kind of differentiation is useful for making these kinds of observations.


Your thoughts?

Should Business Architects use the Business Model Canvas at the Program level?

By |2013-01-31T10:51:21+00:00January 31st, 2013|Enterprise Architecture|

In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture.  In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started.  He felt that the canvas is useful for creating a clear picture of the business impacts on a program.  There are problems with this method, which I’d like to share in this post. 

Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.” 

A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.”  This business program has a management structure and is ultimately provided funding for a series of “projects.”  The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs. 

For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model.  I’m using the term “program” for this post because the Open Group presenter used the word “program.”  Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.

The practice presented by this talk is troubling to me.  As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out.  By doing so, he or she would understand “the” business model that impacts the program. 

During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models?  The presenter said, in effect, “we only create one canvas.”  My jaw dropped.

A screwdriver makes a lousy hammer but it can sometimes work.  The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.

The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program.  First off, programs are transitory, while business models are not.  The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business.  Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time.  It is completely inappropriate for capturing two different models on a single canvas.  Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.

I have no problem with using business models (although my canvas is different from Osterwalder’s).  That said,  I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas.  The session speaker specifically rejected this idea.  I don’t think he is a bad person.  I think he has been hammering nails with a screwdriver.  (He was young).

Here’s where he made his mistake:

multistream value chain

In the oversimplified value stream model above, Contoso airlines has three business models.  The business owners for these three businesses are on the left: Bradley, Janet, and Franklin.  Each are primarily concerned with their own business flows.  In this oversimplified situation, there are only two programs, each with one project.  If the session speaker were working on the Plantheon program, his idea works.  there is only one business model to create.  That nail can be hammered in with a screwdriver.  Lucky speaker.  Showing Franklin his own business model is a good thing.

But if we are working on the Flitrack program, what do we show Franklin?  if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns.  He will not benefit and neither will the program.  In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?

Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models.  The business model that Franklin cares about does not need to be created again.  It can come out of the repository.  The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program. 

Anything less is business analysis, not business architecture.

Is Enterprise Architecture accountable for improving customer experience?

By |2012-10-02T00:18:15+00:00October 2nd, 2012|Enterprise Architecture|

A recent experience with poor customer service has got me thinking about the role of EA in addressing customer experience issues. 

One of the last things I was working on, while still in Microsoft IT, was working on an initiative to systematically help improve customer experience.  With that experience fresh in mind, I was dealing with an issue with my Tivo DVR today where the Tivo box started to misbehave.  I began a chat with their representative and the experience was less than ideal.  (If someone from Tivo wants to chat, just drop me a line for details).

That got me thinking.  Can EA help?  In general, can EA be part of the solution to problems caused by poor customer experiences? 

The Official Dilbert Website featuring Scott Adams Dilbert strips, animations and more

Customer Services is important to the success of any organization

First off, I’d like to say that customer experience is one of the most important elements of the highly competitive online world.  The Web has made it very easy for customers to abandon their existing relationships and switch to new ones.  Even the slightest provocation can send a customer in search of a competitor, and the features of a product are not as “sticky” as they once were.  It is increasingly easy for new small companies to appear that copy all of the key features of a technology and release a competing product, sometimes within a few months of the first one.  The results can be fierce competition that, unfortunately, is often addressed in courtrooms instead of the marketplace (Samsung vs. Apple, Google vs. Microsoft, Apple vs. Microsoft, etc.).

Some companies will not pay proper attention to their customer’s experience.  This is fairly common, especially in manufacturing companies where there are both software and hardware components involved.  For some reason, the fact that two different engineering teams are involved often produces a disjointed experience.  (Apple has been leading the way in addressing these kinds of problems.  The rest of us need to do so as well).

What are the questions you must always be ready to answer?  (The Ten Strategic Questions)

In general, an Enterprise Architect assists with the development of strategic alignment, not by deciding what is important, but making sure that executives don’t miss the important stuff while they are overwhelmed with the mundane.  One way to anchor your analysis to ensure that YOU don’t miss the important stuff is to consider some of the high level tools suggested in traditional strategic analysis… tools like SWOT analysis, Five Forces analysis, and partner accountability mapping.  However, most of those tools do a poor job of considering the importance of customer experience to enterprise success.

The model that I use is the EA metamodel behind business models.  In a prior post, I created a rationalized ontology for the business model canvas that addressed the gaps left by Osterwalder in his analysis.  However, in keeping with the effort to make that kind of model useful, I followed the pattern of Osterwalder and created a visual table that represented the corrected business model ontology.


The guidance that you can get from this is to look at each of the blocks in the canvas and consider the possibility that you have not missed anything important in that block.  Therefore, if you use this model, you would ask the following ten questions:

  • Are we targeting the right customers for the growth that we need?  (Customer Profile)
  • Do we have a good understanding of what our customers want and need? (VOC)
  • Do we have a compelling value proposition to address the needs and demands of those customers? (Value Proposition)
  • Are we developing products and services that deliver on our value proposition, or is there a gap in our products and/or services that we need to address? (Products and Services)
  • Have we considered all of the channels we should be using, or are we using too many channels, to distribute our products and services to our customers? (Channels)
  • Do we have a good idea of the resources we need to deliver on our value proposition? (Resources)
  • Do we know how to use our resources sufficiently well to produce the results that customers expect? (Required Competencies)
  • Have we addressed all the cost and revenue implications of the resources, competencies, and channels that we’ve selected? (Cost and Revenue Models)
  • Are we reaching our customers in the geographies and locales in which they live and work, and if not, why not? (Geographies and Locales)
  • Have we relied on partners in the right way, leveraging their strengths and the cost implications of using them without opening ourselves to problems of key dependencies? (partner profiles)

This list of questions includes the core questions that we need to be asking in order to address customer experience issues at the strategic level.  This is a far more comprehensive list that “5 forces” or “SWOT” and will help you to ensure that you are not missing anything. 

How does Enterprise Architecture address customer experience?

The actual experience of a customer is a function of their needs and your products.  If a customer needs to drive a nail, a hammer will do.  If the customer needs to drive their car to an unfamiliar place, then a Global Positioning System with turn-by-turn directions would be more compelling.  If you offer the customer a product that does NOT meet their needs (like a GPS that only shows maps, but doesn’t tell the driver where and when to turn), then they will not be loyal to the product.  Their experience will be poor and they will quickly find better products.

Customers don’t want ten inch drills.  They want ten inch holes.

When doing a strategy workshop, it is best for the Enterprise Architect to walk in to the workshop with all their preparation in place.  Walking in unprepared will produce really poor results.  To be prepared, the Enterprise Architect will have already collected the list of “proposed strategies” for the coming period and will have analyzed those strategies from the standpoint of the organization’s business model(s).  In other words, for each of the questions above, which ones are being answered by strategy.  Now, f
or the kicker, which ones are not? 

Customer experience may already be covered by a strategy, and if it is, you have to do very little.  Simply make sure that everyone sees the relative value of that strategy when compared to others (like reducing costs or negotiating new boundaries with existing partners).  That is not simple, but not as difficult as the alternative: no strategy for customer experience.

On the other hand, let’s assume that there are goals, or objectives, or themes (rarely actual strategies) already articulated that address the other areas of business model considerations, like costs, or products, or partners.  Address the lack of customer focus in your interviews PRIOR to the strategic workshop.  Ask your key stakeholders what their customers need.  Specifically don’t ask for how those needs are being met… ask what the needs are!  Make sure that you plant, in the minds of your stakeholders, the seeds of doubt: do we KNOW what our customers want and need?  Is it written down?  Would our customers agree with what we wrote down?

During the workshop, propose an initiative to capture the needs of the customers (of each business model) and to map the products and services to those needs.  This will let you answer the question: are our products and services meeting the needs of customers?  This may involve the development of user personas, scenarios, and competitive surveys.  This initiative, when complete, will provide the ammunition that you will need later to propose initiatives to address customer experience gaps. 

Note that gaps can exist in many places… not just in the products themselves, but also in the customer service experience that occurs when customers are not happy with their products or have an issue with them. 


Enterprise Architecture is a strategic planning function that uses a methodical scientific approach to address the gaps between the goals of a business and the execution of strategy needed to reach them.  Using the TEN STRATEGIC QUESTIONS above, Enterprise Architects can capture opportunities and oversights that senior executives may miss.  One of those key questions addresses customer experience issues. 

Therefore, when an organization fails to deliver good customer experiences, Enterprise Architecture, when used properly, can help to address the situation.

The EA Metamodel behind the Business Model Generation

By |2012-08-22T23:02:00+00:00August 22nd, 2012|Enterprise Architecture|

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

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).

Osterwalder Conceptual Model

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.)

2. Osterwalder Conceptual (minus transitive)

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? 

3. Financial Elements Only

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.

3b. Customer Elements Only

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:

4. Conceptual With Combined Financials

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

5. Aligned Terminology

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:

Business Model Viewpoint.3.8


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.

Core Elements Only View.3.8

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.