Technology Architecture: The Constitution of Enterprise IT

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.

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

Technology sprawl eats the budget. When departments use different tech, talent fluidity drops and operational cost balloons. Standardizing optimizes talent placement, procurement, and operations.

It is what makes security and compliance achievable. Applying unified company-wide security standards premises tech-stack standardization. Disparate setups make audits and response impossible.

It is how you get the benefits of scale. 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.

Cloud strategy — the single most important decision

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

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

The standard stack and Technology Radar

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.

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

The process for selecting a technology matters as much as the list itself.

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

Technology Radar is how that list stays alive.

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.

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

The platform is what the standard stack is delivered on.

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

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

Network design is part of the same foundation.

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

So is the security foundation.

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

Security standardization matters in both compliance and efficiency aspects.

EOL management and FinOps

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

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

FinOps is the cost half of the same discipline.

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

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

How heavy it gets shifts with scale and regulation

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

The second axis is the regulatory and security requirements.

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

By case, the shape lands like this.

A startup on a 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.

A mid-size enterprise running a primary plus a 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.

A large enterprise on multi-cloud with 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.

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

Numeric gates for standard-stack management

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.

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.

AI decision axes — GPUs, vector DBs and LLM gateways are the new TA components

AI Gateway becomes the control point for company-wide LLM usage

As LLM API usage expands internally, teams individually contracting OpenAI, Anthropic, and Gemini leads to untrackable costs and unmonitorable usage. Designing centralized control of company-wide LLM traffic via AI Gateway (Portkey, LiteLLM, etc.) — with cost visibility, rate limiting, PII detection, and model routing — is a new essential TA element.

GPU foundation and vector DB placement design

When running LLM inference in-house or building RAG pipelines, GPU foundation (NVIDIA H100/L4) and vector DB (Pinecone, pgvector, Weaviate) capacity planning joins TA. Cloud GPU instances are expensive with supply constraints, making pre-secured capacity and cost estimation essential in TA design. 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.

Pitfalls and forbidden moves

Here are the six most dangerous of the typical ways TA goes wrong. Every one of them tips the company over as the price of having no technical constitution.

The assumption that “technical standards stop innovation” is wrong too. Encouraging experiments through the radar while standardising for stable supply — designing that balance is where TA shows its skill.

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.

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)

Related Articles

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.