What an IT Architect Actually Does

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.

What is an IT architect in the first place

An IT architect is, roughly speaking, “the person who decides the system’s skeleton.” Like a master builder who designs a building’s foundation and load-bearing structure before any walls go up, the IT architect determines the fundamental technical decisions — language, cloud, structure, deployment — that shape the system for years to come. These decisions, once made, are extremely hard to reverse. In the AI era where code generation is increasingly automated, the value of “deciding what to build and why” is rising, not falling.

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 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, 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.

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. Not everything needs to be decided upfront, but the harder something is to change later, the earlier it must be decided.

The items listed under “Planning stage” are the ones where changing later effectively means rebuilding. The further down the table, the more room there is to adjust while running.

Postponing means downstream decisions move forward on tentative assumptions, and once upstream solidifies, you absorb a massive rework hit. Cloud vendor, primary language, and DB engine selection in particular — deferring these core decisions sweeps the entire team into a wave of rework.

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 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.

A few terms: IaC, 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.

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. 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.

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.”

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)

Related Articles

https://en.senkohome.com/arch-intro-learning-roadmap/ https://en.senkohome.com/arch-intro-overview/ https://en.senkohome.com/arch-intro-series-index/

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.