About this article
As an addendum to the âCase Studiesâ category in the series âArchitecture Crash Course for the Generative-AI Era,â this article explains the public / local-government systems case.
Unlike private SaaS, public systems are bound by unique constraints of âgovernment-cloud certification,â âprocurement constraints,â â10-year-unit operations,â and âresident-data handling.â This article organizes selecting certified vendors, complying with government standardization (local-government information-system standardization), and proceeding with design incorporating procurement procedures.
What is public-system architecture in the first place
Imagine city-hall counter services. Unlike private services, âthe obligation to serve all residents equally,â âproper execution of public funds,â and âdesign that keeps running even when staff transferâ are fundamental premises. Fairness, transparency, and long-term stability take priority over efficiency and speed.
Public-system architecture is designed within constraints fundamentally different from private SaaS: government-cloud certification, procurement procedures, 10-year-unit operations, and strict management of resident data.
If you design with a private-sector mindset, adopting non-certified vendors forces procurement redo, or you end up with a system that doesnât meet government standardization requirements and canât be used.
Why public-system-specific design is necessary
Because private-sector design conventions donât apply as-is
Public systems operate under entirely different rules from private SaaS: only government-cloud-certified vendors can be used, procurement takes half a year to a year, and standardization-target operations have customization banned in principle. Bringing private-sector success directly causes procurement-stage redo.
Because the mission of âequally for all residentsâ dictates design
Public systems prioritize fairness, transparency, and continuity over profit maximization. Lock-in to specific vendors, dependence on specific devices, and person-locked skills are fatal in public organizations where staff transfer every 2-3 years.
Because design premises 10-20 years of operation
Against the private sectorâs 3-5 year rebuild cycle, public systems premise 10-20 years of operation. Cutting-edge tech or niche languages carry the risk of not being able to secure maintenance talent 10 years out. âMature tech + certified vendors + standard complianceâ becomes the iron rule because of this long-term operation premise.
3 major premises of public systems
Entering design with the same feel as private will definitely get stuck. The 3 constraints to grasp first are below.
flowchart TB
GOV[Public / local-gov systems]
A[1. Government cloud<br/>certified vendors only]
B[2. Procurement procedures<br/>specs, bidding, multiple-vendor quotes]
C[3. Long-term operations<br/>10+ years, premise of staff transfers]
GOV --> A
GOV --> B
GOV --> C
classDef gov fill:#fef3c7,stroke:#d97706,stroke-width:2px;
classDef cons fill:#fee2e2,stroke:#dc2626;
class GOV gov;
class A,B,C cons;1. Only government-cloud-certified vendors adoptable
Only vendors certified by the Digital Agency can be used in public systems. As of 2026, AWS / Azure / GCP / Oracle Cloud / Sakura Internet are certified. Cloudflare or individual SaaS basically canât be used.
2. Procurement procedures take half-a-year-to-1-year units
From spec creation -> public notice -> bidding -> winning bid -> contract takes at least half a year. To run agile, system-design review is needed â currently the method of pseudo-agile via phased contracts (requirements-definition contract -> development contract) has settled in.
3. 10-year operations premised
Against private spans of 3-5 year rebuilds, public is normally 10-20 year operations. Since staff also transfer in 2-3 years, compositions depending on specific personâs tacit knowledge will definitely break down.
Recommended stack (overall picture)
For public, the triad is âmature tech + certified vendors + standard compliance.â
| Area | Recommended | Reason |
|---|---|---|
| Cloud vendor | AWS / Azure (government-cloud-certified) | Digital Agency standard adoption |
| Language | Java / C# / TypeScript | Easy talent procurement, writeable 10 years later |
| FW | Spring Boot / .NET / Next.js | Mainstream and stable |
| DB | PostgreSQL / Oracle | ACID required, long-term-operation track record |
| Auth | LGWAN-ASP / My Number integration / internal AD | Public-specific auth foundations |
| ID foundation | J-LIS (Japan Agency for Local Authority Information Systems) | Linkage with resident-registry network |
| Monitoring | Vendor-standard + 24/7 staffed | Specified in SLA |
Latest tech and edgy languages are forbidden from talent-acquisition perspective. The iron rule is leaning to languages with people writing 10 years later.
Standardization (local-government information-system standardization) compliance
The government policy is running for all 1,741 local governments nationwide to migrate to âstandard-compliant systemsâ for 20 operations including resident records, taxes, and welfare by end-FY2025. Custom modifications for these operations are now banned in principle.
| Class | Response policy |
|---|---|
| Standardization-target operations (20) | Select standard-spec-compliant products, customization forbidden |
| Standardization-target-out operations | Custom dev possible, but integration APIs with standardization targets are specified |
| Non-business systems (internal portal etc.) | Private-level freedom |
The modern front-runner is selecting packages compliant with âstandard specsâ (Fujitsu, NTT Data, Hitachi, etc.) and Fit to Standard (matching business side to product). Customizing packages while keeping unique business-side requirements is the same rut as the Lidl SAP eLWIS incident.
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?â
| Item | Choice examples |
|---|---|
| Government-cloud selection | AWS / Azure / GCP / Oracle / Sakura |
| Whether standardization target | 20 operations applicable -> standard-compliant / out-of-target -> custom design possible |
| Auth foundation | LGWAN-ASP / My Number / internal AD |
| Procurement method | General competitive bidding / planning competition / random contract |
| Operation period assumption | 5 years / 10 years / 20 years |
| BCP level | RPO 1 hour / RTO 4 hours (standard) |
| Audit requirements | Personal Information Protection Ordinance / J-SOX-equivalent |
| Multilingual support | Japanese only / multilingual (foreigners-in-Japan support) |
Pitfalls and forbidden moves
| Forbidden move | Why itâs bad |
|---|---|
| Agile development âwithout agile contractâ | Spec changes need additional contracts, ends up waterfall |
| Adopt emerging languages / FW | Talent procurement gets stuck 10 years later, same as transferred staff |
| Depend on individual staffâs operational work | Disappears on transfer, Runbook and automation required |
| Custom-modify standardization-target operations | Government-policy violation, off subsidy targets |
| Adopt non-certified clouds / non-certified SaaS | Pointed out in audits, procurement redo |
| Preserve manual Excel aggregation | Lost business-reform opportunity, long-term increased maintenance cost |
| Store personal info in overseas data centers | Legal violation, resident-lawsuit risk |
| Total dependence on retiring vendors | Black-boxed on withdrawal, maintenance continuation difficult |
The correct answer for public is âaccumulating mature choicesâ over âoffensive designâ.
| âBring in a private SaaS success setupâ as-is | Non-certified for government cloud = canât procure, breaks down on audit and resident-data requirements | | âCanât predict tech 10 years outâ so adopt trending tech | Gets stuck on staff transfers and talent procurement â mature languages (Java / C#) are the iron rule |
AI decision axes
| AI-favored | AI-disfavored |
|---|---|
| Standard-compliant + IaC + Git management | Custom settings, Excel manuals |
| Markdown-ized operational manuals | Word/PDF vendor delivery |
| Certified-vendor AI features (AWS Bedrock etc.) | Non-certified AI SaaS (direct ChatGPT integration etc.) |
| RAG-premised standardized business data | Per-section scattered Excel data |
- Choose from government-cloud-certified vendors â out-of-scope canât be procured
- Standardization-target operations Fit to Standard â custom modifications violate government policy
- Lean to languages / FW with talent 10 years later â edgy selection gets stuck in HR
- Operations automated, Markdown-ized â design premising staff transfers
Summary
This article covered the public / local-government systems case, including government cloud, standardization, procurement constraints, 10-year operations, and AI-era explanation responsibility.
Choose from certified vendors, stick to standard compliance, look ahead to talent acquisition, prepare for staff transfers via automation. That is the practical answer for public systems in 2026.
Next time weâll cover the âmobile-app dedicatedâ case. Plan to handle judgment axes unique to mobile vs Web â iOS/Android both supported, store reviews, E2E encryption, etc.
I hope youâll read the next article as well.
đ Series: Architecture Crash Course for the Generative-AI Era (84/89)