How Business Companies Can Drive Technical Architecture Evolution: A Practical Case Study

Jensen recounts how his company formed a virtual architecture committee under the direction of the VP of product research, tasked with a company‑wide infrastructure overhaul. The first step was to obtain top‑level leadership backing, emphasizing that architectural change requires both technical competence and executive influence.

Guided by the principles of focus, stability, linkage, empowerment, and demand‑driven development, the team adopted a three‑stage approach: Grab the core , Practice the framework , and Build the process . In 2021 the company migrated all business systems from Python to Java and split a monolith into over 30 microservices, exposing many cross‑cutting concerns such as audit field injection, token filtering, and encryption utilities.

These concerns were initially placed in a single common package, leading to two problems: (1) mis‑positioning—features drifted away from the core purpose, and (2) perspective bias—solutions were driven by developers rather than architectural goals. The team therefore re‑examined the common package, deciding to retain only core framework responsibilities and discard redundant parts.

The redesign introduced a new base framework called ygp‑base, organized into nine sub‑projects, each with a clear responsibility and a designated owner:

base‑dependencies : defines a compatible set of Maven artifact versions for internal libraries.

base‑tools : utility toolbox (ID generator, keyword desensitizer, regex validator, duplicate‑request interceptor, request‑parameter validator).

base‑web : micro‑service‑style web layer handling HTTP and RPC common concerns (identity, logging, exception handling).

base‑log : unified log format definition.

base‑dal : data‑access layer supporting relational (MySQL, Oracle) and non‑relational (Elasticsearch, MongoDB) stores with a common business‑operation abstraction.

base‑cache : Redis‑based caching component.

base‑utils : general‑purpose utilities, optionally wrapping Apache Commons, Guava, Hutool, etc.

base‑parent : Maven parent defining project‑wide conventions (Java version, encoding, dependency versions, testing standards, packaging rules).

base‑core : lightweight contract module providing core contracts such as identity context, request/response wrappers, generic exception, and Result class.

Design principles were codified into six rules: (1) thorough discussion to reach consensus, (2) inclusive yet pragmatic compatibility, (3) mixed‑architecture practice (layered + micro‑kernel), (4) adherence to GRASP and SOLID, (5) learning from established frameworks (Spring Cloud BOM, Spring Boot starter), and (6) minimizing usage cost through convention‑over‑configuration.

Two concrete cases illustrate decision‑making:

Case 1 – Sub‑project division and permission delegation : The team created a dedicated GitLab group base and split the work into the nine sub‑projects listed above, each with its own maintainer and strict access control.

Case 2 – Whether to relocate the Result contract class : A debate between a radical group (favoring a new standard) and a conservative group (preserving existing imports) concluded with the decision to keep the package path unchanged while applying the new standards, avoiding massive migration risk.

To promote the new framework, the team prepared presentation material covering design rationale, migration handbooks, and demo projects, conducted internal trial talks, and then held joint sessions with micro‑service owners across the organization. Regular stand‑up meetings and continuous discussion ensured steady output despite team members not being full‑time architects.

Finally, the article summarizes five key takeaways: leverage top‑down influence, respect business‑line representatives, clarify architectural vision and principles, maintain daily communication, and treat team‑wide evangelism as essential for adoption.