Aligning Architecture with Business Revenue: Insights from a Senior Ctrip Architect

If an internet company's profit is assumed to be managed solely by business or product managers, the technology R&D team often becomes merely a tool for business, which is a misconception.

Architects tend to focus excessively on technology while neglecting the essence of business, delivering system or application architectures rather than product‑ready designs.

The author divides profit into two aspects—how to make money and how to save money—and has been applying this mindset to architecture design for several years to achieve technology‑driven business; the author is Chen Chang, a senior architect at Ctrip.

In the early stages of a startup or when a development department aims to grow, the architect’s role is evident: they translate product requirements into functional and non‑functional designs, consider operations, high availability, scalability, reduce inter‑system dependencies, conduct architecture reviews, identify risks, and select technologies.

When business needs change or a second phase is planned, architects often revert to reusing previous work, modifying contract documents, scaling machines, and becoming documentation experts, losing touch with coding and becoming dispensable; their lack of business knowledge leads to marginalization.

The causes identified are: (1) architecture inputs PRD and outputs design documents, making architects serve product managers; (2) missing a "nail" (e.g., a business framework) embedded in both development and business; (3) over‑emphasizing technology without considering product profit points.

To elevate the architect’s status, the author suggests: first, align architecture with business and the ecosystem; second, uncover profit points within the business; third, design a product‑oriented, commercializable architecture.

Architectural categories include platform, business, system, and application architectures; data architecture (offline + real‑time), infrastructure, technical, and peak architectures should all be understood and practiced for longer lifecycle designs.

Using a travel business case, the author illustrates a top‑down architectural thinking: building a business ecosystem by integrating multiple product lines, then mapping commercial scenarios to technical modules such as Shipping, Booking‑commit, Booking‑confirm, and backend services.

The resulting application architecture comprises services like user, product, shopping, booking, and order.

Focusing on profit, the author examines the booking service: unifying two separate booking interfaces into one improves maintainability but requires business buy‑in for a multi‑month technical refactor; potential profit avenues include commission per order, data‑driven pricing, channel allocation, faster market response, and connecting offline stores to a central system.

Such a central reservation system (CRS) not only solves business pain points but also increases order volume, enhances maintainability, unifies interfaces, and provides independence.

Key takeaways: architects should give product managers more choices rather than constraints; architecture must align with commercial vision and profit; think of architecture as a container (like an App Store) where compliant modules can be published; profit can manifest as higher output, cost savings, user value, service quality, experience, and rapid market response; ultimately, architecture should integrate product, technology, and operations.

Finally, the article promotes the 2016 APMCon China conference, co‑hosted by InfoQ and Tingyun, featuring technical leaders from Twitter, Alipay, Tencent, JD.com, NetEase, Sina, Tmall, and others, focusing on application performance management. Read the original article for details.