The Architecture Pyramid as a Decision Framework

SKM-001 explains why architecture is a hierarchy of decisions. This framework is how we use it on a Tuesday afternoon, with a real problem on the table.

A framework is only useful if it changes what you do next. The Pyramid changes the first question you ask.

What this framework is for

The Summit Architecture Pyramid describes five layers, each depending on the stability of the one beneath it: Business Capability, Operational Data, Automation, Applications, and Experience. That model is easy to agree with and easy to forget the moment a vendor demo starts.

This framework turns the model into a short, repeatable exercise. We run it at the start of every engagement, before any platform is named, and we re-run it whenever a project starts to feel like it is fighting itself. It fits on one page and takes about an hour with the right people in the room.

The output is not a diagram. It is a sentence: this problem lives at layer N, the layers beneath it are (or are not) stable, and therefore the next decision is X.

The five questions

Work from the bottom up. Do not skip a layer because the answer feels obvious; the obvious answers are where inverted architectures hide.

1. Which business capability is this about?

State the capability without naming a system. "Manage customer relationships," not "fix Salesforce." "Fulfill orders across channels," not "integrate the OMS." If the room cannot agree on the capability in plain language, stop. You are about to solve a technology problem that the business has not defined.

2. What operational data does the capability depend on, and is it trusted?

List the entities the capability touches: customer, product, order, inventory, price. For each, answer three things. Where is the system of record? How many other copies exist? Who notices when two copies disagree?

If any entity has more than one owner, or nobody can say which copy is right, the problem you were handed is almost certainly a data problem wearing an application costume. SKM-003 covers the operational versus analytical distinction that usually surfaces here.

3. Is the automation orchestrating the capability or compensating for the data?

Count the workflows, integrations, and scheduled jobs that exist only to reconcile the entities from question two. Flows that re-match customers, jobs that re-key products, scripts that patch a field that "should have been right upstream." That count is your glue index. A high glue index means automation has become the place where architectural inconsistency is being absorbed, and any new automation will inherit the same burden.

4. Which application change is actually being requested, and what does it assume?

Now, and only now, look at the application. Write down what the requested change assumes about the layers below: that a customer has one identifier, that inventory is current within a minute, that pricing rules live in one place. Each assumption that question two or three cannot confirm is a risk the application will have to carry itself, usually as custom code.

5. What experience outcome proves the decision worked?

Name the visible result a customer or employee will notice, and how it will be measured. Faster checkout, fewer support tickets about order status, an AI assistant that gives one answer instead of three. If the outcome cannot be stated at the Experience layer, the work is maintenance, not architecture. Maintenance is fine; it should just be called that.

Reading the answers

Three patterns account for most engagements.

The problem lives lower than the request. The request is an application or experience change, but questions two and three expose unstable data or compensating automation. The right next decision is below the request: establish the system of record, fix the identifier, or move the transformation into a governed layer. The application change gets cheaper, and often smaller, once that is done.

The layers beneath are stable and the request is honest. The capability is clear, the data is trusted, automation is orchestrating rather than compensating. Proceed to the application decision with confidence, and let the platform choice be a platform choice.

The capability itself is undefined. The room cannot answer question one. No technology decision should be made this week. The next step is a capability conversation with the business owner, not an architecture review.

Worked example

A retailer asks for a new storefront because the current one "can't show accurate stock." Question one reframes it as promising availability across channels. Question two finds inventory counts in the ERP, the warehouse system, and the storefront, with nightly reconciliation and no single owner. Question three counts four scheduled jobs and a spreadsheet that exist only to correct the counts. Question four shows the new storefront would assume real-time inventory that nothing upstream provides.

The decision that comes out of the exercise is not a storefront. It is an inventory system of record with an event feed, and the storefront replacement becomes a smaller project that follows it. SKC-002 shows the same shape of decision inside a live Salesforce Commerce Cloud architecture.

Using it well

• Run it with the business owner present for question one, and engineers present for questions two and three. Neither group can answer the other's questions.
• Keep the written output to one page. If it grows past that, the problem has not been located yet.
• Re-run it when a project's glue index starts climbing mid-build. That is the earliest signal of an inverted decision.
• Treat the layer finding as the headline. "This is a layer two problem" is a more useful sentence than any technology recommendation.

Key takeaways

• The framework converts the Pyramid from a belief into a habit: five questions, bottom up, before a platform is named.
• Most expensive projects are requests at layer four or five whose real problem sits at layer two.
• The glue index, the count of automation that exists only to reconcile data, is the fastest diagnostic available.
• The output is a located problem and a next decision, not a diagram and not a vendor.

Related knowledge

• SKM-001 — The Summit Architecture Pyramid (the model this framework applies)
• SKM-002 — The Agentic Data Layer (where transformation logic belongs once a layer two problem is found)
• SKM-003 — Operational Data vs Analytical Data (the distinction behind question two)
• SKC-002 — Samsonite: a new commerce channel inside an existing architecture (the framework applied)

Changelog

• 0.1.0 (2026-10-22) — First public draft.