Large-Enterprise Core - Design Holding Up Organizationally Over

About this article

As the fourth installment (final) of the “Case Studies” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains the large-enterprise core case.

For ERP / HR / accounting / sales management at 1,000+ employees, or finance / medical / public regulated areas, “stability, audit, governance” is highest priority over “speed”. Before tech selection, “who approves what” is the design target. This article handles auditability, change-ease, long-term support, legacy integration, vendor selection, and SoR/SoE separation.

What is large-enterprise core architecture in the first place

Imagine running a hotel chain. Unlike a private B&B, “audit compliance,” “legal requirements,” “10-year equipment plans,” and “training thousands of staff” are all givens. A design that meets safety standards and withstands long-term operation beats trendy interior design every time.

Large-enterprise core architecture works the same way: stability, audit, and governance outrank speed. Fit to Standard — matching business processes to package defaults (SAP, Oracle, etc.) — is the mainstream, and full-scratch builds are almost never chosen anymore.

If a large enterprise chases the latest tech with custom implementations, it can’t staff maintenance, fails audit, and turns into debt within 5 years.

Why large-enterprise core design is unique

Because “design that holds up organizationally” matters more than the technical optimum

In large-enterprise core, the technically best option is not always the best choice. With thousands of developers, hundreds of teams, and multiple vendors involved, “who approves,” “who maintains,” and “will talent exist in 10 years” come before tech selection.

Because audit and legal compliance dictate design

In regulated industries — finance, healthcare, public — audit trails, change-approval flows, and data-retention periods are legally mandated, heavily constraining design freedom. Neglecting this produces the worst outcome: a finished system that can’t pass audit and can’t be used.

Because coexistence with legacy is a given

Large enterprises always have legacy systems running for 10-20 years, and the realistic answer is phased migration via the Strangler Fig pattern, not a big-bang rewrite. The approach is fundamentally different from startups designing only new systems.

Selection basic policy

The core of this area is the 3 points of auditability, change-ease, long-term support, with strong tendency for mature tech chosen over latest tech. Vendor maintenance period, SLA, compatibility with existing assets, and breadth of talent market are emphasized over technical excellence.

Representative profiles are ERP, accounting systems, HR/payroll, sales management, financial core systems, and medical-info systems. “Choosing because new” is the most dangerous basis in large-enterprise core.

Recommended stack (overall picture)

Large-enterprise core is premised on package adoption (SAP, Oracle, Salesforce, etc.), with the modern royal road being limiting custom to “operations the off-the-shelf can’t absorb.” Full-scratch is becoming almost-never chosen.

For custom dev, only differentiation elements unabsorbable by packages, ideal to suppress to 20-30% of total.

System / deploy choices

Even in modern times with public-cloud migration progressing, in many cases for large-enterprise core, hybrid cloud is the realistic answer. Existing on-prem assets, data-sovereignty requirements (can’t put personal info abroad, etc.), and existing-ERP-vendor contracts become practical barriers preventing full-cloud migration.

The standard for phased migration is building new development parts on public cloud (AWS / Azure) + containers + IaC, connecting with existing systems via API / event integration. Big-bang migrations replacing all at once have high failure rates — proceed with the Strangler Fig pattern (wrapping existing with new implementation and gradually replacing).

For large-enterprise core, tens-of-billions-yen-class big projects of full reform have extremely high failure rates — phased migration is standard.

Software / data choices

For custom-part language, Java / C# is mainstream — unchanged due to talent pool, LTS period, and depth of enterprise frameworks (Spring / .NET). TypeScript + Node.js is also a choice, but Java tends to remain strong in business-logic-heavy areas.

For DB, any of Oracle / SQL Server / PostgreSQL — ACID consistency is an absolute requirement. In accounting, inventory, and finance, eventual consistency isn’t allowed — strong-consistency transactions are needed. NoSQL, event sourcing, and CQRS limited to “areas where absolutely needed” — not used in core’s core.

Choosing NoSQL for accounting / inventory consistency requirements is wrong selection in nearly all cases.

Frontend / auth choices

For internal business-app screens, any of React / Vue / Angular is OK — choose to match existing-org skill set. Angular has persistent popularity in large enterprises, suited for large apps with TypeScript-standard, DI, and routing integration. When choosing React, often internally-accessible SPA rather than Next.js is enough, integrating auth with internal IdP.

The large-enterprise standard for auth is Azure AD (Entra ID) / Okta + SAML integrated with internal AD — users log in with employee ID. The modern compliance requirement is mandating multi-factor authentication (MFA) for all employees, with the recent flow also progressing Passkey support.

Building custom auth in internal systems is a hotbed of security incidents. Always lean to internal IdP.

Data / governance choices

Core-system data is treated as authoritative records (SoR = System of Record), the source for company-wide analytics, BI, and AI utilization. Master Data Management (MDM), data catalogs (Collibra / DataHub), and data lineage setup are required equipment at this scale. Personal information (PII) masking, GDPR / Personal Information Protection Act compliance, and audit trails are built in from design stage.

Aggregate analytics in DWH (Snowflake / BigQuery / Redshift / Azure Synapse), with fine control via Row Level Security, column-level encryption, and access logs. Standardize ETL/ELT business -> analytics with dbt, automating data-quality tests — the modern standard.

“Customer master scattered per department” at large enterprises is a typical antipattern. Solve via MDM setup.

Security / monitoring choices

Large-enterprise core security premises zero trust + compliance-audit response. The old perimeter model of network inside/outside has collapsed — design authenticating/authorizing every request is required. Per audit requirements like SOC 2 (US standard for service-org security), ISO 27001, PCI DSS (credit-card-industry data-protection standard), decide log-retention period, access control, and data-encryption levels.

For monitoring, enterprise products like Datadog / Dynatrace / Splunk are mainstream, premising SLA-equipped support contracts and 24/365 vendor response. Conduct annual incident-response process during failures, RTO/RPO, and BCP simulations too.

For large-enterprise core, audit response is a design premise. Adding later distorts design.

Large-enterprise core numerical gates

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

Large-enterprise core is the area operated with orders-of-magnitude numbers. Below are industry standards.

Lidl SAP eLWIS project (EUR 500M loss), Hershey Halloween incident ($100M loss) — tens-of-billions-class failures like these create the industry’s going rate. The iron rule for large-enterprise core is “mature tech, phased migration, Fit to Standard.”

Pitfalls and forbidden moves

Typical accident patterns in large-enterprise core. All have management-shaking-level destructive power.

Lidl SAP eLWIS (2011-2018, EUR 500M loss), Hershey Halloween incident (1999, $100M loss), Healthcare.gov 2013 launch failure ($2B added) — these are textbook failures showing the importance of design holding up organizationally over tech selection.

For large-enterprise core, organization logic over tech logic. Designs not passing executive-approval processes don’t get approved.

| “Technically correct so it’ll pass” — proposing with tech logic alone | Unless design passes all of talent, procurement, and audit processes, it gets rejected | | “Copy a startup’s successful setup” naively | Audit and governance requirements force a redo in 6 months — the right answer from a different context is poison |

AI decision axes

1. Hold up organizationally — talent / vendor maintenance / audit response
2. Fit to Standard — center on packages, suppress custom
3. Phased migration — leverage existing assets via Strangler Fig
4. Data asset-ization — organize via DWH / catalog / MDM

AI utilization of legacy systems starts with “data catalog setup”

When large enterprises attempt AI utilization, the first wall is that nobody can grasp the data structure of legacy systems. Tables updated by 30-year-old COBOL batches have column names in romanized abbreviations with no documentation — in such a state, neither leveraging data with AI nor connecting AI-generated code to legacy is possible.

The first step is data catalog setup. Gradually add COMMENTs (business descriptions) to table definitions, recording column meanings, value ranges, and related tables as metadata. AI can help this work too. Feed existing batch-processing code or SQL to AI and instruct “infer the meaning of each column in this table” to generate initial drafts.

Correct answers require human (business-expert) review, but cycling through AI-generated drafts with human review and correction significantly shortens time versus building catalogs from scratch manually.

Combining with the Strangler Fig pattern

When utilizing AI in large-enterprise core modernization, instead of wholesale replacement, the effective design is embedding AI during staged migration via the Strangler Fig pattern.

Specifically, use AI-generated code when building new parts as APIs, while humans design and review the existing-legacy connection interface (Anti-Corruption Layer). Existing system specs have much tacit knowledge where AI accuracy is low, but new-build parts can use standard tech where AI assistance is fully leveraged.

Managing each phase of this staged migration with IaC and CI/CD, and controlling old-new system switching via Feature Flags, minimizes migration risk while enjoying AI benefits in the new parts.

Author’s note — cases of “bending the package” cost

German major retailer Lidl progressed the SAP-based core-system reform project “eLWIS” from 2011, but in 2018 took a EUR 500M (about JPY 65B) special loss and canceled the project. The cause was, trying to heavily customize SAP to match Lidl’s unique product-coding system (an internal habit basing on purchase price), the divergence from package standard ballooned to maintenance impossibility. As “the cost of ignoring the principle of matching operations to packages (Fit to Standard),” still told in SAP circles.

US confectionery major Hershey in 1999 forced SAP big-bang migration just before the highest-demand Halloween period — the order system stopped functioning, unable to ship about $100M-equivalent chocolate, with quarterly revenue down 12% YoY. In the industry, told as “Hershey Halloween incident,” the standard case explaining big-bang migration’s danger and necessity of phased migration (Strangler Fig). Large-enterprise core establishing “mature tech, phased migration, Fit to Standard” as base lines — this can be said as the result of accumulated industry common sense about tens-of-billions-class failures.

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

For large-enterprise core selection, discuss in months units, deciding through formal approval processes. Below are items requiring agreement-building among management, legal, security, and IT departments.

• Package vs custom split (Fit to Standard principle)
• Cloud strategy (hybrid / public / data sovereignty)
• Auth foundation (internal IdP integration / MFA / Passkey support)
• Data governance (MDM / data catalog / PII management)
• Audit / compliance level (SOC 2 / ISO 27001 etc.)
• BCP / DR (numerical RTO / RPO definition)
• EA framework (TOGAF / ArchiMate etc.)
• Migration strategy (Strangler Fig / big-bang)

Related Articles

https://en.senkohome.com/arch-intro-case-ai-product/ https://en.senkohome.com/arch-intro-case-mobile/ https://en.senkohome.com/arch-intro-case-overview/

Summary

This article covered the large-enterprise core case, including Fit to Standard, Strangler Fig phased migration, hybrid cloud, data asset-ization, and design holding up organizationally.

Choose mature tech, migrate phased, pass org via Fit to Standard, asset-ize data. That is the practical answer for large-enterprise core design in 2026.

And this was the final installment of the “Case Studies” category. Next time we’ll start a new category (Appendix). Through antipattern collections, best-practice collections, and critical-incident collections, we’ll organize the judgment axes spoken throughout this series into practical references.

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.