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.

Everything you’ve read about IT Project Failure is wrong

By |2012-12-09T17:52:16+00:00December 9th, 2012|Enterprise Architecture|

I did a scan around the web to figure out what many of the leading thinkers were saying about IT project failure and the root causes.  Numbers varied between 20% and 80% of projects failing to deliver on their business case.  The root cause analysis that follows from these failure numbers spends a lot of time looking at the IT project, but most forget to look at the causes of failure that are outside the project’s control.

In the diagram below, the central blue box represents causes of IT project failure that are inside the control of the IT team.  As you can see, there are many more causes of IT project failure that are OUTSIDE that blue box than inside it.  Yet, countless articles have been written on the factors INSIDE the box.  I think it is time we take a slightly wider lens to the problem!


The factors outside the project are as important, or more important, than the ones inside the box.  I have worked on many projects over the years, and if I look back at the ones that ended up cancelled or scrapped, the reasons were not ones in the blue box.  They were usually ones from the top box: where the project should not have begun in the way that it did.  Let’s look at these six factors:

  1. Lack of accountability for success – Sometimes, in an organization, an interesting situation will arise.  I call this the “can’t lose” scenario.  In this scenario, the CIO will suggest that the business can benefit by doing some particular initiative, and his or her people will set out to find a business sponsor for the initiative.  In this case, the sponsor will reap the benefits of the initiative, not the CIO.  (Let’s say that the CIO has suggested a Business Intelligence initiative, and signs up the Chief Marketing Officer to sponsor it).  If the project succeeds, the sponsor wins.  If the project fails, the CIO (not the sponsor) loses credibility.  After all, it wasn’t the sponsor’s idea.  The CIO dreamed it up, after all.  In fact, the sponsor may not do any real “sponsoring.”  He may sit in an occasional status meeting and check his e-mail while the program manager he assigned from his team answers questions… and keeps him protected from any blowback.  The sponsor in this case is not accountable for success.  No one is.  The odds of this project succeeding are small.  (Note: a good IT Governance system prevents this condition). 
  2. Failure to get buy-in from above – Often, a senior executive will ask his operational leaders to suggest IT projects for the planning cycle.  The executive (let’s say Tina Smith, Vice President of Sales) assumes that the leaders (William, Ashok, and Lee: all three are General Managers) will ask for projects that align to their individual strategic needs.  One of those General Managers, William, decides to create an IT project to implement a SOA service bus.  He wants the bus because he is investing in replacing an application and his IT team tells him that a bus is a good idea.  After all, if everyone in the Sales group uses it, everyone will benefit.  But William doesn’t get Tina Smith’s buy in.  He implements his SOA service bus, but when subsequent IT funding requests come up to move other sales applications over to the bus, his peers Ashok and Lee are not interested.  Their priorities don’t include moving to the bus.  William bought a white elephant.  Because he didn’t get Tina’s buy in, none of his peers will reap the benefits.  Is the SOA bus a failure?  Well… it’s not a success.
  3. Misaligned prioritization – Lee James, General Manager of Sales for the Western region of Contoso owns a sales strategy for the enterprise.  The strategy is to make the sales force more productive by moving the company over to a new CRM system.  The CRM system has out-of-the-box support for a long list of reports, but his team tells him that he shouldn’t use those.  Instead, he should put in a Business Intelligence system in the cloud.  Lee wants to trust his team to pick the right solution.  They tell him that the cost of this system is $4 Million over two years.  The company is moving to a new strategy that de-emphasizes the direct sales force.  Instead, the company will be relying on social networking and direct eRetail to make sales.  To make the new strategy work, there are eight projects totally $8 Million that need funding.  There is a competition for dollars in the IT budget.  Lee goes to bat for his $4 Million commitment.  It’s important because “we are already here, so we have to complete the job.”  This is an example of misaligned priority.  The new BI project can be safely cancelled or scaled WAY back to support a strategy elsewhere, but that other strategy doesn’t belong to Lee.  The one that he owns needs money and he’s going to keep fighting to fund it because his boss, Tina Smith, isn’t aware of the tradeoff.  Lee fights, and Contoso loses.  Which project will fail?  Both of them.
  4. Slow decision making – This one is related to the other problems in that it is often, but not always, caused by a poor governance system or poor prioritization of the effort.  In this scenario, the team implementing the project needs the sponsor to make a decision, often one that requires consultation with his or her peers or counterparts in another part of the company.  The sponsor may be unwilling, unable, or incapable of having a difficult conversation.  On the other hand, they may be indecisive.  Regardless, this situation can cause serious delays in a project.  For example, Ashwin’s application sends EDI-formatted messages to a health insurance provider.  The provider had indicated that new fields are allowed in the messages that are very valuable to Ashwin’s line of business.  However, he has to upgrade his EDI translation software to get the new fields.  The EDI translation software is also used by the Finance group to send banking transactions.  Ashwin knows that the finance group will get a benefit out of the upgrade and wants them to help cover the costs.  This upgrade will add $25,000 to the cost of his project and he’s on a tight budget.  The software team offers to write a small component that will insert the fields into the data stream, but its complicated and fragile. Ashwin cannot decide if he should ask the finance team for funding or if he should upgrade the software.  The project team cannot proceed without a decision. 
  5. Lack of authority to drive change – This one is quite common.  Ashok reports to Tina Smith, VP of Sales for IBuySpy.  He has told her that he wants to take the lead on one of her strategies
    : to consolidate all of the eCommerce systems in the company to a single outsourced vendor.  Tina things that this will reduce costs all around, and Ashok is happy to take on the challenge.  His business analyst does a survey and it turns out that the services and support team offers customers the right to buy replacement parts online.  In addition, the “outside services” team allows customers to buy a service contract on their own area of the website.  The main sales site, of course, uses a high-volume low-cost vendor that Ashok is comfortable with.  Ashok sets up meetings with the owners of the other applications, but they choose not to provide the needed transaction cost information or the cost estimates of changing their internal systems.  His data is light but he strongly suspects that there is a good business case for switching.  Unfortunately, he doesn’t have the data to prove it.  Without data, the Tina won’t take the case to the CEO to require the other teams to jump onboard.  The strategy fails.  Neither Ashok, nor his manager Tina, have the authority to require their peers to adopt a lower cost system.
  6. Lack of influence to rally peers – In many organizations, the prevailing attitude is that the boundary between “centralized” services and “federated” services is intentionally fuzzy.  In these companies, there is no policy that requires a function to be centralized vs. federated.  For example, if a company has ten divisions, three may have their own financial processes, while the other seven share a common finance unit.  The decision to use the central finance unit, or to own a federated unit, can be made and unmade depending on who the leaders of the business are.  (Note: leaders change, and with them, these decisions change as well).  This kind of policy is good for flexibility, but creates both inefficiencies and often, confusion.  This is simply a tradeoff in the design of organizations.  It is neither right nor wrong.  In this environment, any business can create a “centralized” function by convincing more than one business leader to come together to create a shared resource.   The flaw comes when a group wants to create a “centralized” (or simply “shared”) function, but they lack the influence needed to get multiple businesses to join the initiative.  Difficult questions of shared funding can be demotivating, and the political need to create “alliances” can be difficult for junior executives that, in many ways, are competing with one another for the next rung on the career ladder.


Each of these conditions has the potential to kill an IT project.  I would suggest that MANY IF NOT MOST of the failures of IT projects can be traced to one or more of these conditions, but these conditions rarely get counted in the statistics for “Causes of IT Project Failure.”  Why?  Because, in most cases, projects that suffer from these conditions are either never funded, or are reworked so that the political problem is simply avoided.  The project business case does not reflect the problem, so the criteria for failure (doesn’t meet the business case) is never met.  Efforts are made to avoid (but not address) the problem before the business case is written!

This is the world of the Enterprise Architect.  These are the kinds of “failure” that fill the eyes and ears of an Enterprise Architect.  If an EA focuses on only these six causes, he or she will deliver real, tangible, and unique value to their enterprise without ever overlapping the roles and responsibilities of an IT architect, business analyst, or technologist.

The Story behind “Stories That Move Mountains”

By |2012-11-04T18:31:33+00:00November 4th, 2012|Enterprise Architecture|

There is a new book available that I’d like to let everyone know about.  It is called “Stories That Move Mountains.”  I wrote this book with two fantastic professionals Martin Sykes and Mark D. West.  In this post, I’m going to talk about how this book came to be, and why I felt so strongly about it that I invested two years of my life in bringing it to market.

First off, if you are interested in buying the book, and we think you will be, you can click on the image of the cover to take you straight to our “buy the book” page on the book’s sister site, StoriesThatMoveMountains.com


Edward Tufte and Me

My journey into “rich information” began, as it did many others, when I heard about a book called “Visual Explanations” written by Edward Tufte.  It was 1997, and the dot-coms were booming.  I had left Microsoft to stake a claim in the modern gold rush.  I was working as a development manager in a quickly growing web development company in downtown Seattle called Fine.com International. (see note

On my team was a talented young web developer named Brian Poel who told me about a seminar he attended hosted by Tufte.  In the seminar, Tufte taught about creating visual designs that inform, not just impress.  Brian showed me the materials and I ended up reading Tufte’s book myself  (Another bit of evidence to support the old saying: a manager is only as good as the smart people that surround him).

Visual Explanations: Images and Quantities, Evidence and NarrativeAt fine.com, we used the techniques described by Tufte in every way we could.  His guidance led to design ideas that fed into the Nasdaq.com web site, the Marriott hotels web site, and many more.  I learned the power of structuring information in a way that makes it easy to consume, elegant to perceive, and compelling to read. 

It would  be many years before I needed these techniques myself.  That didn’t really start until I became a management consultant.  The year was 2001, and the dot-com that I co-founded after leaving fine, Acadio, had failed along with tens of thousands of other young start-ups.  I had moved to a consulting company called Sierra Systems Group (headquartered out of Vancouver British Columbia) to make ends meet.  For the most part, I focused on technology activities, but I had to ramp up my communication skills.  So I started using some of the rich information techniques that I learned from Tufte in our marketing and sales materials.  I cannot say that I was particularly good at it.

I Can’t Draw… Seriously

I really can’t.  Not even stick figures.  Which is odd, because both of my parents, my eldest brother, and my daughter, are all gifted artists.  Not that I can’t create useful diagrams… I had trained in high school as a draftsman.  Give me a T-square, two triangles, a nice drawing board, and couple of sheets of vellum and I can draw a complete set of floor plans for your house (well… I could in 1980… maybe not so much now).  But freehand, I am hopeless. 

Beyond Bullet Points: Using Microsoft PowerPoint to Create Presentations that Inform, Motivate, and Inspire (Business Skills) (English and English Edition)So when I tried to create a nice visual representation, and failed, I thought it was because of my lack of skill as an artist. I couldn’t have been more wrong.  Regardless, the best I could do, at the time, was to follow the guidance in “Beyond Bullet Points” and create PowerPoint presentations that were compelling using emotive photographs.  They were nice, but they weren’t the things I wanted to create.


Meanwhile on the other side of the Atlantic

Turns out, I was part of movement of sorts.  A growing number of people had taken up the challenge of creating interesting visual representations of complex information.  The “infographic” movement had started, and companies were springing up here and there to provide clear, simple, and compelling explanations of complex information.  On the other side of the world, in the UK, an enterprise architect named Martin Sykes had begun his own journey, around the same time as I had.  Big difference: he didn’t give up.

If you ever get a chance to meet Martin, you will enjoy his company immensely, just as I do.  Martin is clever, thoughtful, easy-going, and funny.  He’s a systems-thinker and an excellent speaker.  Martin was also influenced by Tufte, but he continued on to find many other authors and designers who were publishing and writing about this new way of doing things.  Martin started creating his own single page explanations of otherwise complex information, building up his skills and collecting techniques along the way.  And, Martin took the time to learn how to draw.  That didn’t hurt.

I met Martin Sykes through a mutual friend, Gabriel Morgan.  Gabriel had joined the Enterprise Architecture team in Microsoft IT just a few months after I did, but he came to the practice from his work as a consultant using Microsoft Motion (later renamed Microsoft Services Business Architecture or MSBA).  Gabriel had met Martin a few times, and had seen some of the visualizations that Martin used to explain business architecture.   Gabriel worked with Martin to set up a workshop, for our team, to learn some of these skills.  And in late October of 2007, Martin flew to Redmond and spent a week teaching us how to “tell stories” using a series of visual metaphors.  At the time, he called them “Big Pictures” but that thinking evolved and we now refer to these creations as “visual stories”.

Can we do this again?

imageDuring Martin’s workshop, each of us created a visual representation of some idea or story we wanted to tell.  Martin had distilled his own personal techniques into a FIVE DAY COURSE on creating visual stories.  He walked us through ample examples, storytelling exercises, and a fairly simple process that he used to create visual stories.  I created two visual stories in that class, one of which Martin still uses today… as an example of what NOT to do in a visual story!

The five day class happened once. Over the next few years Martin did four one day classes at different companies where he had been asked specifically to do more following a series of 90-minute presentations he had done at internal and external conferences. But the ideas were not “catching fire”, in large part because Martin was just happy to use what he was learning and focus on his day job of making change happen.


Meanwhile, I kept using his materials, and referred often to the binder full of PowerPoint slides that he provided.  I practiced a few times more, and then stumbled into success.  I created a visual story to explain an enterprise architecture roadmap to the Vice President of Operations.  I presented the one page visual, and the meeting went fairly well.  We got the sponsorship we needed.  What I didn’t discover until later: that same Vice President took my one-page presentation and gave it to Steve Ballmer, CEO of Microsoft and one of the most powerful businessmen in the world, to explain how Microsoft’s Operations Division was attacking a key problem within the company.

That single page told a story.  It was not a bunch of data.  It was not a bunch of clever graphics.  There was no hand-drawn art.  It was a careful construction created using Martin’s techniques, and it changed my career.  I was promoted and over time, I was leading a team.  I wanted to bring Martin back to our group to do another one of these fantastic workshops, so that more of us could learn his techniques.  I was willing to teach it myself if I had to.

A book is born

My goal was to put on a workshop for the entire Enterprise Architecture team within Microsoft IT.  I reached out to Martin and asked if he had ever updated those PowerPoint slides.  Thus began a series of meetings that morphed into a book proposal.  We planned to create something visually interesting, to use our own ideas to tell the story of how use these ideas.  Martin reached out to a friend of his, Mark West, a talented artist and designer that had worked with Martin on creating some of his training materials.  Mark was familiar with the process because Mark had lived it.  And he can draw.   (I’m understating rather wildly.  Mark has spent time as an art instructor at a college in Seattle, in addition to running his own design firm.  Mark is a change agent who masquerades as a very cool designer.)

During those early days, we simplified and clarified the process of creating a visual story, and we called it “CAST.”  CAST is an acronym for “Content, Audience, Story, Tell” which are the four stages of the process.  We created a simple “canvas” that anyone can use.  During this past year, Martin has put together a couple of workshops in other parts of the company and has used them to work out the bugs.  We call this canvas  the “CAST model” and I have completely adopted it.  It’s like a simple visual checklist that helps you remember and iterate through the steps to creating a visual story.

We still haven’t done that workshop for Microsoft IT.  We decided to create a book that we could both use to teach anyone we wanted.  We decided to focus on using these skills to simplify the process itself, and to make it easy for folks who, like me, are not artists.  Note: in a professional setting, on projects that are funded to create compelling information, I strongly recommend enlisting the help of a visual designer… but for your own use, to explain your own information, you can follow the CAST process to do the trick.  Just like I did.

The long slog

Anyone who walks the road from idea to a complete book knows that it can be a difficult and time-consuming effort.  We had our moments when each of us thought that this whole thing was nuts.  After all, there were so many good books already on business storytelling and good design principles.  Couldn’t someone just read those books? 

They could, but what I got from Martin, in that workshop in 2007, was not in any of those books.  Martin didn’t change my career with a collection of art tricks and bits from a dozen books.  What Martin gave me, and what we wanted to give our readers, is a simple step-by-step process that a non-designer could follow to create a USEFUL and COMPELLING single-page visualization.  Not high art.  High value.

We knew we had something unique… something that none of the other books and authors and workshops had built.  We had something that the non-artists among us could use to be compelling and useful.  We had a book about change, and making change happen.  We had a book about stories, and using those stories to drive big changes, huge changes… using those stories to MOVE MOUNTAINS.

Most of the text was written between November of 2011 and May of 2012.  Most of the artwork that infuses this book, on every single page, was created in the spring and summer of 2012.  The book is compelling and visually beautiful.  We treated every single pair of pages as a two-page layout, and each was hand constructed by Mark West.  Our publisher, Wiley and Sons, created a new team, with about twice the normal book staff, just to assemble it.  Wiley knew we had something unique, and they were willing to take a real risk on it.  Our team at Wiley did a fantastic job.  I’ve been a co-author before, but never had an experience anything like this one.  The level of communication, collaboration, and shared iterative design was simply unprecedented.  The Wiley team moved a mountain as well. 


Sample of a two-page spread used in the book Stories That Move Mountains

What you will get out of this book

In case it’s not clear already, we want this book to be practical and useful.  This is NOT an art book, even though there is one chapter that focuses on detailed visual elements like fonts, colors and layouts.  This is not a typical business book either.  There are no long expositions on financials or sales strategy or performance measurement.  This is a
book about change, and it is for ANYONE that wants to influence another person to lead a change. 

What you will get out of this book is a step-by-step process to follow that results in a visual story.  We walk you through numerous examples, showing how we use the CAST stages to create visual stories and there is a final chapter that literally goes end-to-end in creating another visual story.  We provide advice, and hugely valuable nuggets from a dozen other books that fill out shelves in mine and Martin’s and Mark’s libraries. 

imageOur references chapter is also a simple, clear, layout that focuses on a small and manageable list of excellent books for you to use if you want to “go deep” on any part of the process (you won’t have to, but just in case you want to).  We are also committed to continuing the conversation on the book sister-site http://StoriesThatMoveMountains.com where all three of us blog and upload resources (including a downloadable CAST model template, like the one on the right).  You can also find us on Facebook for a more socially-oriented conversation (www.facebook.com/storiesthatmovemountains) as well.

It should come as no surprise that both Martin and I are Enterprise Architects.  The biggest value we offer our clients is helping them to build the case for change.  But change can be anything.  You could be changing a business, or a team, or a family, or even yourself.  You can create a visual story for nearly any situation where you want people to remember, and connect, with your case for change.

Yep, it still works

I’ll give you an interesting example.  I am currently volunteering my time to a professional organization called the “Center for the Advancement of the Enterprise Architecture Profession” (or CAEAP, pronounced “seep”).  Through that organization, I have been assigned, by CAEAP, to work with another professional organization that they partner with: the “Federation of Enterprise Architecture Professional Organizations” (or FEAPO, pronounced “FEE-poe”).  I’m working on creating an industry-wide perspective on Enterprise Architecture.  I went to a FEAPO meeting just last weekend where I was working with people, in person, that I’ve only met one time before.  They were all aware of my project, of course, but it was not, and is not, their primary focus.  I couldn’t be sure that they remembered anything from the last time we’d met, in February.  I decided to use a visual story to frame what would have otherwise been a boring status update. 

imageOn the plane flight from Seattle to Fort Lauderdale (five hours in coach, on a red-eye overnight flight), I filled out the CAST model and created the entire presentation.  (I had no internet access on the plane, so the graphic images I used were all on my PC hard drive).  The moment I landed, I drove to FedEx Kinkos, printed the visual story on nice, sturdy, 11×17 paper, and drove straight to the 8:30am meeting.  When it came time to present, I handed out the sheets and we turned away from our screens and spoke to each other instead.

Later that evening, as we sat eating dinner at an upscale Surf-and-Turf restaurant, they were reciting back to me the humorous bits of the story that I told.  The story stuck.  It was memorable.  As a result, everyone has a good idea of what I need from them, and what they need from me, because we had a simple compelling visual story to work from.  (I’ll see if I can get a link to that document made available so that you, gentle reader, can see it.  A thumbnail is on the right).

So yes, I think you should buy this book.  I’d say that even if I didn’t help write it, but I did.  This is our way of saying: it’s time to change the world.  This is our mountain to move.  Join us.  The world needs change agents to be effective.  You are a change agent.  If we help you become just 5% more effective, what hurdles will you overcome?  What innovations will you introduce?  What problems will you solve? 

These are interesting times. 

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.

Many (flawed) Definitions of Business Architecture

By |2012-09-11T02:59:00+00:00September 11th, 2012|Enterprise Architecture|

Not long ago, I attempted to create a refined definition of “business architecture.”  I felt compelled to do so because the definition that I found in the Business Architecture Guild’s BizBOK (Guide to the Business Architecture Body of Knowledge) defined the word “business architecture” in terms of an artifact (a thing).  In my eyes, that “thing” already had a name, and creating a new name for an old thing, while forgetting the practice that creates part of it, seemed like a mistake.

Literally, within minutes of posting a question on LinkedIn about my definition, I found that there had already been a raging debate about the definition of the term “Business Architecture.”  (egg on my face).  So I went through that other discussion and picked up the various definitions I found there.  I also scanned the web looking for additional definitions, and found a few. 

The list of definitions that I found is copied here.  Note that, at the bottom of this post, I will make some observations about these entries and what it says about the maturity of our definitions.  If you’d like to skip the list of definitions, I encourage you to scroll down and look for the analysis.  The surprising conclusion (I’ll spoil the surprise) is that every one of them is flawed, including mine.  Read on.

List of definitions of business architecture

Below is a list of various definitions of business architecture, drawn from a LinkedIn Discussion in the Business Architecture Community, started by Terry Roach.  This list was extracted from LinkedIn on September 9th, 2012.  In addition to the discussion on LinkedIn, I searched the Internet (using Bing, of course) to find additional definitions.  Note that if a definition is cited in multiple locations, it appears in the table below only once, citing the original source.

For each definition, I captured its source and two attributes of the definition: the scope and the perspective.

Scope: The definitions tend to vary about whether they describe one or more of these three aspects of business architecture:

  • Contents – Treats Business Architecture as a noun and describes the contents of it.
  • Purpose – Describes the reason for either performing or creating a business architecture.
  • Activities – Describes some of the activities that intersect the performance of, or management of, business architecture.

Perspective: Each definition takes one of these two perspectives: Either Business Architecture is a thing or a process.   





Terry Roach



“A business architecture articulates organisational objectives and associated strategies in a conceptual model of the domain, the behaviour and the governance of business operations. “

Bruce McNaughton



“The business strategy, governance, organization, and key business process information, as well as the interaction among these concepts.” (derived from TOGAF)

Sunil Muduli

Contents, Activities


Business Architecture is about Modeling/Capturing Business Motivation, Capability, Process (Level 0 & 1) and People(Role/Responsibility)

Rubina Polovina

Contents, Purpose


Business Architecture—A model of real-world that contains discourse relevant for an IT-intensive endeavor (or, simply, IT endeavor)

OMG Business Architecture Group

Contents, Purpose


a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands. (Bizbok 2.1)

Tim Blaxall

Purpose, Activities


Business Architecture helps to implement our business strategy by designing the developments needed in the way our business operates

The Open Group Architecture Framework [TOGAF]



Overview: The Business Architecture defines the business strategy, governance, organization, and key business processes.

Definition: A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs. (TOGAF 9.1, Section 3.22)

Taurai Christopher Ushewokunze



Business Architecture is the process of planning, designing and implementing macro level to micro level business structures at a minimum it defines the relationships between finance, marketing, operations and technology.

Nick Ananin



Business Architecture is the process and outcomes of planning, designing and building a system that delivers tradable products (goods, services etc) that are of value to customers.


Definition of Business Architecture = “An architecture applied to a business system”.

Michael Poulin



Enterprise Business Architecture is architecture that comprises business functionality and business informational models, positions itself across business administrative and organisational enterprise structures, and that transforms goals and objectives defined in a business enterprise model and refined in the Strategic Business Plans into the functional and informational definition for a corporate business

Joanne Dong

Contents, Purpose


Business Architecture is a holistic set of descriptive representations of the different components of the business and their relationships. The purpose of a business architecture is to ensure proper alignments and integration among the components.

Ralph Whittle



Informal: the Business Architecture is a blueprint of the enterprise built using architectural disciplines to improve performance.

Formal: The Business Architecture defines the enterprise value streams and their relationships to all external entities, other enterprise value streams, and the events that trigger instantiation. It is a definition of what the enterprise must produce to satisfy its customers, compete in a market, deal with its suppliers, sustain operations, and care for its employees. (Source)

Tim Manning

Activities, Purpose


Business Architecture is a discipline and set of methods for the holistic design of organisations. The architecture of a business is “the arrangement of the functions and features that achieve a given set of business objectives” (adapted from King, 2010).

Sam Holcman

Purpose, Activities


Business Architecture is explicitly representing an organization’s desired state and as-is state, through a set of independent, non-redundant artifacts, defining how these artifacts relate with each other, and developing a set of prioritized, aligned capabilities needed to meet the organization’s goals, communicating this understanding to stakeholders, and advancing the organization from its as-is state to its desired state. (BACOE, EACOE)

Nick Malik

Activities, Purpose


Formal: Business Architecture is
(1.) 1. A specialization of the Enterprise Architecture business function that collects and manages functional, structural, and motivation-related information using a rigorous scientific and engineered approach for the purposes of business design, functional improvement, motivational alignment and decision support.
(2.) One of the four traditional domains of Enterprise Architecture.
Informal: Business Architecture — A specialization of the Enterprise Architecture business function that uses science and engineering to design and implement business functional and process improvements and strategically-aligned change initiatives.

Derek Miers (Forrester)

Activities, Purpose


An organized and repeatable approach to describe and analyze an organization’s business and operating models to support a wide variety of organizational change purposes; from cost reduction and restructuring, to process change and transformation.

Art Caston (as cited by Dave Woods)

Activities, Purpose


Business Architecture supports business opportunity assessments, strategy development, and business transformation program planning by creating various business reference models, populating these reference models with current business information, and creating integrated target architecture models to show future market positioning, product and service capabilities, enterprise structure and responsibilities, and proposed business partner relationships. These target models are used by related business planning functions to structure, organize, and govern related transformation programs.

IASA (as cited by Kevin in comments below)



A business architecture is a part of an enterprise architecture related to architectural organization of business, and the documents and diagrams that describe that architectural organization.

Ben Gray

Contents, Purpose


A business architecture [noun] helps a client (the business owner/director) to better understand the landscape (business environment, context, or market); understand their choices and constraints; and articulate their vision (requirements) such that designers (of processes, roles, systems, apps, etc) can create a coherent set of artefacts that can be used to plan and build/buy and test against


Analysis of the definitions of business architecture

The first thing to notice is that there are PLENTY of definitions of business architecture.  I have listed seventeen (20) definitions above from seventeen (17) people.  If I find more definitions, I may add them to the list, but I probably won’t update the numbers in the analysis below (too much hassle).   It is interesting to note that very few of the respondents referred to a pre-existing definition from a reliable source (like TOGAF, OMG, or Forrester). 

I did a little categorizing as I went, and you can see that effort in the table above.  The reason for doing the categorizing is to understand what the community considered important to include in a definition.  Think about that for a minute.  A definition captures the important distinctions of a concept, sufficient to clearly differentiate that concept from other, potentially similar, ones.  Definitions “should” be minimal, but they don’t have to be.  The folks who contributed were not trying to make a perfect definition.  They were trying to provide all the information that they found important.  So let’s look at what the contributors found important.  Of the 20 definitions provided, the numbers were VERY evenly split…

Definitions Containing Activities Purpose Contents
  10 10 11

As for the other attribute, it highly correlated to the numbers above.  Everyone who described business architecture in terms of “activities” was describing a process.  All other definitions described a thing.  The number of definitions was EVENLY SPLIT between the two.

Definitions describing a Process a Thing
  10 10

(Note: Sunil described the process of capturing contents without describing where those contents would go.  Therefore, his definition described activities and contents, but still described a process.  Hence, the number of definitions describing contents does not equal the number that describe business architecture as a “thing”)

What can we draw from this: of the respondents to that thread on LinkedIn, and from various sources around the Internet, there is NO CONSENSUS on whether business architecture is a process or a thing. 

Since a definition describes how a word is used, and is NOT a reflection on what we want it to mean, and given that 20 different definitions submitted describe the term in two different ways… I would consider it likely that the term is used in both ways (both as a process and as a thing). 

Next Steps

Assuming that my analysis is correct, EVERY SINGLE DEFINITION ABOVE IS WRONG (including mine).  All of them define business architecture in terms of either a process or a thing.  Not one define the term to have two meanings.  Yet the term ‘business architecture’ clearly has two meanings!

My suggestion to the reliable sources for the definition of business architecture: update your definition to include both sides of this coin.  I will do the same.  Note that I will not update the numbers in the analysis to reflect that change. 

Taking a Careful Slice – Defining Business Architecture

By |2012-08-27T07:23:00+00:00August 27th, 2012|Enterprise Architecture|

I’m putting together my presentations for TechEd New Zealand, one of which is titled “Business Architecture for Non Architects.”  In that presentation, I need to provide a good, SHORT, definition of business architecture.  So, like a good soldier, I marched over to the Business Architecture Guild and dug in to the Business Architecture Body of Knowledge (the “BizBOK”), which defines Business Architect in this way.

“A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”
– Business Architecture Body of Knowledge Handbook 2.1, Business Architecture Guild

I copied this definition into my deck and went on.  Then, as I came back and practiced the presentation, I hit this slide and realized, to my horror, that I do not think this is a very good definition.  Why?  Because of the problem of two parallel phrases: business architecture, and business architect.

Is the business architect responsible for describing the business architecture?

Here’s the problem with the BizBOK definition…  The field of Enterprise Architecture clearly includes four domains: business architecture being one of them.  Enterprise Architecture is accountable for creating a complete description of the enterprise, useful for many things.  One of those things is for the alignment of strategic objectives and tactical demands.  Therefore, to use the “model, viewpoint, view” language of the ISO 42010 standard definition of architecture, we would say

    • Model == Enterprise Architecture
    • Viewpoint == Concerns of Business Stakeholders
    • View == Business oriented architectural artifacts

Therefore, the “blueprint of the enterprise,” is the Enterprise Architecture.  There is no distinction between the “architecture of the enterprise” and the “blueprint of the enterprise.”  These concepts are identical.

Who creates the Enterprise Architecture?  All of the domains do.  Business Architects contribute, but so do Information Architects, Application or Solution Architects, and Technology Architects.  Non architects contribute as well, including process engineers, sales managers, product managers, relationship managers, and others.  A few business architects are involved.  In most organizations I’ve had contact with, business architects do not lead the effort to create the enterprise architecture. 

Conclusion: the BizBOK 2.1 defines the concept of “business architecture” in terms of an artifact that business architects do not create!  That seems a bit exuberant.  It’s a little like saying that “bricklaying is the act of building a house out of bricks.”  Um… no it isn’t. 

What is the role of the business architect?

A Business Architect is one of the four well-defined “domain” architects under Enterprise Architecture.  The other three are: Information Architect, Solution or Application Architect, and Technology Architect.  These different domains are supposed to represent “layers” in an outdated model.  While I reject the entire notion of “layers” or “tiers,” I understand that these terms have become embedded in business over the last two decades.

I’m on the fence about the value of even employing “domain-specific” architects, especially in smaller firms or at the program level.  I believe that, in many cases, a good generalist Enterprise Architect is probably the most effective use of resources and training.  That said, I understand that many large organizations have created specializations around each of the domains, with some folks being “Information Architects” only, and others as “Business Architects.”  I even wrote a job description of a business architect a number of years back that proves popular today.

That said, as we define the “activity” of business architecture, I believe we should remain clear that business architecture is an application of enterprise architecture… a careful slice of general EA skills with a focus on meeting the needs of only one of many levels of the architecture.  That level, the business level, meets the needs of different stakeholder groups (multiple business viewpoints) like strategy development, strategic alignment, process improvement, innovation management, and organizational development.  But the business viewpoints are deeply integrated into the unified model of the enterprise, one that is not complete or effective without the viewpoints of the other domains.

The role of the business architect is therefore to develop specific architectural artifacts needed to meet the concerns of business stakeholders.  Those artifacts are derived from the model of the enterprise (the enterprise architecture) which evolves as they go.  Many experts suggest (and I agree) that it does not make sense to develop the EA model as a standalone artifact, but rather to develop the parts of it that are needed to meet immediate concerns, use the model to meet those concerns, and move on to the next concern, building the enterprise architecture model as you go.   This iterative approach works well and keeps enterprise architects out of the proverbial “ivory tower.”

Clearly the concerns of the business stakeholders include “aligning the strategic and tactical demands” of the enterprise.  I would not LIMIT the scope of enterprise architecture to this one concern.   This is the other problem I have with the BizBOK definition… it is limited to alignment only.  Perhaps that was intentional.  I have not asked.  But it is clearly limiting.

How does that role affect the definition?

A couple of years ago, I defined Enterprise Architecture as a single term with three definitions.  (That’s pretty normal, if you think about it).  One of the definitions was “A rigorous model of the motivations, structures, information, processes, and systems of an enterprise created for the purpose of decision support.” 

[Updated 11 Sept 12] That model is the enterprise architecture.  Therefore, in order to create a non-overlapping and complementary definition for business architecture, I wanted to remove the artifact from the definition.  However, clearly some members of the community used the term “business architecture” to refer to part of that model.  So I left in the notion of an artifact, but defined it as a subset of the larger enterprise architecture artifact.   

[Updated, 5 Sept 12] I am considering two “definitions” at this time.  One is a full definition that provides the necessary and sufficient differentation needed to create a reasonable understanding of the term.  The other is a shorter definition useful in a business context. 

The definition I’m considering at this time is:

Business Architecture is

1. A specialization of the Enterprise Architecture business function that collects and manages functional, structural, and motivation-related information using a rigorous scientific and engineered approach for the purposes of business design, functional improvement, motivational alignment and decision support. [Updated, 5 Sept 12] 


2. A subset of the architectural description of an enterprise sufficient to produce models that meet the functional, motivational, and alignment concerns of stakeholders. [Updated 11 Sept 12]

And the short, “useful” definition is this:

Business Architecture — A specialization of the Enterprise Architecture business function that uses science and engineering to design and implement business functional and process improvements and strategically-aligned change initiatives.  [Updated, 5 Sept 12]

There it is… a careful slice.  I look forward to your (continued) feedback. 

Podcast on the Enterprise Architecture profession–Interview with CIPS’s Stephen Ibaraki

By |2012-08-26T14:53:46+00:00August 26th, 2012|Enterprise Architecture|

Way back in April, I announced the first of two podcasts with the Canadian Information Processing Society.  I just realized this weekend that I had not announced the availability of the second of those podcasts.  Error corrected.

The second podcast, once again hosted by the inimitable Stephen Ibaraki, focuses much more on the growth and progress of the Enterprise Architecture profession itself.  Specifically this podcast reflects upon:

  • The role of Business Architecture in Enterprise Architecture?
  • Does an Enterprise Architect have to be able to discuss technical issues like cloud computing?
  • How would you define Enterprise Architecture?
  • The value proposition of the Enterprise Architect?


For full details, and a link to the podcast, visit the Canadian IT Manager’s Connection, a TechNet site. 

The EA Metamodel behind the Business Model Generation

By |2019-08-27T17:41:13+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.

Aligning the EBMM with Archimate

By |2012-08-10T11:57:00+00:00August 10th, 2012|Enterprise Architecture|

I just recently had a conversation with a talented enterprise architect who had brought together the EA framework elements from numerous different sources in order to address the needs of his business.  Included in that list was the Enterprise Business Motivation Model which I developed and which I continue to maintain.

He reminded me of one of the bits of feedback that I’ve been given over the years, and that is “integrate the EBMM with other frameworks.” 

The challenge I have with that is that many other frameworks don’t have a metamodel.  The EBMM is a business architecture metamodel.  Of course, that is a quickly vanishing excuse.  The open group is largely using Archimate for their metamodel these days, and other frameworks have had metamodels from the start.  So it is time to get off my back and start taking a look at how the EBMM relates with, or differs from, standard metamodels.

I’m starting with Archimate?  Why?  Because it is at the right level of abstraction, fits well with the gaps in the EBMM (in the IT space, where Archimate excels, there is nothing in the EBMM), and allows a good relationship with tools implementation.

So over the course of the next few months, in my copious spare time, I’ll be diving in on Archimate and trying to improve my skills there, and find the ways to connect it to the EBMM.  If you have insight that you can share, please let me know.

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.