Business Architects: Do Not Start With Strategy

Frequently, when reading articles or books on business architecture, the following advice emerges:

Business architects start with the strategy of an organization. They take that strategy and map it to the capabilities of the enterprise to clarify the capabilities that must be improved or matured in order to effectively execute.

Sure… you could do that, if you want to fail.  (Before you flame me, read on.)

A business analyst may start with some bit of strategy and start hunting for capabilities… a business architect will start with a model of the enterprise, its value streams and its business models.  Starting with strategy is a fool’s errand.

Why?

Because strategy is meaningful within context.  It is not meaningful without context.  Starting with strategy means “starting without context.”

Outside of the context of a business model (and, in some cases, value streams), business strategy is about as useful a tire swing with no tree to attach it to.

But wait, you ask, don’t management consultants say to “start with the strategy?”  Yes, but it’s a trick statement: they don’t define what strategy is, so that they can start with a business model and CALL it a strategy.  That’s what smart ones do.  Dumb ones simply fail. 

Business architects add no value if they bring analysis methods that are no more valuable than the poorly described “consulting methods” that management consultants use today.  (If those methods worked, why would “alignment” be a problem?)  Simple methods like SWOT and Five Forces and even Balanced Scorecards can fail catastrophically if there is no recognition of the fact that these methods are only useful within the clear and well described boundaries of a business model.

This post is a follow-up to my prior post: Business Models in Business Architecture.  In that post, I discuss the fact that some business thinkers, including Osterwalder, consider business strategy to be “on top” with business models being “underneath” the strategy level.  (At least, that’s what he wrote when he was a student in college.)  In that ordering, Osterwalder himself was saying “start with strategy” and then to describe the business model.  On this we disagree.    I agree that business strategy is different from a business model.  I disagree on which comes first.  Depending on what you define as strategy, the business model should be on top. 

[Aside: Note that some people consider “strategy” to include many of the elements that Osterwalder, and I, consider to be part of the business model.   Is the value proposition and the list of products the same as the “business strategy” or the “business model?”  If the strategy represents the things that need to change, in an organization, in order to achieve a mission, then the business model comes first, and the strategy comes second.]

Who’s on first?

The business model answers key questions about the INTENT of an organization.  How does that organization WANT to make money or deliver value?  Who does that organization WANT to reach through customer channels?  How SHOULD costs be structured?  How do you HOPE the partners will react?  These are all wishes, but they represent the intent of the organization.  A business model is the context.  It is the setting for the business story.

Note that once a business is operating, there are realities in that business model.  Sometimes the most important question is: are we living up to our business model? 

Strategy is the action: what changes do we have to make in order to REALIZE that business model?  What do we need to do differently than we are doing today in order for the business model to become reality?  That is strategy.  It is the action, not the destination.  But action starts somewhere and travels somewhere.  Strategy starts from where the business model is today, and gets an organization to where the business model SHOULD be tomorrow.

 

There are two possibilities, of course.  Either the organization TODAY is living up to the promise of its business model, or it isn’t.

Not living up to your business model

As I noted above, a business model is a declaration of intent.  It includes things like “channels”, “partner relationships”, and “value propositions”.  So, what if your costs are too high, or your customers don’t accept your value proposition?  That means your organization is not living up to the business model.  In that case, the diagram above is a little misleading.  Your strategy takes you from your INTENDED business model to your REALIZED business model.  (In effect, the business model is not changing… the organization is).

Living up to your business model

So what if your business is doing very well.  After all, it does happen.  Sometimes a business will earn the money it intended, with the cost structure it hoped for, and the business relationships it wants, along with value propositions that delights the customers.  What is strategy in that case?

In this case, strategy usually reflects one of two possibilities:

• incremental improvements in the business model (cut costs a little more.  Improve customer satisfaction a little more.  etc), or
• adding a new business model to the organization.

The most common one is the first.  Minor improvements: Increase the predictability.  Reduce the risk.  Cut costs.  Improve customer satisfaction.  Expand to a new market with an existing product.  These are all incremental changes to the business model.

The second one grabs a few more headlines: adding a new business model to the organization.  When Amazon decided to offer cloud services, it was adding a new business model.  When Google brought out G+, it was adding a new business model.  When Exxon Mobile bought a series of natural gas extraction companies, it was adding a new business model.

In that case, the executives didn’t just say “we are good, let’s stop innovating.”  They pushed for something better.  They defined what that something looked like with an update to the business model (or an addition to it) and then pushed the organization to achieve.  How did they push?  Strategy.

Starting with the business model

So, here comes the kicker… all those business architecture journals and articles that say “start with the strategy” are naïve at best, and at worst, dead wrong.  Understanding the value of the business model concept means changing your practices, updating your methods, and doing something different.  It means, before you look at the strategy, look at the business itself.  How does it work?  How is it supposed to work?  What is the business model?  Is the organization living up to the business model?

Only after you understand those basic questions should you consider business strategy.  Only after you understand the business model does business strategy even make sense.

Comments

• Anonymous
  August 24, 2013
  great

• Anonymous
  August 24, 2013
  http://teendilinh.net/

• Anonymous
  August 24, 2013
  Interesting discussion piece, Nick.  I am sure it will provoke some interesting reactions, thoughts and discussion. I declare my "conflict of interest" before responding - I am a consulting business architect.  However, I have been an employee in roles such as IT Manager and IT Strategist where I have undertaken the "business architecture" role before it was as formalised as now, and in organisations where this role would still not be a full-time, single purpose role. To keep my response succinct and clear, I would not be as absolute about the starting point.  My experience has been to use whatever provides the best "stake in the ground" and this might be a business model or a business strategy.  Oftentimes, the business strategy is not "context free".  The business strategy and related documents often provide market context and current business model context.  The business strategy typically indicates or at least imputes the intended business model. Why start with business strategy?  The business strategy outlines the "mandate for change".  Starting with the business strategy enables the business architect to avoid treading "old ground", re-inventing the business strategy, or pursuing strategies which lack executive priority and support.  It enables the business architect to leverage existing collateral and to be seen to be adding value, rather than duplicating effort and treading old ground.  It can be a very helpful starting point of the business model is in transition or not well expressed. I am not sure that one can deal with business strategy without dealing with the business model, and vice versa.  I would not argue for one having primacy as the starting point over the other.  My experience is that either can be a sound starting point for a business architect.

• Anonymous
  August 24, 2013
  The key to success is engaging with the customer. The EA / business consultant has to first find out who the business leaders (decision makers) are, then engage with them and find out what they have in place which describes the directions of the company and how firm that is.   As the use, meaning & position of Business Strategy, Business Models, Business Planning differs between companies, there isn't one "right way of doing it", it''s going to depend on the company. Understanding how firm the directions are can be tricky. Sometimes it's clear e.g. if a strategy document has been approved by the board according to the minutes ! Sometimes much less so... Confidentiality is a significant factor. Strategies & reasons behind strategic decisions might be kept secret ! The EA/consultant has to be aware that not everything may be being revealed to them !

• Anonymous
  August 24, 2013
  The comment has been removed

• Anonymous
  August 25, 2013
  This has got to be a first: three detailed responses that essentially agree with one another (especially since none of the respondents could see the other responses at the time).   Essentially, each of you are saying, in your own way, start with the "useful and available" information and don't focus on starting at "point A." The rub is that the "advice" we give to new folks, and young business architects, across the industry, is process oriented not (as Len very well described) information oriented.   The best solution is very likely to be the one suggested by Len: that we create a simple information model and indicate, for each method, the areas of the model that are required by that method.  We fill what we have with what we know and produce what we can for value.  

• Anonymous
  August 25, 2013
  Further thinking: I'll narrow the context a little.  (I wasn't clear in the blog post).  The intent, in my mind, was to describe the situation where you want to end up with prioritized roadmap of activities.  The commonly described "first step" is to create a capability heat map.   So the short-term objective is to create a capability heat map.  You have to collect various bits of information in order to do it.   The collecting of information, I posit, is rarely an exercise in typing.  The information is normally embedded in documents or powerpoint presentations (or perhaps communicated via e-mail or even verbally at a meeting).  The intellect of the person collecting the information comes into play.  The preconceived notions, and contextual understanding, and biases, all end up "coloring" the extracted data.  The results are a function of the person trying to reach those results.  (hmmm... perhaps there's another blog post there :-). Given this much narrower objective: create a capability heat map (not all of the possible artifacts of business architecture), I stand by the blog post.  You cannot produce that a capability heat map effectively without considering the business model(s) at play to ensure that you are including strategies at the right level, excluding strategies from other business models (outside the concerns of the stakeholder you are working with), and prioritizing those strategies appropriately.

• Anonymous
  August 25, 2013
  The comment has been removed

• Anonymous
  August 25, 2013
  As the article correctly suggests, Business Strategy needs context, and that such context is provided by the Business Model(s). It is also the case that the Business Model is/was influenced by the existing Operating Model and Business Strategy. Thus, the circle of relationships is: Business Model <-> Business Strategy <-> Business Architecture <-> … Operating Model <-> Business Model. It’s a Circle Game, pick whichever starting point you want, the 'Upstream' drives and is influenced by the 'Downstream' at any point is the Circle. If Business Architecture is the starting point! Then it is driven by Business Strategy, which, in its turn was driven by the Business Model(s). We should accept (and verify) that, for the purposes of enterprise business architecture, the 'context' of which Nick speaks is provided by the Business Strategy. The modeling question for Enterprise Business Architects is "Should the Business Model be included in the Business Architecture along with a Business Strategy Model?" Nick's EBMM suggest that it should be.

• Anonymous
  August 25, 2013
  I would agree and in some respects disagree.   A good business model would start to take shape based on the needs of your consumer and the jobs they need to complete in their lives. If you take a blue ocean approach you would be looking for the gap and then design a business around that experience. You would not start with capabilities but the segments and their needs.   Then shape a business model that delivers this experience.  Over time you can then use the business model to understand the impacts of change but also plot out any strategic direction.

• Anonymous
  August 26, 2013
  The discussion is getting long.  I will move this to LinkedIn to continue the sharing.  This blog software has some serious bugs with comments that are longer than a few sentences.

• Anonymous
  August 26, 2013
  If you wish to add a comment, please visit LinkedIn at this location: http://www.linkedin.com/groupItem?view=&gid=36781&type=member&item=268686373

• Anonymous
  August 27, 2013
  The comment has been removed

• Anonymous
  August 28, 2013
  JD asked a great question on LinkedIn and I feel it covers a gap in this blog post: If we are creating a capability map, do we need to know "why" that map is created?  Does the use of the map drive different "meanings" of the term "capability?"  If we don't have a clear definition of the concept of "capability," this is a problem. My answer is as follows:

---

To me, a capability is a conceptual entity. The list of capabilities is a fairly stable list (ideally) that allows us to create measures across an enterprise over time. If the list is comprehensive, it defines an "enterprise ontology". The formula for those measures is not well established at this time, and the number of things measured is not well established, so there is a reasonable case to say that the "definition" is not fully fleshed out. However, the definition of capability as a conceptual entity doesn't change regardless of the selection of measures and formulas. The organization performs in some way. We use capabilities as a way to pull measures together. Those measures, on their face, are just another view of performance. That said, we ALSO connect capabilities to the strategies. This is an ANALYSIS exercise. Strategies are very transitive and their connections to the capabilities are a matter of judgment. This is a HUGE part of the Business Architecture art. This is why some people say "start with strategy". You have to map from the strategy to something. But I'm saying something different. I'm saying "start with the business model" because the ACT of mapping to strategies can be hazardous if you don't know what strategies to map to, or what the relative priority of the strategies. It takes time to COLLECT the strategies and you can waste a huge amount of time collecting the wrong strategies or in the wrong priority. You can raise expectations from people that you collect the strategies from. Focus matters.

• Anonymous
  August 28, 2013
  @Lisa Let's continue that part of the discussion on LinkedIn.