/Tag: Metamodel

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.

Steps To Create a Core Diagram

By |2012-12-19T08:34:41+00:00December 19th, 2012|Enterprise Architecture|

To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post.  I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco.  Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort.  Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.

The text below describes a five step process

  1. Collect a list of your organization’s business models
  2. Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
  3. Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
  4. Make an educated guess about the operating model of the company
  5. Draw the core diagram and build understanding around it

 

Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.

So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)

Metamodel for a Business Model

Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.

Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.

This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).

Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.

Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.

Diagram illustrating the dimensions of Operating Models with Integration (low and high) on the Y axis, and Standardization (low and high) on the X axis

In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.

You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.

On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.

Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizatio
ns that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.

Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.

For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.

The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.

The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.

The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.

I hope this gives you a good start in creating your core diagram.

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.

image

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.

Speaking at TechEd New Zealand on Business Architecture

By |2012-08-01T21:17:41+00:00August 1st, 2012|Enterprise Architecture|

Haven’t  been to New Zealand yet, but I will be there soon… From September 4 through 7 in Auckland, for TechEd New Zealand.  I will be presenting two topics (Business architecture for non architects, and Aligning IT with capabilities).

Now, normally you wouldn’t see Enterprise Architecture topics on a TechEd calendar.  However, in the NZ market, there just isn’t the demand for multiple Microsoft conferences every year.  As a result, all the conference demand is bundled up into TechEd.  Due to the efforts of Terry Chapman and the hard working architects in Microsoft New Zealand, the TechEd conference there has developed quite a reputation for hosting an advanced architecture track. 

I’m fortunate to be attending and presenting.  If you live or work in the region, I’d love to see you at TechEd New Zealand.  If you would like to see more information about the sessions at TechEd NZ, click here.

Enterprise Business Motivation Model version 3.5

By |2011-07-27T00:26:07+00:00July 27th, 2011|Enterprise Architecture|

For those of you who have been waiting for me to announce the release of the newest version of the Enterprise Business Motivation Model, I’m happy to announce that version 3.5 is available now. 

To visit a WordPress site set up to explain the model, visit http://motivationmodel.com

To visit a web site produced by the Sparx modeling tool, allowing direct navigation of the model itself, visit http://motivationmodel.com/ebmm

To download a PDF document exported by the modeling tool (for those folks who love PDF files), visit this link here

Special Thanks

The Enterprise Business Motivation Model has gone through a long list of changes since the original article was published over two years ago.  I’ve spent considerable time working through the model and getting feedback from colleagues from around the world. 

I’d like to give special thanks to Michael Davison, JD Beckingham, Neil McWhorter, Bruce McNaughton, Henk Harms, Bill Ulrich, Jim Rhyne, Kirk Rheinlander, Leo de Sousa, Yelena Edelstein, Al Newman, Amy Nguyen, David Vugteveen, and many others who have commented, criticized, and asked for clarifications.  Without your concerns and your insight, the EBMM would not move forward.  Thank you!

Changes to look for

There are many changes since the last public version (v1). 

  • The business model description was updated to reflect connections between customer types and partner types, and to more completely cover the model elements of Alexander Osterwalder’s Business Model Generation. (model, description)
  • Porter’s Five Forces was added as a separate area clarifying the linkage between a Five-Forces analysis and business models themselves.
  • The dual notion of Business Capability and Business Unit Capability proved too confusing and arbitrary for a core conceptual model.  The single concept of Business capability remains.
  • The concept of Data object is now elevated to a top-level element in the model with necessary changes to the high level view. 
  • Business role was added with relationships to business processes and data objects.
  • The concepts of Regulations, Legislative Edicts and Charter Legislation were added to clarify the role of these key concepts to Government and Semi-private organizations.
  • The concept of “capability maturity” was expanded to “assessment metric” to allow a broader understanding of how measures can be applied to business capabilities in order to motivate and measure the success of initiatives.
  • Clear distinctions are made between an enterprise, a company, and a business. 
  • An additional relation has been added to business unit: relates to.  This allows models of the enterprise to include interrelationships between business units other than the normal hierarchical relationships that the existing “includes” relation allows.  This should enable a wider array of analysis models to be created for those architects who need to model a subset of the enterprise.
  • A page was created on the WordPress site to discuss the difference between a Process and a Capability.  (link)

 

Of course, we are not done.  I am publishing version 3.5 in order to insure that my conversations with other Business Architects has a current footing.  The following concerns have been shared and are under consideration for future versions:

  1. Add the ability to attach a Value Chain Analysis
  2. Add the ability to represent the accountabilities of a team in relation to the business processes themselves
  3. <<your suggestion here>>

 

As always, I welcome feedback and input.  I’m proud of where the EBMM has come so far and look forward to working with exceptional people to discuss and describe future changes to the model. 

Note: I didn’t keep a careful list of the folks who offered valuable feedback on the model.  If you offered feedback, and I didn’t mention you above, please accept my apologies and send me a note.  I’ll update this post.

On the Hunt for the One-Page View of an Enterprise

By |2011-06-03T10:55:52+00:00June 3rd, 2011|Enterprise Architecture|

I am currently noodling the idea of a one-page view of my employer (Microsoft) for the purpose of rationalizing the sharing of services across business units and business models.  (If you understood the previous sentence, you are probably an enterprise architect, even if that is Not your title).

As a result, I’m on a hunt for the various one-page views that other companies have produced.  The excellent book “Enterprise Architecture As Strategy” (Ross and Weill) provides three tangible examples (Delta Airlines, ING-Direct, and MetLife).  A fourth I found entirely by accident this morning… a very old one drawn by a Disney cartoonist in 1957, and made available here: (http://taotwit.posterous.com/the-visualisation-of-business-models-did-disn).

1957 one page view of Disney

This is an interesting view in that it illustrates the relationships between the business units and how they functionally support one another.  It doesn’t allocate responsibility, but rather demonstrates responsibilities through the relationships.  In effect, it is a somewhat “contractual” view, indicating the accountabilities between business units.  Fascinating for many things, one of which is the date.

The synchronicity of this find is resonating for me because yesterday, a friend and fellow Enterprise Architect within Microsoft named Krishna Srinivasan, shared a very similar view that demonstrated how the functional units of Microsoft could be viewed.  I’m sharing it here because, honestly, the view was so generic that it is difficult to view it as “revealing” anything that someone couldn’t guess.  That said, it is a fascinating, modern depiction of many of the same key concerns that the 1957 view of The Disney Company was trying to illustrate.  One key distinction: in stead of communicating relationships in terms of accountabilities, it demonstrates process relationships (inputs and outputs). 

One bit of brilliance to consider is that you can track the various processes in the company by following the arrows from box to box to box.  It doesn’t quite meet the needs I’m looking for in shared service rationalization, but it does say a lot about how organizations can be represented visually. 

 

clip_image002

Metamodel 101

By |2011-05-26T17:42:17+00:00May 26th, 2011|Enterprise Architecture|

I was just privy to a conversation about the value of creating a specific kind of metamodel, and it made me wonder… if I had to explain the concept of a metamodel to someone, how would I do it? 

First, let’s start by defining the term “metamodel.”  The IEEE Online Software Engineering Vocabulary (SEVOCAB) provides 12 different definitions for the term ‘metamodel’.  In my opinion, the definition most applicable to enterprise architecture is this one:

CDIF semantic metamodel. (1) the description of the set of concepts and notations used to define a model (ISO/IEC 15474-1:2002 Information technology — CDIF framework — Part 1: Overview, 4.2) Note: The CDIF semantic metamodel defines an Entity-Relationship-Attribute model that is used to construct and define models used in systems development.

Peel away the jargon, and you get this: a metamodel defines the stuff that you put into your models. 

For example, I created this model of a fictitious company, Contoso.  They have created some strategies, and the Enterprise Architect has tied those strategies to business initiatives and those business initiatives to the business units that are impacted by those initiatives.  (A simple traceability model).

Contoso Traceability

If the diagram above is a model, what is in the metamodel?   That’s the diagram below:

Metamodel

In this metamodel, we provide definitions for three terms: strategy, initiative, and business unit.  They are meaningful in the context of the model and should have a single definition.  In addition, the metamodel defines every relationship that is allowed between these elements.  We can say that an initiative may involve a business unit, but our model cannot show the relationship of a business unit to a strategy UNLESS there is an initiative that is aligned to that strategy and which involves the business unit.

A metamodel restricts what you can draw.  It prevents you from drawing things that don’t make sense.  And it clearly defines the terms so that when someone reads your model, they know WHY you described some things as strategies and other things as initiatives (for example). 

A metamodel is the grammar and definitions of words.  It provides the dictionary.  The model itself is the story you tell with those words. 

Tutorial over for the day!

Essential Project–Open Source EA Metamodel

By |2010-12-31T10:54:00+00:00December 31st, 2010|Enterprise Architecture|

One thing that often occurs when a team sets out to create an EA tool is that they create a metamodel that will be supported within the tool.  As I pointed out in my last post, I would like to openly challenge tool makers to allow multiple simultaneous metamodels to exist, so that organizations can answer questions from multiple focused perspectives.  In my opinion, this challenge will be quite difficult to realize.

I’ve been looking at some of the public documentation for various EA tools in order to see the metamodels that they support.  This provides some insight into the level of difficulty of this challenge.  Along the way, I’m also becoming reacquainted with some things that I’ve seen before (like a long discussion of the Troux metamodel that I got from an EA conference a few years ago, and the detailed understanding of the alfabet metamodel that I have first-hand experience with, as well as some exposure to the Aris metamodel from IDS SHEER).

I also ran across an open source metamodel that is part of the open source Essential project – a project to create an open source EA tool.  (Personally, I think that open source EA tools are a good idea, but I think the business model that will ultimately win out is a cloud-based model that allows rapid deployment of an instance of an EA tool.  Open source may not be the best way to deliver that business… but that’s a future post.)

The thing that I’d like to call attention to is the detailed open source metamodel that has been produced by the Essential team.  Why is it interesting?  Perhaps because the metamodel is open source but not community developed!  In other words, I’ve seen no public discussion of this model and I cannot see any relationship between this model and those that have been discussed in public.  Why would I adopt an EA tool that allows one model at a time, yet is based on a model that I’ve had no insight into how it was made or what problems it was designed to solve?  Seems fairly backwards to me.

That said, the team that developed this model has done some very good work, and I recommend it to others for understanding and engagement. 

My biggest concern, before I take the time to really jump in, is that the model seems to have been created in PowerPoint.  That makes for some very difficult model analysis, which may mean that there are hidden defects in the model that are difficult to detect.  That doesn’t mean that defects exist… just that I’ve not found that PPT is a good environment for generating metamodels due to the difficulty of debugging the model.    [Correction: the model is produced in an OWL tool.  The metamodel visualizations on their web site are probably just that: visualizations for the sake of consumption — NM, corrected 1-4-2011]

Note that clicking on each of the images below will take you to the actual page on the Essential web site where the model originates.  No point in duplicating that data on my blog.

Essential Bus MM   Essential App MM
Essential – Business Metamodel Elements   Essential – Application Metamodel Elements
     
Essential Info MM   Essential Tech MM
Essential – Information Metamodel Elements   Essential – Technology Metamodel Elements

Can EA Data be independent of the Metamodel?

By |2010-12-30T09:46:06+00:00December 30th, 2010|Enterprise Architecture|

One thing that I’ve come to appreciate is both the importance, and impermanence, of the Enterprise Architecture metamodel. 

If that last sentence didn’t piss you off, you weren’t listening.

I’ve found two common groups of Enterprise Architects:

  1. Folks who do not understand, or care, about EA metamodels.  Starting with Zachman aficionados, and working up to some practitioners of Balanced Scorecards, Business Process Management, and Business Strategy development (all fields that benefit from, and are necessary to, metamodels, but which were developed entirely without that concept).  To the credit of many folks who have come up from these fields, they have seen the value of metamodels along the way and moved to the second group.  Others, unfortunately, have not been able to see the holistic value of understanding knowledge using a connected model of well-defined concepts, and remain in the camp of “metamodel doubters.”
  2. Folks who believe that there should be a solid, unchanging, metamodel, and that all business and technical metadata should fit within it.  The ranks of this group are growing rapidly, as TOGAF has adopted the concept of metamodels and as groups focused on Business Architecture have brought out research materials and books dedicated to specific metamodels.  Readers of this blog will note that I produced a metamodel of sorts with the EBMM (Enterprise Business Motivation Model) nearly two years ago now, with an update to come soon.

 

Unfortunately, there are flaws with the thinking of both groups, and I’d like to propose a third way…

I’d like to propose that metamodels should be created as part of the “view", and not part of the “model” itself: That data will exist independently of the metamodel, in a manner that can be formed into a metamodel that is custom-suited to meet a particular need, at the time of that need. 

Kind of hard to imagine, isn’t it?  After all, as Information Scientists, we think in terms of the data structures… how data will be created, stored, manipulated, and consumed.  And ALL databases have a data model.  (the relationship between tables, fields, keys, indices, triggers, and constraints, as concepts, is an underlying RDBMS model).  How, exactly, can we store data in a database without first creating a single model that describes the type of data that we intend to store, how it will be stored, and how it will be related?

Yet, we’ve seen the field of “unstructured data” blossom in the past decade with the emergence of search engines like Google and Bing.  These engines have brought ever-increasing sophistication to the notion of “answering human questions” from data that is not, fundamentally, structured into an information model.  That said, the most useful data in unstructured systems is still classifiable into complex types, and that classification allows the usefulness of that data to come through. 

For example, if I go to Google and search on a local department store, I could type “Kohls in Covington WA”.  I will get the results below.  Note that if I go onto Bing and issue the same search, I will get nearly identical results.  In both cases, model is applied.  The word “Kohl’s” is taken to mean “a department store” and from that, we can add attributes.  After all, department stores have phone numbers, addresses, can appear on a map, can have items on sale, and, almost as an afterthought, can link to a web site.  

The search results illustrate far more than just links to web sites.  The search engines are applying a classification to the otherwise unstructured information.  To add value, the question is understood, and results are produced, based on classification.  This “result” is not just a web site.  It is not just “random unstructured data.”  And the results are more useful as a result of this understanding.

Bing-metamodel Google-metamodel

Imagine that we have a search engine that works for business and information systems structural data instead of web sites.  We can “know” a great deal of information about business motivation, strategy, competition, business goals, initiatives, projects, business processes, IT systems, information stores, software instances, etc, all the way down to servers, network infrastructure, and telephone handsets.   But can we “apply the appropriate metamodel” to the data at the time when it is needed?

In other words, can we answer questions like these?

  • What systems need to be modified in order to improve competitiveness as expressed through the business goals of the Retail unit? 
  • What is the accumulated Return on Investment of the projects that have completed in IT in the past two years?
  • What gaps exist in the initiatives chartered to create a strategic response to the competitive threat posed by the Fabrikam corporation’s new product line?

Can we do it without pre-specifying a metamodel?

Folks in the second camp above will ask an obvious question here: why not catalog data according to a single super-dee-duper, one-size-fits-all metamodel?  After all, once you have the right metamodel, every one of these questions can be understood and answered.

Let’s parse that idea a little… What makes a metamodel “right?”  I would venture that a metamodel is not ??
?right” or “wrong.”  It is simply “useful” for the purpose that it is being used for… or not.  For example, sometimes I care about the distinction between a business process and a business capability.  Other times, I do not.  If my metamodel is static, I must always collect business data according to a single unified taxonomy, or I must always have two different taxonomies.  But the world is not so simple.  Sometimes, I need one.  Sometimes, I need two.  The metamodel is dependent upon the question I’m asking and the problem I need to solve.

In other words, the metamodel itself is a dependent variable.  Only the raw data, the business stakeholders, and the business concerns themselves, are independent.  All the rest is self-organizing and, here’s the problem, changes depending on the situation.  The structure, relationships, and important attributes of any one set of elements is particular to the problem that the stakeholder is solving.

So, I will re-ask my question: can we collect information in a manner, and understand it in a mechanism, that allows us to apply different metamodels to the data depending on the need of the stakeholders?

I think we can.  I think we must. 

How (not) to convince an architect

By |2010-12-09T11:12:10+00:00December 9th, 2010|Enterprise Architecture|

I’ve been watching, with a mixture of dismay and mirth, a LinkedIn discussion between Adrian Grigoriu and a group of Enterprise Architects as he attempts to promote his new business architecture approach.  Now, to be fair, Adrian has already written and published his book, so it is a little late to take constructive criticism from his peers.  Poorly timed discussions are a dangerous thing.

One thing that is clear: the architects on LinkedIn are not convinced that his diagram is actually an architectural model.  To be fair, Adrian has dug a hole for himself by (a) insisting that his diagram is actually an architectural model, and (b) stating that it compliant with emerging standards.  The folks on the forum have rather convincingly demonstrated that both these statements are untrue.  The odd thing is: those statements don’t need to be true.  The diagram doesn’t have to be an architectural model to be a useful diagram.

Not everything that an architect produces must be an architectural model.  I think it is good when we use models because we can defend the view with data, but the imperative of an EA is to be useful first and foremost.  It is entirely possible that, in some situations, Adrian’s diagram would be “useful” without being a model.  Unfortunately, he never describes those cases, so we are left to marvel at his diagram and say “good job” without being sure that we can use it.  Personally, I don’t find it useful.  Alas.

So, what does it take to get other architects to see value in the work you do?  What mistakes did Adrian make when he started the conversation?

  • First and foremost, we all have a certain amount of self confidence in the “goodness of our stuff.”  That can lead to a little bit of self delusion, and every author is susceptible to it.  The key, in a semi-scientific community like EA, is to counterbalance that natural tendency with opinions from peers in a private and trusted conversation, before you go live to the marketplace with your final product.  Scientists discovered a long time ago: peer review matters.  Get your peers to review your work before you publish it, so that you can make statements that are credible, accurate, and compelling without getting involved in pedantic discussions.
     
  • Secondly, Use some of that business savvy that makes a business architect successful and consider your “idea” to be a product.  How would you market that product?  What name would you call it that would be appealing to the people who need to “buy” it?  What would they find credible, surprising, useful, compelling, and easy to share?  Perhaps if Adrian had taken a “marketing” approach to his ideas, he would not have named his framework “GODS,” presented it only from the business process perspective, or ignored the fact that he has represented two (out of dozens) of high level business models as though it were an archetype for all commercial businesses.
     
  • Third, when you want others to believe you, tell a compelling story about how the product came to be, what inputs you used, what experts you relied on, how it has already proven useful in three or more places, how others can use it, and why it is important for your readers to adopt it NOW.  If you cannot weave together all of the elements of a good story, your customers won’t care and you will spend all your time talking to critics who really have no motivation to support you, but plenty of reasons to oppose you.  Not a good place to be.
     
  • Lastly, know when you are selling and when you are collaborating.  His question to LinkedIn was phrased to invite collaboration, but that is not what he wanted to occur.  As a result, his purpose (advertising the book) is defeated, but more importantly, he is unable to collaborate with people who would love to help him, but cannot because he did not ask for help at the time when it would have been useful: before the book was out the door.

I wish Adrian good luck with his efforts, but more importantly, I hope to learn from his mistakes.