/Tag: Frameworks

The European EABOK and Enterprise Architecture Pattern Catalog

By |2016-10-19T20:36:47+00:00September 24th, 2016|Enterprise Architecture|

A number of years ago, I joined up with a small group of architects determined to create an EABOK (Enterprise Architecture Body of Knowledge).  We got off to a good start and I even bought the domain (eabok.org).  However, the Mitre Corporation (a federally funded research and development corporation) trademarked the name before we did, based on a white paper they had released in 2004.  I was out-lawyered.  So the name was theirs.  They wanted to do an EABOK as well.


Alternatives to the EPSC Model

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

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

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


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

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

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

Why do we need alternative models?

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

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

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

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

The Dynamic Collaboration Model

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


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

What other models exist?

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

What does this matter?

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

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

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

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


Your thoughts?

Climbing the ladder from EITA to EA

By |2014-03-10T13:50:59+00:00March 10th, 2014|Enterprise Architecture|

One of the most common problems in Enterprise Architecture, and one I get asked about routinely, is the “ladder” problem.  Many Enterprise Architecture teams are formed by assembling a group of talented technologists into a team and giving them a charter to “go do EA.”  The problem is that most of these teams have no credibility outside the technology group, and cannot really operate as a “bridge between business and IT” if they don’t have the relationships and knowledge that they need to be an Enterprise Architect.  Building those relationships and that credibility takes time… sometimes many years.  Until they make that transition, the team is an Enterprise IT Architecture team (EITA) and while that is useful, the value proposition of EA remains unfulfilled.

I call this “climbing the ladder” from EITA to EA. 

While the entire team should work on this, only a few will succeed.  Good news: That’s all you need.  However, it’s important that everyone makes the attempt to climb the ladder.  As a manager, I have no magic “test” to determine, for certain, which member of the team will make the transition and which won’t.  I once thought I did, but reality proved me wrong.  So everyone makes the attempt.  Those who remain EITA’s can continue in that role for the EA team, or they can transfer to a different group where their technical skills are valuable and needed.

So, how is this done?  How does an individual EITA climb the ladder?

You need four things:

  1. business knowledge
  2. empathy (and good reflective communication skills)
  3. courage
  4. air cover

Business Knowledge

Business knowledge is the one that should, on the surface, be the easiest of the three to acquire.  Unfortunately, it seems to be one that is sorely lacking among EITA’s who are attempting to make this transition.  What do I mean by business knowledge?  I mean the ability to understand the basic concepts of business at a working level.  In other words, can you answer these questions coherently:

  1. Explain the difference between value and cost from the perspective of the provider of a product or service
  2. For Contoso in Q4 CY2013, they saw sales to new customers increase while market share decreased.  Explain.
  3. Give an example of a disruption in bricks-and-mortar business triggered by mobile computing
  4. When your company acquires another company for cash, explain how the balance sheet is impacted
  5. Explain how opening a new channel for your customers can result in a decrease in sales
  6. Give an example of a good strategy that failed in your industry or market.  Why did it happen?

Where do you get business knowledge?  There are a gazillion books that will give you the basics.  Universities are helpful as well.  With the wide array of support, Enterprise IT Architects should have no difficulty learning these things… yet it’s startling how many don’t.  I have some friends who insist that an MBA is needed.  I disagree with that, but college courses do help.  I hold out the most hope for success with a blended program like that offered by the Enterprise Architecture degree at Pennsylvania State University. 

Empathy and Communication Skills

There has been a good bit of ink spilled about technical topics: mobile platforms, SOA, security, etc.  These help with the EITA side of the job.  But they don’t do much for the architect who needs to climb the ladder.  To successfully make that move, most architects need to invest in training on their soft skills.  This means building up the following:

  • Listening – Can you elicit the emotional context behind your stakeholders strategies and goals?  Can you truly “hear” them?  There are courses, and books, and online videos, that can help you to become a more conscious listener.  Not only will this help you climb the ladder, it will also help you in your relationships with family and friends. 
  • Empathy – The art of empathy in business is one where you feel as your stakeholder feels.  Don’t confuse with sympathy.  Big difference.  Empathy is a selfless act, and your ego has to be put into check if you are going to learn empathy.  There are many folks in architecture who struggle with ego, ambition, and condescension.  I struggle as well.  But if you don’t tame this beast, and build your capacity for empathy, your stakeholders will have a difficult time connecting with you.  As the old saying goes: They won’t care what you know, unless they know that you care. 
  • Negotiation – You will be frequently called upon to find a way for two people, with different perspectives, to come to a solution where both people “win”.  These “win-win” solutions form the basis for successful endeavors of many kinds, not just in business.  But if you don’t know how to negotiate, your usefulness as a bridge-builder is seriously limited. 
  • Positional Awareness – this means the ability to “see” how the organization works from various perspectives, and to position yourself, and your value proposition as to provide you the ability to influence that system.  It also means being aware when other folks are doing the same thing, which has the effect of changing your landscape out from under you.  Some folks call this “politics.”  I call it necessary.
  • Selling – Yep, I said the dreaded “s” word.  Many architects view “sales” as a dirty word.  After all, Sales people use emotions, leverage relationships, and often don’t even understand the details of what they are selling.  The sale is more important than the actual people!  Ouch.  It’s true.  Sales professionals are often competitive individuals who have been known to compromise their integrity for the sake of the transaction.  But that doesn’t mean that the tools and techniques of sales aren’t useful, or effective, or critical to success.  These techniques are mission critical.  So take professional training in sales.  How to hook a lead.  How to build excitement.  How to connect to your stakeholders’ underlying motivations.  How to use emotion to communicate.  How to ask for the sale.  How to follow up.   The use of color, design, and simplicity to convey a message.  All of that. 


Did you know that courage can be learned?  I guess I always knew it was possible, but I never really considered it until I found myself with a situation where I needed to use courage, and needed others to do the same.  I was playing the role of a SOA architect, and I needed to convince development teams and technical architects to adopt a set of patterns that would help the enterprise, but may actually add complexity to their own project.  I needed to walk into rooms and see if I could demonstrate, convince, cajole, argue, and/or negotiate my way to changes that were not in the obvious best interests of the team itself. 

I taught myself courage.  I taught others courage as well.  Part of teaching, and learning to be courageous, is to put your efforts into perspective.  See your work as necessary to a “bigger picture” and be very aware of how much you can get away with before others decide that they cannot actually follow your lead or support your efforts.

Courage is not the lack of fear or operating outside of dangerous situations.  It is the conscious choice to move ahead despite danger.  As the Will Smith character in “After Earth” tries to teach his son, “D
anger is real.  Fear is a choice.”  Sometimes, as an Enterprise Architect, you will have to tell someone powerful something that they don’t want to hear.  The situation can end badly, impacting your ability to continue working as an Enterprise Architect, or worse, resulting in you losing your job.  These dangers are very real to many EAs. 

Courage means that you will need to move ahead anyway.  It does not mean you should be reckless in the face of danger.  It is OK to be cautious at times.  But real success often requires boldness, and your bold actions cannot be made without the courage of your convictions.      

Air cover

There is a difference between “being courageous” and “being stupid.”  The difference is support: do you have the support you need, by someone higher up the food chain, to take on the challenge of climbing the ladder in most organizations.  This support from above is critical to your success.  I call it “air cover” (a reference to a military situation where ground troops can request a deadly strike on an enemy to be dropped from planes, missiles, or artillery). 

In a business setting, air cover means that you have successfully convinced leaders in various places around the company that you can be trusted.  They believe that you are valuable and that your motivations are in the right place.  So when a problem occurs, or one of your standards is challenged, or your roadmap makes a stakeholder angry, that leader can step in and sooth sore egos. 

I cannot indicate the importance of air cover.  For architecture managers, if you don’t provide air cover for your team, you are worse than an ineffective leader… you are a disgrace.  And for architecture practitioners, if you don’t build the relationships you need to build so that you will have the air cover when you need it, you are not being courageous.  You’re being stupid, reckless, or chaotic (take your pick).  To climb the ladder, someone has to be holding the ladder.  That’s your air cover. 


Climbing the ladder is a difficult challenge for any Enterprise IT Architect (EITA).  It takes dedication, support, and some significant innate abilities.  However, for many who take on this challenge, the rewards are excellent.  I truly love Enterprise Strategy Architecture.  I hope to see many of you “in the trenches” with me, fighting to make our ecosystems healthier, stronger, and more agile every day. 

Caveat: certification and frameworks

You’ll notice that I never mentioned Certifications or Frameworks in the discussion above.  That’s because I’ve met and known hundreds of Enterprise Architects.  Certification was only useful to make them more effective as an EITA.  It made no difference for climbing the ladder.  Certification will help with some skills and a great deal of knowledge.   A certification may build confidence, reduce churn in your team, and make your results easier for others to read and follow.  I’m not putting down certifications.  I’m just pointing out that this step comes with experience, not certification.  At least, not yet.

Technorati Tags:

The Purpose of an Enterprise Architecture Framework

By |2013-10-14T23:15:00+00:00October 14th, 2013|Enterprise Architecture|

Can Social Media create new ideas?  Here’s an example where the answer is “yes.” 

I recently blogged about EA models, and what makes them interesting.  I was thinking about providing insight to people who were in the mood to send me updates to the EBMM… a rather tactical post to deal with a rather pedantic an uninspiring issue: logistics of change.  On Twitter, however, a discussion broke out among rather distinguished architects that took the logic of my post to it’s natural resolution, and it was well beyond my limited thinking to have considered it when I wrote the original blog post.  In other words, they read my post, added insight, and create a novel idea, derived from mine, that I had not considered.

It started with consummate twitter user Mark Nielsen (manielse) noticed my blog post and recommended it.  Tom Graves retweeted Mark’s comment and added his own.

@tetradian: MT @manielse: By @nickmalik: What makes models interesting <<blog link>> #EntArch >important for all EAs

Richard Veryard then added his own interpretation, restating the premise of my last post.

@richardveryard: #entarch @tetradian @manielse  @nickmalik implies purpose of model is to answer specific set of questions – support a given reasoning process

Tom then did something really interesting.  Using a little judicious editing, he create a new conclusion: one that I did not make in my post.

@tetradian: @richardveryard “implies purpose of model is to … support a given reasoning process” – yes, agreed / @manielse @nickmalik #entarch

And there we go into new territory.  Richard caught an implication from my reasoning that I had simply assumed, without examining or testing.  Tom then took that implication and used it to reach a higher implication, and called it out in the open.  So let’s examine that resulting implication and then apply that logic a bit further to see where it goes.

The purpose of a model is support a given reasoning process

My prior blog post focuses on the questions that you want your model to answer.  You create a model to answer a question.  If you don’t know what the question is, you won’t answer it (or you will bury your answer in details that are not pertinent to the question).  So first ask the question. 

But why are we asking a question?  This is the leap that Richard and Tom took.  Let’s understand that asking questions, for their own sake, is a rather detached activity.  Enterprise Architects tend to live a little closer to the practical world than that, so we are asking questions that are useful, not just interesting.  And what makes a question useful?

We ask a question, and model the answer, for a couple of reasons:

  • We want to guide thought in ourselves.
  • We want to guide thought in others.
  • We want to answer a question asked of us.
  • We want to examine the results of asking a question that we find particularly interesting.


Note that I did not say that we are guiding action.  We are guiding thought.  In some cases, thought precedes action.  In other cases, not so much.  But the role of the Enterprise Architect may be to suggest action, and it may include overseeing that action to ensure alignment to goals, but Enterprise Architects are rarely the driver of action.  Someone else funds the action and drives for conclusion.  We are the people who guide thought.  If we were living in a feudal society, we are not the King… we are his advisors. 

The idea of “supporting a reasoning process” is clearly the first two bullets.  We want to guide thought.  We are walking through a reasoning process, either for our own decisions or for the decisions we will lead others to (sometimes both at once). 

Tom’s edit takes on new ground because he allows us to draw a meta-conclusion: that ultimately a model may lead us to a reasoning process when we were not actually planning for it to.  This is the fourth bullet above, and one that I wasn’t really considering when I wrote the post.  What if we don’t know where the model will lead, until we create the model?  What if we are simply modeling because doing so is literally a form of reasoning in itself?  What if we can ask questions of the model that we didn’t think were relevant and wouldn’t have bothered asking, but can only ask because we have the model to answer it?

Now, to extend the thinking just a bit.  What is an architectural framework?  While there are many definitions, there is one possible definition I’d like to propose: an architectural framework is composed of a reference model describing the essential elements of a system, and a series of methods for building instance models within that reference model.  In other words, a framework is a model and the tools to use it to build more models.

The Purpose of a Framework

If the purpose of a model is to support a reasoning process, then, by extension, the purpose of a framework is ultimately to support a particular theory of organizational evolution. 

This notion flies in the face of most framework development efforts. 

Taxonomic transformation, like that proposed by Zachman fans, is a model-driven design approach to mostly IT solutions.  The descendants of TAFIM, including TOGAF and DODAF, follow a methodological approach that builds from a solution standpoint, but which supports the core concept of a single-page enterprise architecture.  Service oriented frameworks like MODAF, FEAF and NGOSS are somewhat middle out, with the core concept being composability of services.  Business oriented frameworks tend to focus on classification of motivations, and usually start with some kind of metamodel like the OMG BMM, the BMGen canvas, or my own EBMM.

Under here are the theories of evolution of a successful organization… but it will take a little archeology to figure out what those theories really are.  Just as we can look at the remnants of cultures long passed and deduce elements about the way that those people lived, we can look at frameworks and deduce the ideas that the framers of the framework had about how organizations could, or should, or must develop. 

Frameworks, like models, are designed to answer a specific set of questions.  But more than that, they are designed to support a logical train of thought from understanding of a situation through proposing a pathway through it to meet a vision of success.  If your organization can only really support one fundamental approach, then you must choose the frameworks that can deliver on that approach in an effective way.

Consider these aspects of each framework.   Consider the idea that frameworks are an outward expression of inner assumptions.  Then, go looking for those assumptions.

If this is where we start, with the underlying assumptions, it is fairly easy to see why some frameworks are appealing to specific people and even corporate cultures, where others are not.  If the framework doesn’t support your view of organizational transformation and evolution, it is tougher to understand and apply it.  Your organization’s culture, politics, and history may end up doing more to help you to select an EA framework than you think.  After all, you can always extend a framework to include a method, but it is tough to deal with the problem of a framework that simply doesn’t support the way people in an organization think about themselves and their mission.

This is important because EA has been struggling for years to understand what the possible directions are for academic study and scientific examination.  Using this approach, we can refine and develop succinct theories of organizational development, merge similar frameworks, build commonalities among approaches, and even compare results of company development “in the wild” to see where these approaches lead.

And the Credit goes to…

Who authored the new idea?  Who cares.  I won’t take all the credit.  Perhaps it was first Richard Veryard riffing on my post and then Tom Graves creating a new idea by removing words. Perhaps I went to the conclusion after reading that edit.  I don’t know.   Perhaps it was just social.  Perhaps it is an idea that has already been proposed elsewhere.  I respect that possibility as well. 

Regardless, I think there is a real idea under here.  We have artifacts, real artifacts, to take to our original authors as well as social anthropologists and archeologists.  Let’s ask for analysis and intent.  Let’s find out what those underlying assumptions really are.  We may discover that there are underlying theories of organizational evolution upon which we can base the ongoing development of the EA profession.

The “Right” Representation of the EA Value Cycle

By |2013-04-29T17:10:58+00:00April 29th, 2013|Enterprise Architecture|

In the world of Enterprise Architecture, we are still creating “shared” understanding of how to tell our stakeholders what we do.  There is no consistency in our diagrams or our descriptions just yet.  This post will discuss the different ways we present the value stream of Enterprise Architecture and will attempt to select a particular viewpoint that can be useful for the majority of situations.

First, let’s address the most commonly shared representation: TOGAF.  The TOGAF ADM model illustrates a sequence of activities that starts with a preliminary phase and works its way through each of the levels of architecture.  Basically, TOGAF illustrates a straight-through process from phase A through phase H to develop and use architecture. 


First off, I’m no huge fan of this illustration.  I always wondered how you get to an architectural vision prior to considering the architecture of the business.  Also, the notion of a center point focused around requirements management feels weirdly tactical.  At the level of an Enterprise Architect, I’m dealing with strategies and measures of success.  At the level of a technical architecture, the word “requirements” has an altogether different meaning.  Grouping together the notion of “strategic needs” with “technical requirements” may make sense to a technologist, but I don’t know a single business stakeholder of EA that would agree with grouping those two rather distinct things. 

Who is our audience?

These observations bring me to my first key consideration: If we want to communicate the value stream of Enterprise Architecture, we first should consider the audience, “who are we communicating to?”  If we are communicating to a stakeholder of EA, we should show them the bits of EA that are relevant to them, and we should not show them the bits that are not. 

It is not cynical to gloss over the complex bits of EA when talking to a business stakeholder… it is practical.  In fact, we do it all the time.  If you buy cable TV services, a person from the cable company may come to your house and install a coax cable to your home.  He will mess around with a cable box for a few minutes, and then, if you are lucky, he will show you how to do simple things like changing channels and recording your favorite shows.  Then, he’s off.  He does NOT spend an hour describing the various technical aspects of signal transmission and digital carrier signals.  Why should he?  You don’t care.  You want to watch TV, not get a degree in electrical engineering.  And the same applies to EA.

Secondly, if we want to communicate EA, let’s recognize that different people interact with Enterprise Architecture in different ways.  Business stakeholders will interact with Enterprise Architecture to ensure that their strategies are being executed effectively, with minimal interference, and producing a result that considers things like security, cost of ownership, and the ability to cope with rapid changes in the marketplace.


  1. We have to care who we are speaking to, and we have to reflect the things that they care about.
  2. We have to show them the details that matter to them and obscure the details that don’t.
  3. We should illustrate the activities in the context of the processes that they understand, and not at a conceptual level that may be difficult to relate to their daily experience.


The ADM from TOGAF is an odd bird, because it attempts to be all things to all people.  It represents EA in a way that every stakeholder can use, but honestly, no stakeholder can use it.  It is not wrong.  Far from it.  But it is not useful because it violates every single one of the rules above.  The ADM reflects the EA viewpoint, but not the viewpoint of the customers of EA at a level that they can grasp, understand, and most importantly, use.  So let’s keep the ADM in our court, and create a view of the EA process that is relevant to our stakeholders.

So who are our stakeholders?  For the sake of this post, I’m going to select one set of stakeholders and ignore the rest.  Is that correct?  Nope, but it is practical for a blog post.  What this means is that the rest of this post produces an answer of the “right” representation only for one class of stakeholders… another representation would likely be needed for different people.  That is the nature of EA.  Let’s not fret it.

Stakeholders: Non-technologists

There is a widely held view in Enterprise Architecture that an EA must be technically savvy in order to be effective.  There are certainly business architects who are quite effective who are not technologists, but in order to move UP to the notion of an EA (which includes business architecture, information architecture, solution or application architecture, AND technology architecture), you would need to be technically capable. 

I won’t belabor the point about whether it is correct to view Business Architecture as a subset of Enterprise Architecture.  It is the wildly predominant view.  (A poll that I put on LinkedIn that asked this question found that well over 80% of EA respondents agree that EA generally includes every aspect of business architecture.  That’s pretty overwhelming.)

That said, our biggest struggles in EA rarely involve conversations with other architects.  While there may be a great deal of confusion, there is rarely a lack of buy-in for architecture among architects, or even technologists.  Our key challenge, when it comes to communication, comes when we are talking to non-technologists.  In other words, the proverbial “business” stakeholders of EA.  (Please don’t flame me about whether IT is part of the business or not. That is a useful conversation, but it is outside the scope of this post).

Therefore, for the rest of this post, I will focus on the non-technology stakeholders of Enterprise Architecture.  These are people whose chief concerns are not technical concerns.  We could say that they care about financial performance, role clarity, cycle time, cost effectiveness, market position, revenue growth, opportunity costs, business drivers, and many other factors outside the realm of technology concerns.  People in this category include senior business leaders (CEO, COO, CFO, CIO, CMO, etc), as well as business unit leaders (General Managers, Sales Division Leaders, Product Development and Marketing, Customer Service, Online Services, etc). 

In order to communicate directly and well to these folks, lets recognize that they don’t care about the aspects of architecture that are technology focused.  While the WANT good technology, and will BENEFIT from good technology, they will assume that the technology issues can be handled effectively without bothering them with details.  To refer to our previous metaphor, they want the cable compa
ny to handle the technology, so that they can deal with changing channels.

So, let’s take the ADM, and trim out the stuff that non technologists rely on, but don’t need to have a conversation about.  They assume it is there.  That includes the preliminary stage, as well as architectural vision, requirements management, information systems architecture, technology architecture, and architecture change management.

The ADM now looks a bit different.  In fact, we can put it in a single row with a looping arrow.  Note that, in TOGAF, the Business architecture phase includes both current state assessment and future state modeling.


Representing the processes of the non-technical stakeholder

We have removed the confusing bits from the view of the non-technical stakeholder, but it is tough to say that we are at the point where we are relevant.  After all, the non technical stakeholder has a business process that he uses when working with changes to his or her business.  We are not representing that process. 

The process, frequently described in dozens of bits of EA literature, starts with an understanding of the current situation within the business.  Then, when the business creates a strategy, we bring these two bits of information together (current state and strategy) to create a vision for the future.  This is the order that the non technical stakeholder may recognize… not the generalized view of the ADM.  So it is time to break apart and rearrange the bits a little bit.  I will now step away from the “crop circles” representation since it is so far out of the experience of people who describe business processes.


In this view, we can begin to see the steps that an Enterprise Architect would perform that are visible to a non-technical stakeholder.  Just for the sake of clarity, this doesn’t mean that the technical steps are absent… it just means that our technical efforts don’t have to be paraded around in front of our non-technical stakeholders. 

Note that I relabeled the ADM steps. 

  • Business Architecture becomes Current State Evaluation, and Strategy Development
  • Opportunities and Solutions becomes Future State Modeling
  • Migration Planning becomes Roadmap Development
  • Implementation Governance becomes two things: Funding and Initiation (the Project Portfolio Management aspects) and Oversight and Governance (the governance of ongoing activities).
  • Architecture Vision is cut down to only the elements relevant to the non-technical stakeholders: the evaluation of the current state of the enterprise.


Let me point out that the TOGAF process assumes a different order of activities than the diagram above.  From the standpoint of the stakeholder, this is what makes sense, regardless of how TOGAF describes the stages.  This is why I’m no big fan of TOGAF as a methodology.  It doesn’t reflect reality.  On the other hand, the elements above are fairly well understood. 

Also note that I’m not saying that the substitutions listed above are equivalent.  In fact, I’d argue violently that Business Architecture is far more than Current state evaluation and Strategy Development.  However, from the viewpoint of the non-architect, business architecture is a process that is involved with the development of business models (current and future), and that’s about it.  There is a great deal of effort that is not seen by the stakeholders.

In other words, the blue model above is only showing the tip of the iceberg, and relabeling the phases according to what is (approximately) visible, not what is actually there. 

This is an important part of explaining an activity to a stakeholder, and it is a skill that every Enterprise Architect must get good at.  You have to explain your activities in the context of what a stakeholder understand and recognizes… not in the context of all your work.  It’s not about you. It’s about the stakeholder.


The Rules of Value Streams

There are a few problems with the view above.  In order to understand the problems with that view, let’s mention a couple of rules for representing a value stream.  We will use these concepts because the ability to describe EA in terms of a value stream is important.  Value streams are sticky… they are easy to remember and easy to relate to.  If we want to remove the barriers to adoption of EA, we could do far worse than using this technique.  That said, there are some rules that we have to keep in mind:

  1. A value stream does not illustrate dependencies that are not really there.  Parallel efforts should be represented as parallel if that would improve understanding of how value is created.
  2. The value stream is illustrated as a sequence of high level processes in a straight line from left to right.  That said, a value stream must start with an event that is relevant to the customer who gets value.  It must end with the deliver of that value.  Any activity that is not part of that flow (from relevant starting point to value) should be represented “above” or “below” the value stream.  
  3. A value stream should be illustrated in its fully operational state.  In other words, it should describe a process that is running, not one that hasn’t been created yet.  Events that are relevant only for “start-up” activities can be included, but should not be the primary focus of a value stream.


So let’s apply rule #1.  Is it true that the current state of the organization actually feeds the development of strategy?  No.  In fact, the evaluation of the current state can happen completely in parallel to the development of business strategy. 

So the diagram could look like this one.


Here, we can see that there are, in fact, parallel activities for the understanding of the current state of the enterprise, and for the development of business strategy.  Where they first intersect is in the development of the future state (the opportunities and solutions phase from the ADM model).  You need both an understanding of the current situation and the needs of the future in order to describe where the organization should move towards. 

Now, let’s apply rule #2.  What is the event that the business considers to be relevant to start the value stream of Enterprise Architecture?  The Development of Business Strategy, of course.  So the flow should perhaps look more like the diagram below… (note, the arrows and activities are identical to the one above… the only thing different is the order on the page).


Now, let’s apply rule #3… that one is easy.  The arrow at the bottom that says “First TIme EA” can simply be dropped.  After all, the first time a process is run, it starts from somewhere.  It is simply irrelevant to the non-technical stakeholder to point out where that starting position is. 

Exception: if you run Enterprise Architecture as a consulting arrangement, you may want to leave that arrow in there.  After all, you will need to illustrate where the consulting arrangement will start.  That said, I have found that fewer and fewer EA initiatives begin with the hiring of a consulting firm. 

Providing context

When we started with the ADM, we assumed that there was a 700+ page methodology and framework behind the image, describing each step and what is included.  However, your stakeholder will not read the TOGAF or any other 700+ page body of information.  That would be absurd.  You need to add a little detail to the image to describe what is in each of these stages.

It’s also a good idea to “clean up” the diagram a little so that we use less space on the “arrows and boxes” and more engagement on the ideas of what is going on.  So the next modification of the process looks like this:


This diagram is a better one for informing the non-technical stakeholders of your Enterprise Architecture program about what it is that you do.  We remove a little of the “accuracy” about where an arrow starts and ends, but we add a great deal of context about what is happening along the way.

The “backward” arrow along the bottom clearly indicates that there are activities that flow outside the value stream but which are needed for each repeat of the cycle. 

Final words

Is this a perfect representation of the EA process?  I don’t believe in perfect things… just useful things.  But it is better, in my opinion, than showing a non-technical stakeholder the ADM or one of the “box and arrow” models above.  It uses the visual language of value streams and business process models, both widely recognized and used in business interactions.  It explains itself without going into a lot of detail.  And it clearly describes the end to end flow without restricting or dictating where Enterprise Architects start and stop (an important requirement, since maturing EA programs will change their scope as they mature).

I have shown this view to others, and some have wondered about the “backward flowing” process along the  bottom.  The alternative to showing something as “backward flowing” would be to illustrate it as a cycle (with arrows feeding “in” from the right and “out” from the left).  If it is a challenge for you to view the diagram without those arrows, I apologize.  I’d love to see other view of this model that illustrate the “cycle” in a way that still meets the “rules of the value stream” as discussed above.

I’d love to get feedback and insight from the community.  What do you think?  Does the last image above resonate?  What would you do differently?

Humility and the Art of Enterprise Architecture

By |2013-02-26T16:46:41+00:00February 26th, 2013|Enterprise Architecture|

As a lot, Enterprise Architects are not terribly humble people.  We name frameworks after ourselves, and sometimes go to great lengths to correct the “misinterpretations” of others who describe our work in a way that we don’t agree with. 

Yet, recognizing that the field is young requires that we should be willing to change as the field of EA changes; that we should be willing to look back on our models, developed in the past, and admit that we missed a few steps that we wouldn’t miss today.

I recently had the opportunity to discuss, on LinkedIn, a blog post that I made five years ago.  I look back on that blog post and must admit that my opinions are a bit different now than they were five years ago.  I still agree with my post, but I would certainly use different words today than I used in the past.  I am more than willing to admit it. 

I also look at the efforts of Alexander Osterwalder whose Business Model Canvas has proved both practical and flawed.  He missed the fact that he needed to create a differentiation between the customer’s needs and the value proposition of the business offering to fill some of those needs.  Did he go back and create an updated canvas?  Nope.  He created a new canvas to describe demand as though it fits with his older one (hint: it’s a mess). 

The venerable John Zachman, probably one of the most humble men I’ve met, also made this same mistake.  While his original model was only a couple of columns, and was updated only a few years later into the table we see today, the field of EA has changed.  The table is no longer representative of companies with multiple business models (most of them) and the lack of a “customer” row simply relegates his "ontological table” to the dust bin. 

Neither man will change.  They have “legacy” models, with their names attached.  To paraphrase Forrest Gump, humble is as humble does.

I would like to think that my willingness to upend my EBMM and replace it periodically with new versions shows my willingness to admit that (a) I’m often wrong, and (b) I’d rather learn than become stale.  That said, I’m no paradigm of humility, myself. 

After all, a truly humble EA would not have written this blog post. 

(As my teenage daughter would say: Oh snap, you pwned yourself!)

Rumination on the concept of “best practice”

By |2013-01-28T18:15:13+00:00January 28th, 2013|Enterprise Architecture|

I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference.  One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.”  Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.

I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed.  I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time.  But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”

Are the practices in the TOGAF framework truly “best” practices?  Are these practices the best ones that the EA field has to offer? 

I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”

After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve.  (I nearly always agree with Jeff, BTW.  We sometimes differ in language, but nearly never in approach).  That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice.  Who are we to say?  We are practitioners.  While that is good, it is not enough in my mind to qualify the practice as “best.”

To be a best practice, in my opinion, a method or approach has to meet a higher bar.  There has to be evidence that it is, in fact, better than just a “good practice.” 

I think a best practice should have:

  • Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
  • A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
  • Some analysis to show that it meets other criteria like broad applicability and simplicity, and
  • We should demonstrate the ability for that practice to be understood and performed by people who are currently in the role (e.g. can we teach it, and if we teach it, can others do it?).


I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover?  2%?  10%? 

Is 10% coverage enough to say that a framework is based on best practices?

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. 

The EA Metamodel behind the Business Model Generation

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

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

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

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

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

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

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

What is a Business Model

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

The nine “building blocks” referenced by Osterwalder are:

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

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

The Business Model Canvas

The Business Model Canvas and it’s conceptual information model

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

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

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

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

Osterwalder Conceptual Model

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

Rationalization phase 1: Fixing the Relationships

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

Step 1: Look for Missing Elements

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

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

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

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

2. Osterwalder Conceptual (minus transitive)

Step 2: Look for Missing Relationships

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

Some of the additional relationships added:

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

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

Step 3: Remove Transitive Relationships

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

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

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

Rationalization Phase 2: Simplify Modeling

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

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

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

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

   (William Shakespeare, Sonnet 18)

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

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

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

3. Financial Elements Only

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

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

3b. Customer Elements Only

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

4. Conceptual With Combined Financials

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

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

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

Rationalization Phase 3: Aligning to Architectural Terminology

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

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


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

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

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

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

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

Other naming issues were not so difficult. 

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

5. Aligned Terminology

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

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

Rationalization Phase 4: Aligning to Architectural Frameworks

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

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

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

Business Model Viewpoint.3.8


Integrating into a larger model – the EBMM

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

Core Elements Only View.3.8

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

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

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

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

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

Relating Business Models to other Business Architecture Elements

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

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

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

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

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

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

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

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