What an IT Architect Actually Does — A Role Whose Value Is Rising in the AI Era

About this article

This article is the first main entry of the Architecture Crash Course for the Generative-AI Era series. Under the heading “What an IT Architect Actually Does”, it lays out the role’s overall picture, the domains it covers, the right mindset, and how the decision criteria are shifting in the AI era.

The series-wide framing lives in the previous article, How to Read This Book.

Category overviews

What is happening in the world of architecture

In 2020, an analytics platform company called Segment published a blog post titled “Goodbye Microservices”, declaring that the 140+ microservices they had grown into were being collapsed back into a monolith. When they originally adopted microservices in 2013, that was the textbook industry-correct answer.

Five years later, the same choice was treated as technical debt. That is the world of architecture.

In other words, “it is mainstream so it is correct” can flip into “it was mainstream so it is debt” in five years.

In a domain where these reversals happen on repeat, the IT architect is the person who decides the system’s skeleton and writes down the reasons. Even in an era where AI writes code — especially in such an era — the value of this role is going up.

AI knows the answer to “how to write it” but cannot answer “what to build” or “why pick this”, because those depend on the organization’s context. In Japan’s IT industry, the precise definition of the job title varies wildly by company, but two things never waver: “decide the skeleton” and “leave the reasoning behind.”

This article walks through the architect’s overall picture, the taxonomy of architectures they handle, the mindset, and how decision criteria have shifted now that AI-driven development is the default in 2026.

Who this article (and series) is for

The audience is anyone working in IT, regardless of title or years of experience.

• Managers — to understand the rationale behind technical decisions and reinforce your own.
• Consultants — to validate the technical proposals you put in front of clients.
• Systems engineers — to widen the range of design judgment.
• Programmers — to grasp the “why this design” that lives upstream of the code.

For engineers who are not full-stack, the conceptual knowledge and decision criteria in each domain translate directly into day-job value. A frontend specialist who knows infra. A backend specialist who knows security. That resolution into adjacent domains is the first step toward becoming an architect.

I think of “architect” as a role, not a title. Regardless of what your business card says, you can leave your name on a design decision starting tomorrow.

What is an IT architect?

An IT architect is the person who creates “architecture” in the IT field. Put simply, the person who designs the system.

But “design” here does not mean drawing screen mockups or class diagrams. It is the person who decides the system’s full skeleton — what language, what cloud, what structure, how it deploys.

In typical projects this person operates as Tech Lead or Lead Engineer, with final responsibility for the team’s technical decisions.

With the rise of DX (Digital Transformation — reshaping operations or business itself with IT), the architect role has become more important year over year. When the shape of the business sits directly on top of software, the system’s skeleton is the business’s skeleton.

The architect lives at the boundary between “the people who write code” and “the people who draw diagrams.” Architects who never touch code lose contact with reality and drift into armchair theory; architects who only write code drift away from organizational decision-making and end up with narrow influence.

A real architect plants both feet on both sides and runs technical and organizational decisions in parallel.

What is “architecture” anyway?

The word “architecture” originally means the design or structure of buildings. Its etymology is the Greek arkhitekton (chief carpenter), pointing to both the person overseeing the design and the design philosophy itself.

In IT, system development is often analogized to construction, and the term “architecture” expanded to cover system structure, design overall, and the design philosophy behind it.

As with buildings, once the skeleton goes up it is extraordinarily hard to change later, and the initial design dictates how the next 5-30 years of operation will go. The “building a house” metaphor keeps coming back because the cost of going back feels similar.

The main types of architecture

Architecture splits into multiple types by the scope it covers. This series organizes its articles along this taxonomy.

flowchart TB
    EA["EA<br/>(Enterprise)<br/>BA / DA / AA / TA"]
    SY["System<br/>(Whole / Foundation)"]
    SW["Software<br/>(App outline)"]
    AP["Application<br/>(Internal / Code)"]
    FE["Frontend<br/>(UI / UX)"]
    DA["Data<br/>(Storage / Flow)"]
    SE["Security<br/>(Cross-cutting)"]
    DV["Operations<br/>(SRE)"]
    EA --> SY
    SY --> SW
    SW --> AP
    SW --> FE
    SW --> DA
    SE -. cross .- SY
    SE -. cross .- SW
    DV -. cross .- SY
    DV -. cross .- SW
    classDef strat fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef impl fill:#dbeafe,stroke:#2563eb;
    classDef cross fill:#fae8ff,stroke:#a21caf;
    class EA strat;
    class SY,SW,AP,FE,DA impl;
    class SE,DV cross;

Architecture	Scope
System Architecture	Hardware, software, network — the comprehensive whole
Software Architecture	Application external structure (monolith / microservices / etc.)
Application Architecture	Application internal structure and implementation policy
Frontend Architecture	UI/UX, rendering, state management
Data Architecture	Data collection, storage, management, and use
Security Architecture	Security foundation design
Operations Architecture	Runbook design, SRE design (Site Reliability Engineering, the operational discipline born at Google)
Enterprise Architecture	Business (BA) / Data (DA) / Application (AA) / Technology (TA) — the enterprise-wide design

This taxonomy is not fixed. The granularity shifts by company and project. What matters is identifying “at which layer does the design judgment need to happen?” and assigning an architect who can handle it.

Large projects split architects by layer. Small ones have one person doing all of it.

A quick term refresh: a monolith (one large bundled application) and microservices (many small services connected together) are concepts that recur throughout this series. The deep dive lives in the Software Architecture category.

Why is architecture necessary?

To satisfy both functional and non-functional requirements

If satisfying functional requirements alone were enough, you could pick any technology — cloud, on-prem, anything. Login works, data persists, screens render, requirements met.

But real systems also have non-functional requirements: cost, performance, security, availability, scalability, maintainability. Deciding which technologies to combine — and how — to satisfy these is the architect’s job.

Functional requirements ask “what can it do?” Non-functional requirements ask “how well does it actually do it?”

If you only look at the functional ones, every selection comes out as “works = OK”, and after production launch you get blowups: performance fails to materialize, outages stack up, operating costs explode. Architecture design can be reframed as a bundle of decisions to satisfy non-functional requirements.

Because redoing it is hard

Once a system has been built, changing its core is essentially impossible. Switching language, switching DB, switching cloud vendor — all of them carry “rebuild from scratch” levels of effort.

That is why an architect with the knowledge and skills must be there before construction starts.

The cost of going back is the same as in construction. Replacing wallpaper is trivial. Moving a load-bearing column is rebuilding the house. Knowing which decisions are wallpaper and which are columns is the architect’s first job.

When to make each architectural decision

Timing depends on the target:

• System-wide architecture: at project planning, or in waterfall, at requirements definition.
• DB and application architecture: also recommended to be settled (broadly) at project planning.

Postponing means downstream decisions move forward on tentative assumptions, and once upstream solidifies, you absorb a massive rework hit. “Decide it in the first week” is the rule.

The architect’s mindset

Five mindset items I have learned from books, articles, and field experience.

1. There is no correct answer in architecture

The most important mindset in architectural design is accepting that there is no correct answer. Even an apparently perfect design will hit problems as development progresses, and a “correct” design from one era can become a “bad” design in the next.

It always requires holistic judgment over the company’s business background, technical constraints, developer skill, and existing system landscape. A universal correct answer does not exist.

Microservices around 2013 swept the industry as “the new correct answer.” By 2020 they were being mocked as “too operationally heavy”, with a wave of monolith-reversal case studies.

Five-year reversals are the industry default. Swallowing the current mainstream whole turns into debt five years later. “X is mainstream, so let’s switch” is how decisions almost always go wrong.

2. Beware over-engineering

Microservices for small systems. Pre-built features for hypothetical future needs. Interface abstraction at every layer. These look sophisticated but in most cases waste time and money.

YAGNI (You Aren’t Gonna Need It — do not build what you do not need now) is the strongest brake on over-engineering.

The single habit that prevents over-engineering is constantly asking: “Is there a simpler way?” Thoughtful and experienced people tend to layer for the future, but most of those layers are never used and only consume operational cost.

In some sense, over-engineering is a disease of the experienced. The courage to pick a boring design is what determines the long-term outcome.

3. Revise architecture when needed

If a change is needed, don’t change it in the field unilaterally. Loop in the architect who oversees the whole. Architecture decisions ripple across the organization, and bending one in isolation surfaces inconsistencies later.

Always reflect changes back into the architecture document and keep it current. The moment the document drifts from reality, it becomes a “map of the past” that nobody trusts.

A document that has lost trust never gets updated again, and you eventually rebuild it from scratch.

4. Don’t get lost in the words

“ASP”, “Web Service”, “Web App”, “Cloud Service”, “SaaS” — technically these mostly point to the same thing. Renaming is often commercially motivated; the substance has not really changed.

Understanding the substance and producing the appropriate architecture is the architect’s job. The industry is full of cases where the same thing got designed three times under three trendy names.

5. Design assuming AI-driven development (vibe coding)

Vibe Coding — describing requirements to AI in natural language and reviewing the generated code as a human — went mainstream from 2024, and AI is now writing large amounts of business code.

The architect’s job shifts heavily toward “designs that are easy for AI to write and read”. Compared to the old “humans-only” era, the priorities flip at the root.

AI-friendly designs	AI-unfriendly designs
Code-managed (IaC, type definitions, schemas)	GUI-only black-box tools
Mainstream / standard protocols (OAuth, OIDC, REST)	Proprietary protocols, in-house frameworks
Modular monolith + 1 DB ACID	Heavy microservices + distributed transactions
Convention-based (Rails-style, Next.js-style)	Designs with too many degrees of freedom

A few terms: IaC (Infrastructure as Code), OAuth/OIDC (industry-standard federated login protocols), ACID (the classic DB consistency guarantees: Atomicity, Consistency, Isolation, Durability), distributed transactions (transactions that cross multiple databases).

The AI-era design principles boil down to:

• Aggressively adopt anything you can manage as code (IaC, Zod (TypeScript schema library), OpenAPI (machine-readable API spec standard), etc.).
• Learning cost matters far less as a selection criterion — pick the language for performance and to avoid cold starts.
• Mainstream, convention-based frameworks dominate.
• Avoid custom implementation — auth, crypto, distributed transactions belong on standards.

In the AI era, I believe “AI-friendly design = human-friendly design” is the convergence. Simplicity and leaning into standards become the highest-value moves.

Three important viewpoints

Three core viewpoints that anchor architectural judgment.

One-way Door / Two-way Door

A decision-making model proposed by Amazon’s Jeff Bezos. It splits decisions into “reversible” and “irreversible”, and concentrates time on the latter. Probably the single most useful framework in day-to-day architecture work.

Type	Examples	Approach
One-way Door (irreversible)	Language, DB, cloud vendor selection	Take time, deliberate, validate
Two-way Door (reversible)	Folder layout, library choice, class design	Decide fast and adjust on the fly

Treating One-way and Two-way Doors with the same weight wrecks your time allocation. Spending too long on a Two-way Door and rushing through a One-way Door is a textbook failure pattern.

Reversible decisions: fast. Irreversible: deliberate. Skip this rule and your project carries both delay and debt.

CAP theorem

In distributed systems (cloud included), simultaneously satisfying Consistency, Availability, and Partition tolerance is in principle impossible. This is the CAP theorem, proposed by Eric Brewer in 2000 and a classic of distributed-system architecture.

In practice you decide between “showing the screen even if the data is a few seconds stale” versus “erroring out rather than displaying wrong data” based on business requirements.

Social network: the former. Bank balance display: the latter. Whichever you pick locks in everything downstream.

Cognitive load

No matter how lofty an architecture is, if the team cannot understand or implement it, it fails. The sight of an architect’s beloved ideal collapsing in the field within a week is common.

The right discipline is constantly asking, “can the team’s actual skills run this?” A design nobody understands might as well not exist.

Always leave the rationale (ADR)

Recording why a decision was made, in a visible form, is the most important behavior an IT architect performs. Systems where only the conclusion remains and nobody can explain “why this choice?” years later are guaranteed to become debt.

Why it matters:

• Newcomers can understand the design philosophy.
• You can judge mid-development or post-launch whether the original goal is being met.
• It feeds important context into the next round of development.

The most widely adopted format is the ADR (Architecture Decision Record). One decision per file, version-controlled in Git.

# ADR-0001: Adopt PostgreSQL as the database

## Status: Accepted (2026-04-01)

## Context
We need both transactional consistency and full-text search.

## Decision
Adopt PostgreSQL (rejected MySQL and DynamoDB).

## Rationale
- JSON type, full-text search, and geographic data supported out of the box.
- ACID-compliant — safe for monetary calculations.
- Available as managed service on AWS RDS / Aurora.

Teams with an established ADR culture onboard new members faster and have steadier judgment quality. Teams without ADRs have the same arguments every year and repeat past mistakes.

Architect responsibility ladder

Note: industry rates as of April 2026. These will go stale as technology and the labor market shift, so they need periodic refresh.

The architect’s job changes substantially in scope and decision-making weight by scale, experience, and organizational level.

Tier	Years (rough)	Scope	Decision weight	Typical artifacts
1 Tech Lead	3-7	One project, ≤10 people	Mostly Two-way Door	ADR, design docs, code review
2 Product Architect	5-10	One product, dozens of people	One-way Door appears too	Architecture diagrams, technology selection docs
3 Solution Architect	7-15	Customer engagements, vendor proposals	ROI, estimation, regulation handling	Proposals, PoC design, RFP responses
4 Enterprise Architect	10+	Whole company, multi-BU	Multi-year strategic decisions	TOGAF/ArchiMate, EA maps
5 Chief Architect / CTO	15+	Whole company, plugged into the C-suite	Executive-level agenda	Tech strategy, org design

Years are not absolute. A small startup can have a CTO-level decision-maker in their twenties; a large enterprise can keep someone at Tech Lead in their forties.

A pragmatic measure of your tier is decision weight × radius of impact. As you climb, the share of organizational judgment goes up versus pure technical judgment.

The architect carries technical judgment and organizational judgment at the same time, with the organizational share increasing as the tier rises. Worth keeping in mind.

Architect failure modes — the forbidden moves

Common ways architects blow up. All of them charge a premium of “dragging the org through bad tech.”

Forbidden move	Why it fails
”Decide because X is mainstream”	Ignores org constraints, existing assets, and people; becomes debt in five years.
No ADR	Nobody can answer “why this?” later, and successors flounder.
Over-engineering (extra layers for the future)	Unused abstractions consume operating cost; YAGNI violation.
Ideal design ignoring team skills	Operational impossibility, design becomes a fossil.
Treating One-way Doors as Two-way Doors	Reversing irreversible decisions costs years of debt.
Deciding in isolation (no implementer in the room)	Idealism disconnected from reality breaks at implementation.
Ignoring Conway’s law in service splits	Misalignment with the org structure causes inter-team friction.
Outsourcing to a vendor without understanding internals	Helpless during incidents, locked in long-term.
Validating new tech in production (skipping PoC)	Risk goes unmeasured; trouble surfaces in production.
Not updating the architecture doc	Drifted “map of the past” creates confusion.

Conway’s law mentioned above is the empirical rule that “organizational structure determines system structure.” Deeper coverage is in another article.

Segment’s monolith reversal from 140 microservices (2020), Amazon Prime Video’s consolidation from serverless+microservices into a monolith with 90% infrastructure cost reduction (2023), Netflix’s GraphQL Federation move (2020+, re-aggregating to lower the inter-service API coupling cost).

Even hyperscale tech companies swap design philosophies on a 5-year cadence. “It is mainstream so it is correct” flips into “it was mainstream so it is debt” when the era changes.

What happens at sites without ADRs (industry anecdote)

I myself am not (yet) in a position making architect-tier decisions, but here is a story I hear variations of often.

In a B2B SaaS, the backend message queue used an unusual middleware. The textbook choice would be RabbitMQ or Kafka, but they had picked something else. Everyone assumed “there must have been a reason” at the time.

Three years later, the original designer had left. No ADR. Digging through old Slack threads turned up no record of the rationale.

The ops team treated it as “there must be a meaning, don’t touch it” and left it untouched for three years, falling behind on version upgrades, accumulating security alerts, and eventually causing a half-day production outage.

The post-incident postmortem concluded the original selection rationale was likely “the designer at the time wanted to play with that tech.” The truth is still unknown.

This scene plays out everywhere in the industry. Architectural decisions correct for their context become unevaluable once the context is lost. A 5-line ADR per decision would have let the successor say, “this premise no longer holds, let’s reconsider” with confidence.

Without it, everyone defaults to “don’t touch it” as self-preservation. What survives across time in architecture is not the conclusion — it is the reason.

What you must decide — what’s your project’s answer?

For each of the following, articulate your project’s answer in 1-2 sentences. Leaving them ambiguous now will always come back as “why did we decide that?” later.

In priority order, the items the architect should decide at project start:

• Application form (Native / Web / Hybrid)
• Deployment model (Cloud / On-prem / Hybrid)
• Primary language and framework
• Datastore selection (RDB / NoSQL / Mixed)
• Authentication (in-house / IDaaS)
• Non-functional targets (availability, performance, security)
• ADR operating rules (where, who, when)

Common failure patterns

Four failure patterns I see often from an architect’s view:

• Picking because it is mainstream — ignoring org constraints, existing assets, and people. Five years later, debt. Segment’s microservices reversal is the symbol.
• Not writing ADRs — decisions become tribal knowledge; successors cannot answer “why this?” In two years the original author has left or the memory is fuzzy.
• Over-engineering — layers built for hypothetical futures that go unused, leaving only operational cost behind.
• Ignoring team skills — beautiful design that the team cannot run will fail. Designs above the cognitive-load ceiling always fossilize.

How to make the final call

The core of the IT architect role is, in my view, “in a domain with no correct answer, derive the most rational choice from within constraints, and leave the reason.”

Even apparently-perfect designs hit problems as development moves forward, and mainstream designs become tomorrow’s debt. The mature pattern is: weigh business background, technical constraints, developer skill, and existing assets together, then handle One-way Doors deliberately and Two-way Doors fast.

“X is mainstream, so let’s switch” fails with high probability, and constantly asking “is there a simpler way?” is the only habit that prevents over-engineering. Then leave ADRs. That becomes your largest gift to the next generation of architects.

The other decisive axis is the convergence: “AI-friendly design = human-friendly design.” With AI-driven development now baseline, code-manageable (IaC, type defs, schemas), mainstream protocols (OAuth/OIDC/REST), convention-based (Rails-style, Next.js-style), modular monolith + 1 DB ACID — these all point in the same direction: simplicity.

Learning cost has dropped sharply as a selection criterion, and mainstream tech with thick AI training data takes most of the share. Custom implementations, in-house frameworks, and GUI-only tools are the most reliable way to accumulate debt in the AI era.

In summary, the priority order:

1. One-way Doors deliberate, Two-way Doors fast — invest the time on irreversible decisions.
2. Converge on simplicity and standards — avoid over-engineering, prefer mainstream and convention-based.
3. Match cognitive load to team skills — designs nobody understands fail.
4. Leave the rationale in ADRs — the largest gift to the next generation.

“There is no correct answer, therefore leave the reason.” That is the core. In the AI era, things are converging on “AI-friendly = human-friendly.”

Summary

This article covered “What an IT Architect Actually Does” — a role whose value rises in the AI era.

Architect is a role, not a title. The person who decides the system’s skeleton and leaves the reasons behind. Because AI now writes the code, the human who can decide “what to build” and “why this” appreciates in value.

There is no correct answer, so leave the reason. That, I believe, is the largest gift you can hand to the next architect.

The next article tackles the “Learning Roadmap” — a concrete reading order by role and experience.

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.