Technology Architecture - The Constitution of Enterprise Tech Choice

About this article

As the fifth installment of the “Enterprise Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains EA-perspective Technology Architecture (TA).

While the system-architecture chapter (10 series) handles “what to use in projects,” this article handles “what to allow / make standard company-wide.” For example, “make AWS the company-wide standard cloud” is this article, “EC2 / ECS / Lambda - which to use” is the 10 series. This article covers Technology Reference Model, Tech Radar, company-wide standard stacks, and SoR/SoE/SoI separation - explained for CIO / IT-strategy / infrastructure-department-head.

What is EA-perspective Technology Architecture in the first place

Imagine company-wide equipment and facility standards. If each department independently buys PCs, printers, and network equipment from different vendors, maintenance costs explode and IT support can’t keep up. Setting company-wide standards keeps cost and management burden under control.

EA-perspective Technology Architecture (TA) is the domain of standardizing the entire company’s technology foundation. Rather than “what to use in projects” (the 10 series), it decides “what to allow / make standard company-wide” — the constitution of tech choice.

Without TA, departments start using AWS, Azure, and GCP on their own, and the tech stack explodes into unmaintainability.

Tech freedom only stands on top of governance

The 4th EA layer (TA) designs and standardizes company-wide tech foundations (infrastructure / network / platform). Different from tech selection at individual-system construction, the role is deciding enterprise tech standards.

“Which cloud to use” / “what’s the company-wide standard language” / “what DB” - deciding these at company-scale is TA. Without TA, departments arbitrarily start using AWS / Azure / GCP, and tech stacks explode.

TA is the constitution of enterprise tech choice. Deviation requires justification.

Why TA is needed

Tech diversification eats cost

When departments use different tech, talent fluidity drops and operational cost spikes. Standardizing optimizes talent placement, procurement, and operations.

Security / compliance compliance

Applying unified company-wide security standards premises tech-stack standardization. Disparate setups make audits and response impossible.

Enjoying scale benefits

Cloud contracts, licenses, and support contracts get discounts when consolidated. TA’s standardization enables tens of millions to hundreds of millions of yen in cost reduction.

Main TA components

TA systematizes tech foundations used company-wide. Beyond mere product lists, it’s comprehensive design including selection criteria, usage guidelines, and exception handling.

Element	Content
Cloud strategy	Adopted clouds, multi/single
Standard tech stack	Languages, FW, DB
Network design	WAN (Wide Area Network), VPN, dedicated lines
Security foundation	IAM (Identity and Access Management), WAF, monitoring
Platform	K8s (Kubernetes), CI/CD, observability
End-user environment	PC, mobile, MDM (Mobile Device Management)
Tech standards / guidelines	Selection rules

Cloud strategy

The most important TA decision is cloud strategy. Multi-cloud sounds nice, but operational complexity spikes - realistically, primary cloud + auxiliary cloud is more often chosen.

Strategy	Content	Suited for
Single cloud	Concentrate on 1 vendor	Small/mid, speed-focused
Primary + Secondary	Master-slave	Want risk distribution
Multi-cloud	Distribute across multiple	Large enterprise, risk-tolerant
Hybrid	On-prem + cloud	Migration period, finance, etc.

Multi-cloud reality is 3x operations, 2x cost - without clarifying “the meaning of doing it,” only burden without effect.

Standard tech stack

Defining languages, frameworks, and DBs recommended company-wide is the standard tech stack. Multiple stacks may exist, but realistically narrowing to within 5-10 is operational.

flowchart TB
    STD([Company-wide standard stack])
    LANG[Server language<br/>Python / TypeScript / Go]
    FE[Frontend<br/>React + Next.js]
    MOB[Mobile<br/>React Native / Swift]
    DB[(DB<br/>PostgreSQL / BigQuery)]
    CACHE[(Cache<br/>Redis)]
    MQ[Messaging<br/>Kafka]
    INFRA[Container platform<br/>Kubernetes]
    STD --> LANG
    STD --> FE
    STD --> MOB
    STD --> DB
    STD --> CACHE
    STD --> MQ
    STD --> INFRA
    BAD[Edgy emerging language /<br/>custom FW]
    BAD -.|rejected by tech committee| STD
    classDef root fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef tech fill:#dbeafe,stroke:#2563eb;
    classDef bad fill:#fee2e2,stroke:#dc2626;
    class STD root;
    class LANG,FE,MOB,DB,CACHE,MQ,INFRA tech;
    class BAD bad;

Area	Example (hypothetical company)
Server language	Python, TypeScript, Go
Frontend	React + Next.js
Mobile	React Native, Swift
DB	PostgreSQL, BigQuery
Cache	Redis
Messaging	Kafka
Container	Kubernetes

“Putting in trendy languages” bloats standards, so strict management via tech committee is needed.

Tech-selection process

Set up a formal process to make new tech standard. Prevent individual projects from arbitrarily adopting, standardizing through evaluation, verification, and agreement.

Step	Content
1. Proposal	Someone proposes candidate tech
2. PoC	Verify at small scale
3. Evaluation	Cost, operations, talent, etc.
4. Committee review	Discuss in tech committee
5. Standardization	Create guidelines
6. Deployment	Phased adoption expansion
7. Review	Periodic review

Technology Radar

The technique visualizing tech trends proposed by ThoughtWorks, with many companies making in-house versions. Classifying tech in 4 quadrants of Adopt / Trial / Assess / Hold, sharing the company’s tech strategy.

Quadrant	Meaning
Adopt	Use as standard tech
Trial	Experiment in projects
Assess	Gathering info
Hold	Should avoid

Reviewed semi-annually, functioning as a mechanism penetrating tech trends into the org.

Platform (common foundation)

TA also defines internal common platforms. Rather than each project building independently, use common foundations for efficiency. This is Platform Engineering territory.

Common foundation	Content
Kubernetes Platform	Company-wide container-execution foundation
CI/CD Platform	Unified deploy pipeline
Observability Platform	Company-wide monitoring foundation
API Gateway	Unified API entrance
Identity Platform	Auth / authorization foundation
Data Platform	DWH / data lake

The modern trend is integrated provision as Internal Developer Platform (IDP), with Backstage as the representative OSS.

Network design

Company-wide network composition is also TA’s scope. Systematize global WAN, inter-site connection, and cloud connection.

Element	Content
Global WAN	Connect sites
SD-WAN	Software-defined WAN
SASE	Security-integrated WAN
Cloud connection	Direct Connect, ExpressRoute
VPN / ZTNA (Zero Trust Network Access)	Remote access
DNS strategy	Internal/external DNS management

Security foundation

TA defines the security foundation uniformly applied company-wide. With individual projects making their own, you become hole-ridden.

Foundation	Content
IdP (Identity Provider)	Okta, Azure AD, etc.
MDM	Endpoint management
EDR (Endpoint Detection and Response)	Endpoint detection
WAF (Web Application Firewall)	Web protection
SIEM (security log integrated analysis) / SOC (Security Operation Center)	Monitoring / response
CASB (Cloud Access Security Broker)	SaaS-usage management
SSE / SASE (network + security integrated service)	Security integration

Security standardization matters in both compliance and efficiency aspects.

Lifecycle management (technology)

Technology has lifecycles too. Continuing to use EOL (End of Life) products becomes security risk, requiring planned updates.

State	Response
Latest	Recommended adoption
Supported	Adoptable
EOL announced	Update plan
EOL passed	Emergency update needed
EOS (Support ended)	Immediate response

Windows Server, PostgreSQL, Java - grasping each product’s EOL schedule and planning updates ahead is TA’s job.

FinOps (cloud-cost optimization)

The important area of modern TA is FinOps (Financial Operations). Cloud cost grows endlessly if neglected, requiring mechanisms for visualization / optimization organization-wide.

FinOps activity	Content
Visualization	Per-department / per-project cost
Reserved instances	Long-term contract discount
Spot Instance	Cheap use of surplus resources
Auto-scale	Auto-reduction by demand
Stop in non-operating hours	Night / weekend stops

FinOps tools like CloudHealth, Kubecost, CAST AI are spreading. The key is penetrating cost-consciousness as organizational culture.

Decision criterion 1: company scale

TA detail is decided by company scale. Excessive at startups, required at large enterprises.

Scale	Recommended
Startup	1 cloud, 2-3 languages
Mid-size	Standard stack + exception rules
Large enterprise	Full TA + tech committee
Global	Per-region TA aligned with company-wide TA

Decision criterion 2: regulatory / security requirements

Finance, medical, government see TA heaviness spiking. Tech selection freedom drops, becoming operations of using only permitted products.

Industry	TA strictness
Finance / insurance	Extremely strict (FISC = Financial information system safety standard, etc., compliant)
Medical	Extremely strict (HIPAA etc.)
Government	Whitelist system
General companies	Standard + exception handling
Startups	Loose, speed-focused

How to choose by case

Startup / single cloud

AWS or GCP 1 vendor + 2-3 languages + leverage managed services. TA committee unneeded, founder CTO’s head is the standard. FinOps via CloudHealth free tier or AWS Cost Explorer for monthly review, EOL management on 1 spreadsheet.

Mid-size enterprise / Primary + Secondary

AWS primary + Azure secondary + 5-10 standard stacks + Technology Radar. EA-cum-tech-committee quarterly, build IDP with Backstage, unify LLM Gateway via Portkey / LiteLLM.

Large enterprise / multi-cloud / regulatory compliance

3 clouds + whitelist system + dedicated tech committee + FinOps team. Dedicated team per cloud, SIEM/SOC 24/7 ops, adopt only FISC- or HIPAA-compliant products. EOL has migration plan from 2 years prior, AI foundation on on-prem GPU + internal LLM Gateway.

Global large enterprise

Per-region TA + company-wide TA + data-residency compliance. Europe in GDPR-compliant stack, China in independent cloud (Alicloud etc.), common via Identity Platform and API Gateway integration. Place Platform Engineering org centrally with regional specialists.

Standard-stack-management numerical gates

Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.

The TA lifeline is balance of allowing freedom while binding via standards. Below are industry-standard management metrics.

Metric	Recommended	What to do if exceeded
Standard tech-stack count	Within 5-10	Strict management by tech committee
Used cloud count	1-2 (primary + auxiliary)	Multi has 3x ops, 2x cost
Systems within EOL 6 months	0	Emergency update plan
Technology Radar update frequency	Semi-annually	Operations not becoming outdated
Exception-tech approval rate	10% or less	Off-standard requires justification
Cloud cost / revenue ratio	5% or less (industry-dependent)	Optimize via FinOps
Unused-resource rate	10% or less	Night stop, auto-reduction
Reserved-instance coverage	60-80%	Commit-contract for continuous workload
Patch-application SLA (Critical)	Within 72 hours	EOL neglect absolutely forbidden
FinOps review frequency	Monthly	Habit of seeing billing every month

The reality is multi-cloud is 3x ops, 2x cost. The realistic answer is starting with single-cloud base unless you can clarify “the meaning of doing it.” Multi-million-yen monthly cloud cost sees 20% monthly reduction normal with FinOps dedicated, with neglect leading to billing explosion shaking management.

Multi-cloud is only when there’s a clear reason. Choosing at scales unable to operate is the breakdown route.

TA-operation pitfalls and forbidden moves

Typical accident patterns in TA. All tilt enterprises as the cost of no tech constitution.

Forbidden move	Why it’s bad
Departments freely choose clouds, languages, DBs	3 clouds, 6 languages, 4 DBs mixed in 5 years, zero talent fluidity, doubled ops cost
Respond to EOL after it comes	Migration takes months to years, plan from 2 years prior is realistic
Don’t see cloud bills	Cases of 47 unused EC2s, JPY 1.2M monthly burn
Stay on-demand without buying reserved instances	Miss 30-70% cost-reduction opportunities
Build per-department security foundations	The 2017 Tesco Bank pattern, GBP 16.4M fine
Don’t make Technology Radar, miss innovation	Standardization rigidity, engineer attrition
Adopt multi-cloud without ops regime	Both half-baked, all unoptimized
Handle AI workloads with legacy TA	GPU requirements, vector DBs, LLM Gateway missing
Leave LLM API usage unrestrained	Per-department individual contracts, cost explosion and governance lacking
Don’t make Internal Developer Platform (IDP), each team operates independently	Unstandardized inefficiency, unify via Backstage etc.
Believing “tech standards stop innovation”	Promote experimentation via Radar while standardization stably supplies — balance matters
Believing “multi-cloud is safe” and adopting it	Operational cost explodes, all half-baked — becomes liability without clarifying the purpose
Leaving EOL as “handle it when it comes”	Migration takes months to years, planning from 2 years prior is realistic
Leaving cloud as “it auto-optimizes”	Opposite — neglect explodes waste, FinOps is active activity

When AWS monthly billing was visualized at a company, the case was reported where 47 EC2 instances no one was using lined up, burning about JPY 1.2M monthly. Culprits: “instances launched for PoC by a former predecessor who left” and “GPUs forgotten to stop after verification ended.” The cloud silently floods the pool when you leave the taps open. FinOps doesn’t run without “someone watching the water meter daily.”

The 2017 Tesco Bank outage (online banking full stop 48 hours, about 40,000 accounts unauthorized transactions, GBP 2.6M compensation + GBP 16.4M fine) is told as a case where disparate security standards left attackers’ loopholes.

TA is not the enemy of freedom but the premise of sustainable freedom. Standards exist so differentiation can concentrate.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Cloud strategy (single / multi)
• Standard tech stack (languages, FW, DB)
• Tech-selection process (Radar, committee)
• Common platform (K8s, CI/CD, monitoring)
• Security foundation (IdP, WAF, SIEM)
• FinOps regime (cost visualization)
• AI foundation (GPU, LLM Gateway, vector DB)

Author’s note - cases of orgs collapsing “without tech constitution”

Cases showing what happens to orgs whose tech stacks explode without TA recur in the IT industry.

A mid-size software company under the policy of “respect dev-team freedom” let departments choose clouds, languages, and DBs freely - and 5 years later, 3 clouds AWS/Azure/GCP, 6 languages Java/Ruby/Python/Node.js/Go/Scala, 4 DBs MySQL/PostgreSQL/MongoDB/DynamoDB mixed - with the ops team spending half a year just on new-hire training, and no one able to optimize reserved instances per cloud - cases often told at industry dinners. The cost of “freedom” was double infrastructure cost and zero talent fluidity.

Another, the 2017 UK Tesco Bank outage is a famous case caused by lack of tech standardization. In November 2016, online banking detected unauthorized transactions on about 40,000 accounts, and Tesco Bank stopped all online services for 48 hours, eventually receiving GBP 2.6M customer compensation and GBP 16.4M FCA fine. Subsequent investigation revealed disparate security standards (different auth/monitoring settings per department) had left attackers’ loopholes. A case slapping home that “allowing tech freedom without tech constitution becomes security holes.”

Both show that TA isn’t the enemy of freedom but the premise of sustainable freedom. Because standards exist, individual projects can concentrate on the parts that should truly differentiate - this paradox is TA’s essential value.

How to choose

The core of TA is the thinking of creating the constitution of enterprise tech choice. Departments arbitrarily selecting tech generates stack explosion, talent fluidity drop, and security non-uniformity, producing hundreds of millions yearly in waste at large enterprises. TA’s work is systematizing cloud strategy, standard stacks, common platforms, and security foundations company-wide, demanding justification for deviations. But the important thing is balance: don’t rigidify, promote experimentation via Technology Radar while standardization stably supplies. Multi-cloud reality is 3x ops, 2x cost — becomes liability without clarifying “the meaning of doing it.”

AI-era decision axes

When AI-driven dev (vibe coding) and AI usage are the premise, TA gains the aspect as execution foundation for AI agents. AI workloads have special GPU/memory/communication requirements unhandleable by legacy TA, requiring AI-specialized foundation design.

AI-era addition	Content
GPU foundation	NVIDIA H100, L4, etc.
Vector DB	Pinecone, Weaviate
LLM API Gateway	Central management, cost visibility
Prompt management	Unified company-wide management
AI Observability	LangSmith etc.

Centrally managing LLM API usage and integrating use of OpenAI, Anthropic, Gemini and billing — AI Gateway is a new TA component. AI Gateway (Portkey / LiteLLM) central management has become required equipment for both cost visualization and governance.

AI-era TA needs extensions premising GPU, vector DB, LLM.

Selection priorities

1. Single-cloud base realistically - multi explodes operations, primary + auxiliary realistic answer
2. Narrow standard stack to 5-10 - strict tech-committee management, prevent bloating
3. Coexist innovation via Technology Radar - Adopt / Trial / Assess / Hold, semi-annual review
4. Design AI foundation as new TA component - GPU, vector DB, LLM Gateway, AI Observability

“Constitution of tech choice, innovation promoted via Radar.” AI era’s new components are GPU and LLM Gateway.

Summary

This article covered EA-perspective Technology Architecture, including cloud strategy, standard stacks, Technology Radar, FinOps, IDP, and AI-era GPU/LLM Gateway.

Single-cloud base, narrow standard stack to 5-10, coexist innovation via Technology Radar, design AI foundation as new TA component. That is the practical answer for EA-perspective TA in 2026.

Next time we’ll cover EA Frameworks (TOGAF, ArchiMate, Tailoring).

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.