Why Past Success Patterns Can Mislead Modern Architecture Design

Recently I have to lead an architecture team for a new version, so I wrote some basic logic to build a first‑level strategy model for the team, providing a foundation for later discussions; the problem is universal and contains no confidential details, so I share it publicly.

Architecture work is highly flexible and the least suitable for applying past successes to guide new strategy design; even if your previous domain resembles the current one, past successes can only serve as references, not as templates to copy.

Because even identical domains differ over time—industry ecosystems, technology, people, business bottlenecks, stakeholder investments, talent pools, and former market leaders—all change, we must not let past "definitions" dictate our judgment. New architecture can reference successful patterns, but analysis must be based on present conditions and current problem investigation, not on blindly reusing old models.

This is my first recommendation for product strategy design.

Architecture design is a subtle discipline built on metaphysical logic; it is abstract and non‑concrete, yet that abstraction must be implementable, otherwise it becomes mere theory. We must avoid saying "the architecture should be X, but we lack manpower"—such reasoning is useless. Architecture must be grounded in implementation readiness; you cannot separate design from execution or claim constraints prevent design.

Architecture design is part of the implementation team, not an independent entity. About 90% of architecture work assists the implementation team in executing and challenging the architectural strategy; separating people is meant to ensure investment, not to create a competing team.

Conversely, you cannot base a design solely on current headcount because circumstances evolve. Early in architecture, you may have many people you cannot fully utilize; excess staff becomes a burden, and future staffing changes may be unmanageable. Architecture must be responsive to variations in manpower, resources, and market conditions.

Therefore, from the start we should plan multi‑step strategies, using the entire market opportunity as the upper bound for growth, and during execution consider how to gradually boost investor and market confidence to expand the business orderly. Architecture must anticipate others' mistakes and integrate with all product forces—development, sales, maintenance, finance, legal—without existing in isolation.

This is the second recommendation.

A practical tip: when drafting an architecture, focus on the customer as the target and engineering as the metric.

In practice, the first part of the architecture should clearly state what you intend to sell and what customers will buy, establishing control factors that guide all subsequent changes and obstacles, and indicate the direction after overcoming them.

The final part of the architecture should translate all designs into concrete "versions" and "projects". Human resource management must be project‑based, with clear goals and resource allocation, rather than vague ad‑hoc assistance. The hope of implementing the architecture should rest on resource management, not on abstract expectations, justice, or morality.

Here, "project" is used in a broad sense, not limited to a specific workflow.

Projects must deliver concrete versions—hardware, software, plugins—each with its own versioning; avoid vague references like "my‑wonderful‑app" without specifying version details.

When your software reaches the market, customers have diverse requirements; you must decide whether a single version or multiple versions will serve them. Products inevitably have bugs, new features, and fixes, which introduce further bugs, so customers may accept a bug‑fix upgrade but not a version addressing unrelated issues.

This leads to many market versions, which naturally increase development, testing, maintenance, and management costs—a critical engineering control factor.

If you design around a single concept like "my‑wonderful‑app", implementation will become chaotic because you actually develop multiple versions (v1, v2, v2.1, etc.), making resource and project forecasts inaccurate and execution impossible.

Many misunderstand "open‑source delivery"; it actually reduces version proliferation by allowing one source tree to compile many binaries. Providing source code shifts maintenance cost to the customer, but the customer may be a competitor or simply need a solution. Even with source delivery, commercial products still require testing across binary versions, and you must recognize that these binaries will evolve.

Fundamentally, architecture design must stay grounded in engineering costs; any idea involving engineering must be realistic, not fanciful.

Third recommendation: combine investigation with design. Early architecture faces countless unknowns—competitors' strategies, customer expectations, research breakthroughs, market share forecasts, policy trends, etc. Waiting for complete investigation before deciding leads to paralysis, so you must make educated guesses, assess their investment‑return trade‑offs, and proceed.

Architecture is essentially a guess; execution based on that guess must be flexible. Insisting on saving face and refusing to adjust when a guess proves wrong leads to failure.

Thus, architecture should not be about saving face; focus solely on the product's ultimate success, ignoring external opinions.

Fourth recommendation: do not expect the implementation team to like you. All actions aim to guide them around obstacles; they may dislike your conclusions. Use personal charisma to soften conflicts and share development pressure, but recognize that a comfortable implementation team will render your architecture ineffective.

Consequently, when you decide to do architecture, do not expect to be overly nice; the role is inherently uncooperative. Listen to implementation complaints but distinguish genuine feedback from strategic cost burdens.

Final recommendation: architecture teams span multiple domains; avoid labeling yourself as a representative of a single field (chip design, security, kernel, database). The team's purpose is to design gaps between modules and coordinate them for optimal efficiency. As a member of the architecture group, you represent the entire product, not a single module.

Most investors lack technical expertise; even those with a technical background view your implementation as a black box. Their decision‑making relies on multi‑party confirmation.

If the architecture team cannot reach consensus, convincing investors or customers becomes impossible. Every member should understand the whole architectural strategy. While I don't expect a chip engineer to code, they must grasp software architecture requirements and their role in solutions. You must know how ACPI tables affect the kernel, not just wait for requirements.

Broadly, a product architecture team must consider the entire industry ecosystem, not just its own product. Like a wolf depends on sheep, the architecture must understand ecosystem limits and know when to pull back.

Therefore, a product architect must comprehend the whole ecosystem, be willing to allocate parts of their business to other products or companies, and accept responsibilities that others may not want, thereby gaining control over the ecosystem.

These are the main ideas; the rest concerns specific business implementation. When difficulties arise, revisit the overall thinking—what seems like a dead end may reveal a path, and smooth progress may signal an upcoming crisis.