YU CHENG, CHANG Taco

A piece of data, a rule, and a module responsibility should each have a clear source. When the same thing is scattered across different places and consistency depends on human memory, complexity begins to accumulate.

Early in my career at Evergreen International, I turned recurring EDI transformations and interface behaviors into configurable, reusable capabilities. At Walsin Lihwa, I further organized my implementation approaches into UI patterns and training materials that the team could adopt. I did not yet have a name for this; I only knew that duplicated rules should not exist independently.

At Gorilla Technology Group, the problem expanded to multiple brands, Shared Packages, and different delivery workflows. I began using a config-driven framework, monorepo, dependency boundaries, and CI/CD so that code, versions, and teams followed the same structure. Folder Structure was no longer merely documentation, but an architectural rule that diagrams could explain and ESLint could enforce.

If a rule can only be upheld through human memory, it is not yet a real rule of the system.

At Clinico, I saw more clearly that “sharing” does not mean putting everything together. It means identifying behaviors that are fundamentally the same and allowing them to exist only once, while preserving clear override boundaries for brand differences. Whether dealing with BPM, LIFF, multi-brand services, or data models between GraphQL and REST, I was addressing the same issue: preventing identical logic from gradually diverging as products evolve.

BTSE extended this principle from software architecture into collaboration. The impact scope of a multi-brand system could not be guessed, and cross-functional requirements, delivery, and testing responsibilities should not be interpreted separately. I therefore worked to calculate dependencies, provide QA with the affected pages, and align every role around the same set of facts.

At Cypher Lab Sdn. Bhd., this problem became even more direct once AI Agents entered the development workflow. AI can generate code quickly, but if architectural rules are scattered across people’s memories, documents, and tools, it only amplifies inconsistency faster. I therefore consolidated layering, boundaries, linting, CI, documentation, and the Agent Contract into Blueprint, allowing both people and AI to understand the system from the same source.

Looking back, the architectural tools I built were not unrelated efforts. From configurable systems, shared patterns, monorepos, and impact analysis to Architecture as Code, I have consistently pursued the same thing:ensuring that the system has only one true answer—one that can be understood, verified, and continuously evolved.