Is Business More Important Than Technology for Programmers?

I envied the company's business architects when I was young at a large tech firm.

In that company, architects were divided into three categories: business architects who build business process systems to boost external competitiveness; infrastructure architects who construct technical foundations; and data architects who conduct data research and report to executives.

The author focuses on the business architect role, describing three main activities:

Identifying the need for a new business system from scratch.

Visiting each department to connect existing systems and propose an abstracted solution.

Drawing pure‑business architecture diagrams that are completely independent of technology.

When disagreements arose, the business architect would propose a price system that all departments could read for base pricing, and later suggest a comparison system. He would sketch the entire workflow on the spot, answering questions instantly with clear logic.

The author admired his deep business knowledge, industry insight, and strong abstraction ability, noting that the architect solved large‑scale problems rather than isolated issues.

After the price and comparison systems were launched, business processes became smoother and execution efficiency improved significantly.

Another key responsibility was “going everywhere” to facilitate cross‑department collaboration. The architect would present the full business flow, solicit issues, and provide immediate solutions, including technical ones. He even designed a flexible MySQL‑based product table schema that supports dynamic fields, attribute inheritance, and recursive attribute resolution.

The author concludes that a person who understands both business and technology can make far greater contributions and earn senior management’s trust. However, this advantage assumes genuine deep business expertise, and it is especially valuable for engineers who stay within the same industry.