1. Everything Built on a Facade Will Shake
In spot consulting for large enterprise IT departments, one scene repeats. Systems are running. Business is flowing. But there is no structure.
Individual systems were built for individual requirements, then connected by APIs, CSV files, and Excel macros. No one holds the full picture. Each new requirement gets a new component tacked onto something existing.
Then one day, leadership says: "Let's do Enterprise Architecture."
But when you try to layer EA onto a facade, what happens? Reconciling with existing systems, navigating inter-departmental politics, estimating migration costs. Time is consumed not by essential structural discussion, but by debates over how to justify the current state.
The greatest enemy of EA is not technical debt.
It is the fact that "things are working right now."
2. EA as Initial Design
EA takes two forms.
| Retrofitted EA | Initial-Design EA | |
|---|---|---|
| Purpose | Organize and improve the current state | Define structural principles before building |
| Constraints | Existing systems, organizations, politics | None (design from a blank slate) |
| Output | Documentation of the status quo, phased migration plans | Design principles that guide decisions |
| Risk | Diluted by politics and compromise | Whether principles are upheld during implementation |
Retrofitted EA is like cartography — surveying and recording the roads of an existing city. Valuable in itself, but the city's structure doesn't change.
Initial-design EA is like urban planning — deciding where to run water pipes and power lines before laying roads. No need to dig them up later.
3. TokiStorage's Architecture
TokiStorage is a project run by one person. But it has design principles established from the start.
Principle 1: Data Is Self-Contained Within the QR Code
Voice and images are embedded as URL parameters within QR codes — the permanent data has zero dependency on external servers. Operational processes (order intake, contact forms, analytics) use Cloudflare Workers and GAS, but the data inscribed in QR codes plays back independently of those services. This principle means that server failures, service shutdowns, or corporate bankruptcy never result in data loss.
Principle 2: Separate Responsibilities by Layer
The QR generation tool, physical manufacturing, and three-layer preservation (GitHub, NDL, physical media) are designed as independent layers. Changes in one layer don't cascade to others.
Principle 3: Security Is Guaranteed by Architecture
Every piece of data in the pipeline is public by destination. The voice data in QR codes passes through Cloudflare Workers and GAS as part of the order process, but that data is destined for physical products, GitHub, and NDL — it is not secret. Credit card information is processed directly by Wise and never enters the pipeline. The pipeline carries no secrets. Code is published, so hidden vulnerabilities get found. The site is static, so server-side vulnerabilities don't exist. Security isn't "added" — there are no secrets to protect in the first place.
Principle 4: Governance Is Designed Per Layer
QR generation is client-side, so content is not screened. Physical products are private property, so they are not scanned. NDL deposit goes through newsletter editing, so content falling under prohibited uses may be declined. What is controlled, what is not, and why — all clearly defined per layer.
4. Governance Is Embedded in Architecture
In many organizations, governance is discussed separately from architecture. Security policy, data governance, compliance. Each has its own document, its own owner, its own committee.
But fundamentally, governance is part of architecture. "Who can control what" is determined by system structure. If the structure is ambiguous, governance is ambiguous.
In TokiStorage, governance is embedded in architecture.
- Privacy — the design of not sending data to servers makes data protection regulation compliance unnecessary
- Content control — the presence or absence of control, and its rationale, is defined per layer
- Transparency — published code makes governance a verifiable fact, not a verbal promise
- Permanence — data self-contained in QR codes is unaffected by changes in organizational governance structures
Don't "enforce rules" for governance.
Design structures where rules aren't needed.
5. A Question of Structure, Not Scale
There is a misconception that EA is for large enterprises. That it's a taxonomy for thousands of employees, hundreds of systems, dozens of departments.
But the essence of EA is "making structural decisions before implementation." That definition has no condition on scale.
Even in a one-person project, without upfront structure, every new feature brings indecision about "where to put this," judgment wavers, and technical debt accumulates. Conversely, with principles established first, decisions become natural. New features fall into place: "This belongs here, according to our principles."
EA is hard in large enterprises not because they are large. It's because they ran so far without initial design.
6. Multi-Stage Approval as Structural Defeat
Retrofitted governance inevitably arrives at multi-stage approval flows.
Structure is ambiguous, so no one can assess the risk of a change. Since risk can't be assessed, confirmation is sought from many people. Security review, architecture review, compliance check, department head approval. Back and forth, impeding the entire development lifecycle.
This is not the success of governance. It is the price of absent architecture.
When structure is clear, the blast radius of a change is self-evident. When self-evident, approval flows become lightweight. Organizations that need multi-stage approval are not "cautious organizations" — they are "organizations without structure."
7. Conclusion — First Design Lasts Forever
Architecture cannot be added later.
Design it first, or run forever without it.
There is no middle ground.
Enterprise Architecture is neither a framework name nor a consulting firm's product. It is the stance of "making structural decisions before implementation."
TokiStorage is a one-person project, but it has EA as initial design. That is why a QR generation tool can support physical manufacturing on top of it, NDL deposit on top of that, and content governance on top of that — all without the structure shaking.
Whether you're a large enterprise or a solo operator, the question is the same. Did you decide the structure first? That answer will echo across the entire lifespan of your project.