Navigate Business Architecture—Permission to Be Different

Introducing a Value Chain

We love reference architectures! Reference architectures are the ultimate intellectual accelerator! A reference architecture takes a topic and identifies the normal outlines of a system. It provides a conceptual shell for the system.

More importantly, someone else made it, hundreds of others have refined it. It has proven itself over time. We can lean on it and it will carry the load.

The classic Porter Value Chain is a reference architecture. It takes a commercial organization and identifies the normal outline. Primary Activities create the products and services that delight our customers. Supporting activities—drawn as a burden Primary carries—exist because they are necessary and do not delight our customers.

A solid value-centric thinking frame. Supporting Activities (overhead) and Primary Activities (value producing). All aligned to capture margin.

Great reference architectures show Structure (components and relationships) and Function (how the system works).

Michael says structure and function are tied to business activities. The things a business must do. He uses a simple graphic to draw our eye to overhead and the movement of raw materials into our organization and out to our customer. With a simple arrow, we know the goal is generate margin.

All reference architectures explicitly, or implicitly, explain the scope of the system of interest—what is the boundary of analysis. And what is the problem.

The Porter Value Chain says the scope is the activities necessary to operate a commercial organization. The problem, optimization for margin.

My EA consulting team looks for perfectly complete reference architectures. We know, few include everything we desire:

• Model(s) of the system showing Components, Relationships between components, and Properties that should be specified
• A crisp vocabulary containing every specialized term and phrase, all consistently defined
• Relevant architecture patterns
• Guiding architecture principles
• Viewpoint Library

Most volunteers creating useful reference architectures create one good enough for their purposes. Then they stop. In 1985 Michael stopped.

You see the 1980s manufacturing roots in Michael's model. When he was thinking, digital products were not a thing. Nor, the rich ecosystem of outsourcers.

However, none of this changes the power of the core structure:

• Primary delights your customers
• Supporting provides scale and efficiency to do what Six Sigma calls unavoidable waste
• Everything is about the activities

I use the basic Porter Value Chain all the time. In the search for better tools I read pundits' calls claiming a need for redoing, refreshing, and modernizing. When I read their complaints, all I see is a call for an industry-specific variant.

Of course we all want an architecture project specific reference architecture. Who doesn't want the boundary of analysis, core components, and central problem handed to them? This is why my EA consulting team is always on the look-out for strong reference architectures. When we find one we render it in Navigate's formal model terms and drop it into our EA Repository. Where it waits quietly, until we need to accelerate our thinking.

Configuring a Value Chain

Most industries have a common value chain. A common set of activities everyone in the industry makes choices about. After all, Tesla and Toyota do the same thing, make cars. Making cars requires designing cars, sourcing raw materials and parts. Manufacturing the car. Distributing the car. Retail sales. Maintenance and support.

The difference is how companies have made different configuration choices about the common activities. Those choices dance at the cusp of being hard foundational constants and variables.

Think about Tesla and Toyota. Both made radically different foundational choices. Tesla does things in-house. Toyota uses close supply partners. When Tesla's truck needed a new manufacturing technique—bent stainless steel body panels—Tesla invented the process, the tools, and built a facility. Tesla does things in-house.

By contrast, when Toyota needs something, they look outside. Toyota instinctively looks for a specialist supplier. Toyota uses third party dealers to sell and service. Tesla, again in house. To the extreme of fuelling the car—Tesla invented a better electric plug, built a network of best-in-class facilities, and added an entire software suite tied to each car's navigation providing real-time advice to the entire fleet about when and where to refuel.

Value Chain Model Kind

Whenever I am working on an architecture project I must know my current business architecture. Starting with the contours. Then the detail of our value chain configuration.

What I am hunting for are the primary value-creating activities, and their interrelationships. I want to find the configuration choices my organization made.

Then I need to see the supporting activities, their relationships, and their engagement with the primary.

At this point, I'll exclude process logic, and capability definitions. I want high-level activity flows, and a sense of the organizational design under the hood.

In Navigate we'll model this through a hierarchical activity decomposition. I'm seeking a simple Porter-like diagram that illustrates how value is created and supported.

We lean on a few architecture properties to help pull out configuration choices:

• Value Chain State identifies Primary or Supporting. I need to know whether I'm optimizing for value creation or for efficiency. Remember, by Six Sigma definition all supporting activity is waste, and we need to minimize the spend on waste.
• Performer identifies who does the activity. I look for corporate or divisional teams, an acquisition, a business partner, a vendor or a customer.
• Competency compares with our peers. We score Parity, Advantage, Superior. I want to know where we are investing for differentiation, and what that differentiation is.
• Operating Model leverages MIT's CISR. Knowing which activity is Diversified, Unified, Replicated, or Coordinated tells us about the expected deployment. I can infer how that deployment aligns to value.

Sometimes I'll reach to Maturity, where a strict reading of CMMI's 1-5 scale tells me about the required control of the activity. Remember, CMMI-based maturity is never a measure of goodness.

Concluding Permission to Be Different

Leaping off the page of my Value Chain Model are crisp, clear, definitive directions—performance expectations, constraints, and risk appetite.

An activity that is Primary, performed product-specific, and Diversified must be optimized for the specific needs of the Product. Pairing distinct performers and diversified is a strong push. Not only do we have duplicate activity, but it is expected to be done differently. And done with no expectation this activity will connect to anything outside the product. Suggestions about efficiency from scale, and the cost of duplication are violating superior architecture. Yes, they are non-compliant.

Diversified, Replicated, and Coordinated are strong modifiers on locally performed activity. Replicated tells us everyone does the same thing, the same way. Think check-in across all the properties and brands in the Marriott family. Coordinated tells us everyone optimizes process for their product, but shares information for the customer. Think airline check-in across First Class, Business Class, and Economy.

By contrast, an activity that is Primary, Corporate, and Unified must be optimized to the value creation of every product and service at the same time. Here corporate and unified do not tell us much. The default position of a corporate function is to do it the same way for everyone. This one is fun, because unlike a Supporting Unified Corporate activity, I need to optimize for value creation, not efficiency. Arguably I could be inefficient if, and only if it improved value creation.

Let's take a moment to put these cases in terms of our example CEO's expectations:

• Product Family A current market share is too low. Given the value offered there should be more customers. She expects the value already offered to turn into more sales.
• Product Family B product prices are too low. Given the value offered customers should be willing to pay more. She expects the value already offered to turn into more money.
• Product Family C cost of goods is too high. Given the value offered the company isn't making enough profit. She expects to retain larger share of the customer's sense of value.

Let's imagine an activity all three do that is Primary, performed product-specific, and Diversified. Sweet. In Product Family C, we perform a quick test of contribution to Cost of Goods and the ability to slash without impacting product value. A plausible yes to this test puts the activity in the crosshairs.

Now an activity that is Primary, Corporate, and Unified. Sweet. Here we look at that activity in terms of market share, price, and cost. If the activity can move the bar on any of these axes, it is in the crosshairs.

If you have ever wondered about a business architect working in Phase A, wonder no more. If the business architect simply leverages the enterprise value chain and the stated objective of our three architecture projects they have a sense of where to start. They can start to compose viable summary architecture alternatives. They have the information to make some informed calls.

The configuration choices are telling them about the available decision freedom. That cost-impacting, product-specific, diversified activity is under the control of the boss of Product Family C. My first call would be to my application architect and data architect to see if anyone entangled this product-specific diversified activity in the information systems layer. My second call would be to my Product Family C SMEs, who I'd expect would already be considering a radical cost saving exercise.

My third step would be back to the architecture. No one needs my deep expertise to snatch ripe-low-hanging-fruit off the branch. That Primary, Unified and Corporate activity has wicked problem written all over it. Enterprise architect skills are needed to untangle that complex decision space to squeeze some marketshare & price boost, while driving down cost of goods.

This week I want you to think about the edge of superior architecture. Last week, we discussed the deep contours of our superior architecture. This week, we reached the transition zone between superior architecture and open variables. That independently product-specific activity has a burden of producing enough value to justify inefficiency.

My challenge is for you to sketch your value chain and your most prominent competitor's value chain. You should see the same activities, often with similar choices. Then sketch another industry player who isn't a direct competitor, you'll probably see different configuration choices.

As a stretch goal, write down the end-to-end system supporting those activities. I suspect you will see the roots of friction where value chain choices are in conflict with choices inside the end-to-end system. Every one of those friction points is a wicked problem calling for enterprise architect skills.

In my example, I read from the business architecture to understand the configuration choices. Then I quietly slipped past the definition of value by telling you to optimize. I had to. I needed you to think about the value chain and configuration choices. Those choices exist and must be optimized to the value proposition. Bluntly, there is a reason why one activity is corporate unified and another performed independently by every product. Next week we'll move from the configuration choices to understanding the value proposition.

Have a great week!

As always, I welcome your feedback and questions.

Regards,

Dave

Dave Hornford
Conexiam