【Column】Why Start with Abstraction—Beyond Concrete Traps to Enterprise Context—

[mineko]

Japanese version:
【Column】なぜ、私たちは「抽象」から入るのか　〜具体の罠を避け、企業の「文脈（Context）」を設計するために〜

This article does not discuss the merits or drawbacks of specific products or methodologies. Instead, it examines the underlying assumptions of design thinking in Enterprise Architecture.

“Please show us more concrete images.”
“Tell us what we should ask, and what kind of output we will get.”
“Since this is SaaS, isn’t design no longer necessary?”

In discussions around Enterprise Architecture (EA), it is not uncommon to hear these kinds of comments, especially from perspectives that emphasize speed and certainty. At first glance, all of them sound reasonable, and they are highly understandable from an on-the-ground operational viewpoint.

However, when designing the very “operating system” of strategy execution—the structures through which decisions, investments, and execution continuously interact— prematurely pushing for “concreteness” does not accelerate decision-making. On the contrary, it often leads to self-imposed constraints on future options. This results in frequent backtracking and redesign, ultimately causing the entire transformation effort to become rigid—a failure pattern that is often pointed out in EA discussions.

Design, in this context, does not mean making everything concrete from the outset. Rather, it refers to defining the structure of decision-making first, and then designing the prerequisites that allow organizations to strategically extract value—starting from high-ROI areas—based on prioritized investment decisions.

Enterprise Architects deliberately begin with architectural patterns and governing principles—not to postpone design or avoid concreteness, but as a strategic act.

It is a deliberate and strategic design act intended to preserve future strategic options without being prematurely constrained by specific products, organizations, or processes.

Abstraction in EA is not ambiguity.

It is the very "managerial latitude" that maximizes an organization's context and its freedom of decision-making.

1. "Concreteness" Takes Away Judgment for Futures Not Written Down

The greatest risk of premature concretization lies in the illusion that "what is documented is all that matters."

In the upstream phase, it is impossible to foresee all future issues or organizational changes.

Yet, if details are over-defined from the beginning, the moment something occurs that is not described in the blueprint, the organization loses the principles to fall back on.

Defining abstract “patterns” means preparing the yardsticks for judgment (boundary conditions) in advance—before encountering issues that have not yet emerged.

2. “Abstraction” Is What Preserves Influence over Overall Optimization

Discussions about individual functions or interface designs naturally gravitate toward local optimization.

What EA deliverables must truly constrain is not a single project, but all subsequent investment and implementation decisions. To achieve this, the focus must be on “structure,” not details, and only the logic that affects the whole should be agreed upon in advance.

With this axis in place, organizations can respond to new requests later by asking:

“Does this fit our architecture?”

This enables high-quality decisions that are not swayed by emotions or by the loudest voices.

3. Designing the Right Degree of Freedom Aligned with Enterprise Context

Abstraction is never a uniform template.

How much should be fixed as a “pattern,” and how much should be left to on-site discretion? This balance is precisely what reflects corporate culture and strategic priorities—in other words, the enterprise-specific context.

Which areas should be standardized, and which should retain flexibility for differentiation?

Designing this boundary is a high-value output that architects can provide: defining an organization’s unique context as a structural construct.

EA Is the Design of “Managerial Latitude” for an Uncertain Future

Talking about abstraction does not mean distancing oneself from practice.

Rather, it is the act of identifying, before reacting to individual requirements or phenomena, what state the organization aims to achieve, and what common functions and structures must be satisfied to get there.

What we design is not the “issues” directly in front of us, but the structural way of being that the organization wants to make work repeatedly and consistently across multiple events and requests.

From this perspective, the key question is not “what a specific tool can do", but what kind of management and operational backbone we are designing, and which implementation platform we choose to support it.
Concreteness provides immediate solutions within a specific scope, while abstraction, on the other hand, shapes the architecture itself—one that can absorb future change.

First, define the “patterns” the organization must protect, then flexibly place concrete implementations on top of them as circumstances evolve.

By designing and using platforms with this mindset, platforms such as ServiceNow can be positioned not merely as operational tools, but as foundational capabilities that connect management intent with execution on the ground.

As a result, enterprise strategy does not remain confined to short-term optimization, but continues to sustain its effectiveness over time.

Note: The views expressed in this article are based on the author’s personal experience and perspective, and do not represent the official views or product policies of ServiceNow.