Before the Architecture, the Value Chain

When we talk about systems, servers, platforms, APIs, microservices, or software architecture, we need something more than technical skill. We need a usable map of the business context those decisions belong to.

How does the business create value?

That question sounds obvious. In practice, it is often not available in a format that helps teams make architectural decisions.

I have spent more than two decades implementing, designing, and leading work around complex systems. One recurring pattern I have seen is not that technical people move too quickly into implementation. Moving quickly can be a strength when the direction is clear. The deeper problem is that the business architecture, strategy, goals, and value-chain context are not always available to the team in a format that helps them reason about the problem they are trying to solve. When that map is missing, fragmented, or too abstract, teams naturally start with what they can see: integration patterns, cloud platforms, event streams, domain boundaries, databases, and deployment models.

This is sometimes dismissed as engineering ego. I think that explanation is too simple.

The bigger issue is often not attitude. It is an information gap.

In large organizations, business strategy is not always easy to access. Architectural maps may be outdated, fragmented, or missing entirely. Even when strategy exists, it may live in presentations, leadership discussions, capability models, or planning documents that are too abstract for the team trying to solve a concrete technical problem. The people working on systems may not have a clear view of which parts of the business create differentiation, which parts mainly need efficiency, and which parts are commodity capabilities that should be kept simple.

When that business context is not translated into a usable form, technology becomes the thing people can see. So technology becomes the thing people optimize.

That is expensive.

Every system has a carrying cost. Every custom solution creates maintenance. Every architectural decision consumes attention, money, and organizational capacity. If teams cannot see how their problem connects to business value, they risk spending their best architectural energy in the wrong places.

If I were asked to take a 10,000-person organization and start describing its business architecture from scratch, or if I were asked to support a major business architecture revamp, I would not start with applications, integrations, platforms, or organizational charts.

I would start with Michael Porter’s Value Chain.

Not as the complete answer. Not as a detailed operating model. But as a practical first structure for breaking down the organization into the activities through which it creates value. From there, I would use business architecture concepts, such as those found in TOGAF, to describe the organization in more detail: capabilities, value streams, processes, information concepts, organizational units, stakeholders, goals, and outcomes.

The point is not to force every organization into a generic model. The point is to create a first map that helps us ask:

Which activities create value, which capabilities support them, and where should technology strengthen the business?

Using the Value Chain as a Starting Point

Michael Porter introduced the Value Chain as a way to understand how a company creates value through a set of activities. For Enterprise Architecture, I see it less as a finished model and more as a starting scaffold. It gives us an initial way to structure the business before we go deeper into capabilities, processes, systems, data, and ownership.

The model separates business activities into two broad categories: primary activities and support activities.

Primary activities are the activities directly involved in creating, selling, delivering, and supporting the product or service:

• Inbound logistics: Receiving the inputs the business needs, such as materials, data, stock, documents, or external events.
• Operations: Transforming those inputs into the product or service the customer pays for.
• Outbound logistics: Delivering the product or service to the customer.
• Marketing and sales: Creating demand and helping customers decide to buy.
• Service: Maintaining or increasing the value of the product or service after delivery.

Support activities enable the primary activities:

• Procurement: Acquiring resources, suppliers, tools, and services.
• Human resource management: Recruiting, developing, and retaining people.
• Technology development: Research, development, IT, automation, data, and technical capabilities that support the business.
• Firm infrastructure: Finance, legal, management, governance, and other structural capabilities.

The model is simple, but that is part of its strength.

It gives architects, leaders, and teams a shared language for discussing where value is created. More importantly, it can help translate strategy into a format that teams can use when reasoning about systems, data, integrations, and technical investments.

That distinction matters.

Some capabilities deserve deep investment. Some need to be reliable and efficient. Some should probably be bought as standard products. Treating all of them the same is one of the most common ways organizations waste technical capacity.

Why Enterprise Architecture Needs This Map

Enterprise Architecture is often described through models, principles, standards, roadmaps, capabilities, applications, integrations, and data flows. All of those are useful. But if they are not connected to how the business creates value, or if that connection is not visible to the teams making decisions, architecture risks becoming internally coherent but strategically weak.

A system can be well-designed and still be the wrong investment.

A platform can be technically elegant and still solve a low-value problem.

A modernization initiative can reduce technical debt and still fail to matter strategically.

The Value Chain helps prevent this by giving architecture a business anchor that can be made understandable at the level where decisions are made.

When we map systems, capabilities, data, integrations, and teams against the Value Chain, we can give teams a better starting point. Instead of only asking how to solve the problem technically, we can also ask:

• Which systems support the activities where we create competitive advantage?
• Which activities must be excellent, and which only need to be good enough?
• Where does technology directly affect revenue, margin, customer experience, speed, quality, or risk?
• Where are we over-engineering commodity capabilities?
• Where are we under-investing in the systems that actually differentiate us?

This is where Enterprise Architecture becomes more than documentation. It becomes a decision-making discipline that packages business context so it can actually guide technical work.

For example, in a financial technology company, the transaction engine, ledger, risk controls, customer onboarding, compliance flows, and real-time data capabilities may sit close to the core of value creation. These areas may justify custom engineering, higher architectural ambition, stricter resilience requirements, and more senior technical attention.

The internal HR portal probably does not.

That does not mean HR is unimportant. Support activities are critical. But critical does not always mean differentiating. A support capability may need to be stable, secure, compliant, and easy to use, while still being a poor candidate for heavy custom architecture.

This is the practical value of the Value Chain. It helps us choose where to be ambitious.

The Over-Engineering Trap

One of the most common architecture mistakes is treating support activities as if they were primary activities.

This leads to what I think of as the over-engineering trap.

Organizations build bespoke internal tools for procurement, reporting, administration, expense handling, resource planning, or workflow management, even when those tools do not create any meaningful differentiation. The systems become expensive to maintain. They require integrations, permissions, support, upgrades, data models, and internal ownership. Over time, they quietly absorb capacity that could have been used closer to the company’s actual value creation.

The problem is not that support activities are unimportant.

The problem is failing to distinguish between importance and strategic uniqueness.

A payroll system is important. An accounting system is important. Internal collaboration tools are important. But for most companies, they are not where the company wins in the market.

A pragmatic architect needs to understand this distinction.

Sometimes the right architectural decision is to build. Sometimes it is to buy. Sometimes it is to integrate. Sometimes it is to accept “good enough” and preserve organizational energy for something more strategically meaningful.

That is not a lack of ambition. It is disciplined ambition.

The Missing Piece: A Living Map

The Value Chain is often introduced as a static framework: a diagram in a strategy deck, a slide in a workshop, or a conceptual model that people agree with and then forget.

That is not enough.

Modern organizations change too quickly. Products evolve. Customer journeys shift. Teams reorganize. Regulations change. Platforms are replaced. Data starts flowing in new ways. AI and automation create new possibilities. What was once a support activity may become more strategic. What was once differentiating may become commodity.

This means the map cannot be a one-time artifact.

Enterprise Architecture needs a living connection between business value and technical execution. That connection must be available when teams begin reasoning about a problem, not only after the solution has already taken shape.

That does not necessarily mean a complex tool. It means that the organization needs a maintained and usable understanding of:

• the business activities that create value,
• the capabilities needed to perform those activities,
• the systems and data that support those capabilities,
• the teams responsible for them,
• the investments being made,
• and the strategic importance of each area.

Without this, architecture becomes disconnected from business reality. With it, teams can move quickly while still making decisions that reflect strategy, value creation, and economic priorities.

Business First, Technology Second

Good architecture is not only a whiteboard full of boxes and arrows.

It requires understanding how the company makes money, where it creates value, and where it needs to be different from competitors, translated into a form that is useful for the architectural problem at hand.

Porter’s Value Chain remains useful because it gives us a simple but powerful way to ask those questions. It helps us avoid treating every system as equally strategic. It helps us see where technology should amplify the business, and where it should simply be reliable, standard, and cost-effective.

For Enterprise Architects, this is not a nostalgic return to an old framework. It is a reminder of first principles.

Before we draw the next system diagram, choose the next platform, or launch the next modernization initiative, we should make sure the team can answer:

Which part of the Value Chain are we strengthening, and why does it matter?

If we cannot answer that, the problem is not necessarily that we are moving too fast. The problem may be that the business map needed for good architectural judgment is not available where the work is happening.

Then we are not really practicing Enterprise Architecture.

We are only designing systems.