"Is that really necessary?" — Breaking away from solution-first thinking and designing from intent as an architect

The role of an architect is not to simply implement the "solutions" requested by user departments.It requires understanding the business intent behind superficial requests and deriving truly valuable solutions.This article explains this mindset using concrete scenarios, based on the workshop "Solving for Intent: Architects Are Not Order Takers" (facilitated by Walter Spinrad - CTA and Louise Lockie - Salesforce MVP) held at Architect Dreamin’ Americas in January 2026.

Why is "solution-first" a problem?

It is not uncommon for user departments to present specific implementation plans, such as "I want you to create a field" or "I want you to create a form." However, if you treat these implementation plans as requirements as-is, have you ever experienced cases where you realize there is a misalignment after delivery is complete, leading to rework or dissatisfaction?

At the workshop, the following question was posed.

The root cause of this problem lies inconversations proceeding while requirements and solutions are mixed together.The language used by user departments may sound reasonable at first glance, but in reality, "what they want to achieve (intent)" and "how to achieve it (solution)" are often not distinguished.

What is Intent-Driven Architecture?

What was proposed at the workshop is a three-stage thinking model:Stated Requirement → Identify Underlying Intent → Business Outcome. Stated Requirement focuses on "the solution requested by the user department," Identity Underlying Intent focuses on "identifying the true purpose/problem behind that request," and Business Outcome focuses on "designing the business results to be achieved and their measurement metrics."

By restructuring conversations along this flow, it becomes possible to design based on business value rather than superficial functional implementation.

From here on, I will introduce the cases discussed at the workshop in a story format.

Case 1: ERP Integration — Told "nightly synchronization is fine"

A request that arrived one day

A request like this arrived from a sales department manager.

It is a simple requirement at first glance. With a nightly batch, implementation costs can be kept low, and it seems like something we could start on immediately. However, we decided to pause and think for a moment.

Why did they decide that "nightly synchronization is sufficient"? What exactly do sales representatives want to do by looking at order history?

When we visited the site

We visited the sales team's office. We found that the sales representatives were frequently busy handling phone calls.

"We get a lot of inquiries from customers asking, 'Where is the product I ordered right now?'"

A staff member told me this.

"I can see the shipping status if I log into the ERP, but it's a hassle to open a separate system while handling customers in Salesforce... In the end, I end up keeping the customer waiting."

I see. What they really wanted wasn't just "order history." It was the ability to immediately check the entire sequence of statuses from order registration to shipping and delivery right in the middle of customer interaction.

Digging deeper,

I also spoke with the customer support team.

"Honestly, what the customer cares about most is 'when will it arrive?' If the fulfillment time were shorter, the number of inquiries themselves should decrease, but..."

Here, my perspective shifted. Visualization is not just about "providing information"; it has the potential to lead to early detection of delays, SLA monitoring, and proactive customer notification. In other words, if you can inform the customer of the situation before they even inquire, you can achieve both improved customer satisfaction and reduced operational burden.

Designing according to intent

The initial requirement of "syncing order history via nightly batch" was actually just the tip of the iceberg. When you organize the issues that truly need to be solved, the following options become visible:

• Is display as mere contextual informationsufficient?

• Is near real-time status updatesnecessary?

• Should we even consider automatic customer notifications?

If you jump to the "nightly sync" solution without making these judgments, even if you successfully integrate, dissatisfaction will remain, such as "I wanted to see it in real-time after all." By building requirements starting from what it is needed for and how it will be used, it becomes possible to design without rework.

Case 2: Approval Process — Is "running it through 3 layers and sending notifications" really necessary?

The received requirements document

One day, I received this request from the Sales Promotion Department.

Approval process, 3 levels, email notifications. As requirements, they are clear. It can be implemented using standard Salesforce features, and it seems like I could start designing immediately.

But wait a minute. What are the real requirements? Why is it necessary to stack the approval workflow into 3 layers?

We decided to ask the project owners, the CRO (Chief Revenue Officer) and the CFO (Chief Financial Officer).

What became clear through dialogue with management

"Frankly speaking, our gross profit is declining."

The CFO started with this.

"When I looked into it, I found that an average discount of about 20% had become the norm. Our growth trajectory is also unclear, and at this rate, we won't be profitable."

The CRO continued.

"Sales teams keep discounting to hit their numbers. But even if revenue grows, it's meaningless if there's no profit left. That's why we want to put a stop to it through an approval process."

I see. Behind the request for "we want an approval process," there was an intent to "prevent meaningless discounting and protect profits." was there.

However, questions remained.

We asked further questions.

"Are approval requests ever rejected?"

"...Honestly, almost never. Once an application is submitted, it somehow just gets approved."

"Who uses the email notifications for each step, and how?"

"Hmm... there are so many notifications that, honestly, I might not be looking at them much."

Here, the structure of the problem became visible. The three-tier approval process and the flood of email notifications were not actually functioning. In fact, we even heard that some sales representatives were thinking, "It's a hassle if it exceeds 20%, so I'll submit it at 19%."

What is the problem that truly needs to be solved?

To summarize, the issue the user department was facing was not the lack of an approval process.

• The problem is that revenue and process have not been separated.

• Three tiers are excessive, and two tiers might be sufficient.

• Email notifications for each step increase noise and are actually being ignored.

• It is inducing undesirable learning behavior (adjusting to 19%) to avoid the threshold.

• For projects with short lead times, application and approval processes cannot keep up

Designing according to intent

Taking a step back from the solution of "creating an approval process," I decided to rethink the design from the perspective of guardrails that protect business integrity.

The questions to consider are as follows:

• Re-examine whether notification frequency, number of layers, and the necessity of approval are truly needed by "working backward from the objective"

• Quantify the number of cases meeting the threshold (over 20%) and estimate the resulting number of approval emails and man-hours

• Verify whether the approval rules are creating friction in the sales process

• Clarify the definition of the discount itself (is it a simple 20% off, conditional, or a fixed threshold?)

Ultimately, instead of implementing the three-layer approval process as is, I decided to propose a guardrail design that acts as a "filter to prevent bad deals".

Frameworks and methods for practice

In the workshop, it was recommended to always keep the following three questions in mind:

1. "What problem does this feature solve?"

2. "Who benefits, and how?"

3. "How will we measure whether it was successful?"

Furthermore, the following five practical approaches were proposed:

1. Separate "requirement organization" from "solution consideration"

It is natural for clients to talk about requirements and solutions at the same time. As a facilitator, it is important to guide them by saying, "Let's first organize what you want to achieve," and separate the phases.

2. Elicit intent through Play Back (paraphrasing and repetition)

Paraphrase the other party's requests multiple times during natural conversation and have them repeat it back. After 3 to 4 repetitions, keywords emerge, and wants and needs can sometimes be seen as separate.

3. Determine the definition of success and measurement early on

If you proceed with a project without clearly defining KPIs/KPOs, you will end up with something that is "complete but of unknown effectiveness." It is important to agree with stakeholders on "what needs to change for this to be a success" before you begin the design process.

4. Start small and grow

Do not include everything in the initial design; start by narrowing it down to the truly necessary scope and expand while in operation. Clarify "who owns it," "who inputs data," and "who uses it" to prevent unnecessary additions.

5. Do not neglect field observation

You cannot understand the reality of the situation from the upper management level alone. Even if you encounter buck-passing or resistance, it is necessary to connect directly with middle management and the front lines to secure opportunities for observation. It is important to notice "avoidance behaviors," such as when the UI you prepared is not being used and processes are being handled through alternative channels.

Summary

An architect should be an "Outcome Owner," not an "Order Taker." The architect's role is not to simply implement the "solutions" requested by user departments. Keep in mind the three core roles of an architect—Translator, Challenger, and Systems Thinker—and strive to translate the underlying intent and think about overall optimization.

Furthermore, the workshop concluded with the following call to action:

You don't need to change your behavior drastically all at once. Let's accumulate small updates and embody the architect's mindset of designing from intent!