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.
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.
15 thoughts on “Business Architects: Do Not Start With Strategy”
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.
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 !
I mostly agree with what you're saying here Nick, but I want to set it within a larger context that, at least for me, explains why chicken/egg questions like these keep coming up.
For some reason I don't yet understand, most people seem to prefer process models to information structure models. Maybe we just evolved to think in terms of sequenced activities as a way of achieving goals. Regardless, I believe that we would often be better off thinking in terms of information structure models rather than sequencing of activities. The thing about an information structure model that gives us tremendous flexibility is that it tells us how the elements of the structure must relate to one another without (unnecessarily) constraining the order in which we create those elements and their relationships. We can suggest heuristics for populating such an information structure, but they are suggestions not requirements. What is important is not how we create the information structure, but that however we create it we eventually "get it right", and ideally that along whatever path we take to getting it "completely" right, it is usefully right most of the time.
This latter desirable property, "useful incompleteness", is almost totally obscured by time-ordered thinking. A process- or activity-centric model strongly suggests that one element must be "complete" before we can move on to the next, while in practice this is rarely possible. If we observe this constraint rigorously, we have to cycle round and round this process repeatedly, fixing things we got wrong because we have to make decisions whose consequences we cannot yet understand, because they will not become apparent until we try to execute the downstream activities. This is basically the idea behind agile software development.
An example I often use to explain the difference in these two ways of approaching a design problem is how we solve jigsaw puzzles. We do not start by looking for the upper left hand corner and then proceeding to find each successive piece in a raster scan fashion. We look for obvious anchor pieces (all four corners, the edge pieces, similarly colored pieces) and we build "locally correct" subdomains whose correctness is independent of the rest of the puzzle. These in turn serve as larger anchors that we try to connect, and as we do so, the problem becomes one of filling in the gaps within a larger framework that is stable and can serve as reference. This analogy is not perfect (none are) but it gets the idea across.
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.
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.
As to Peter's concern: Peter, you mention that strategy includes context. It often includes "influencers" that motivate the strategy. It rarely includes the context of the business model, which describes the business itself: who are the customers, what segments are they "operating" in, what partners are used to reach them, what products or services do we create, what's the value proposition of our products or services, who are our suppliers and why do we use them (instead of being vertically integrated)?
So saying "Microsoft must improve Bing by increasing the ability to sell advertising in BRIC countries. Why? Because Google having trouble with international markets and this leverages our strengths." That's not context for the strategy of improving a search service.
The context must be the business model of online advertising with the channel based on search services offered in specific countries. How well are we doing? What are the impediments to success in the existing locations?
If the business architect doesn't know enough about the offering (and, to include the context of the EA, if we don't understand the detailed obstacles within our own organization that reduce effectiveness, agility, and security), how can he or she prioritize the strategy of "confront the attack on MSOffice offered by Google" with respect to the strategy of "advertise to small and medium-sized businesses in Brazil?"
Without prioritization of strategy, everything is equally important… or we pick the strategy that will make the most money… or we pick the strategy that will improve customer ratings (because that's what an article in Business Week said we should be focused on). That's what Business Architecture must do, or we are no better than the fools from the consulting companies that promote that short-term thinking.
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.
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.
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.
If you wish to add a comment, please visit LinkedIn at this location:
Just after the rebirth of Business Architecture (2008)
I had a chance to work with some really smart people who I tested my approach with and we managed to accomplish in 10 weeks what takes most a year to accomplish.
The stakeholders I worked with are considered the "impossible to influence" types.
Now if we can acquire success at this speed, with a role of trusted adviser earned as an outcome?
Isn't it worth understanding?
I've used this broad set of guides to align governance by design, enable an ideal customer experience and lean the expense to an optimal manufacturing or just in time solution model.
Now I had a chance to meet with a Sr. Business Architect from IBM not too long after this project and learned that these experts were not as advanced in their approach as I had managed to get Cisco's experts in 10 weeks.
Technology and Business People needed an expert to guide them based on what needed to change in technology or a champion who could speak deep technology with both business and technology experts.
I've commented in the LinkedIn blog. I wanted to simply add that business models are not intended to be dynamic from an architecture delivery perspective. We are expected to deliver a solution that allows varying degrees of purpose. To a static set of customers and the same for suppliers. Static meaning new have a path in but are less likely than we want to bring new on board. Fewer is better in known or mature offers. The exception rather than the rule.
The same is true for advanced and more often in new innovation or emerging offers.
Everything is new in emerging offers and requires more rigor and more documentation.
Considering the offer maturity is defined during strategy conversations and approved during the strategy execution, then it may be true that a business model is different than what I am seeing described as change management activities. Unless architects are taking on the role of change experts from HR, we don't want Business Architects taking on that level of responsibility. Which of three paths a strategy takes or all three in some cases, absolutely.
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.
Let's continue that part of the discussion on LinkedIn.