Public / Local-Government Systems

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.

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

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.

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

Pitfalls and forbidden moves

The forbidden moves that matter most in public systems.

For public systems, stacking up boring choices beats designing aggressively. “Bringing across a private-sector SaaS’s successful configuration” breaks down at uncertified procurement, and adopting a fashionable technology on the grounds that “nobody can predict the technology of ten years from now” dead-ends on staff rotation and talent sourcing.

AI decision axes — AI inside certified vendors, and machine-readable operations

Use AI features from government-cloud-certified vendors

When utilizing AI in public systems, using AI features from government-cloud-certified vendors (AWS, Azure, Google Cloud, Oracle Cloud, Sakura Internet) is the precondition. Sending government data to non-certified SaaS like ChatGPT is disallowed under security policy in most cases.

AI features within certified vendors — AWS Bedrock, Azure OpenAI Service, Google Cloud Vertex AI, etc. — keep data in domestic regions and can be used within existing security standards (ISMAP etc.). When including AI-utilization requirements in procurement specs, specifying certified-vendor service names by name makes procurement reviews easier to pass.

Markdown-izing ops procedures is the prerequisite for AI automation

Public system operations premise 3-5 year staff transfers. Ops procedure manuals delivered in Word/PDF repeatedly fail to be handed over during transfers or go unversioned and outdated.

Switching to storing ops procedures as Markdown in Git repos with version control yields two benefits. First, transfer handoffs are completed by just “granting repo access.” Second, Markdown procedures become usable as AI-agent input, enabling delegation of initial incident response and routine-task execution to AI.

Word-format procedure docs are human-only-readable, but Markdown procedures serve as “machine-readable operational knowledge” readable by both humans and AI, holding long-term value.

Related Articles

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.

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.