R&D Management 18 min read

Understanding Architecture: Goals, Resources, Behaviors, and Decision‑Making for Architects

The article broadens software architecture beyond structural design to encompass people, processes, and business value, urging architects to balance realistic, flexible goals, limited resources, commercial‑focused behaviors, and industry trends so they can deliver cost‑effective, scalable solutions that align technology with organizational objectives.

Amap Tech
Amap Tech
Amap Tech
Understanding Architecture: Goals, Resources, Behaviors, and Decision‑Making for Architects

Preface

In software engineering, architecture is often limited to system structural design (e.g., SOLID, DDD). A good software architecture helps teams develop efficiently, reduces maintenance cost, and improves scalability and maintainability. This article expands the definition: architecture also includes the people involved, the activities throughout a project, and the business value it creates.

What Is Architecture?

From a broad perspective, architecture is a complex, continuous activity that designers (architects) undertake to create commercial value for users within a given technical, cultural, and business environment, using limited resources and cost.

Architects must make correct choices in complex environments, ensuring that architectural activities proceed smoothly and that projects are delivered. This can be analyzed from four dimensions: goals, resources, behaviors, and trends.

Goals

Achievable : Goals should be realistic based on an assessment of capabilities, resources, and environment.

Specific and Clear : Goals must be measurable and broken down into smaller sub‑goals for effective tracking.

Flexible : Goals need elasticity to adapt to uncertainties and changes.

Continuous Monitoring and Adjustment : Goals are not set‑and‑forget; they require regular evaluation and refinement.

In practice, technical teams often pursue technically advanced solutions (e.g., switching from Kafka to Pulsar) without fully weighing migration cost, long‑term benefits, and team learning overhead. The ultimate aim of architectural activities is cost reduction and efficiency improvement.

Resources

Resources are limited. Architects must maximize commercial value within these constraints and help technical staff understand business value. Three pathways for engineers to generate revenue are highlighted (illustrated in the original diagram).

Key actions for individuals include:

Understanding the company’s or team’s business model.

Recognizing the commercial value created by one’s work.

Ensuring the long‑term commercial value of architectural activities.

Finding opportunities to increase revenue in architectural planning.

Finding opportunities to reduce cost in architectural planning.

Behaviors

Technical staff often focus solely on logical or numerical aspects, neglecting the commercial side. Effective architecture requires decoupling commercial activities from technology, recognizing that technology is a means to generate value, not the value itself. Collaboration and organizational coordination are essential.

The article references Maslow’s hierarchy of needs to explain how pressure and lack of security can drive short‑term, self‑preserving behavior that may undermine long‑term commercial value.

Trend – Timing, Location, and People

Understanding industry cycles and emerging technologies is crucial. Human tendencies such as self‑protection, fear of change, and path dependence can hinder adoption of new solutions. Architects must balance technical advancement with business impact, avoiding the “hammer‑as‑nail” trap.

Three levels of R&D activities are presented (illustrated in the original diagram): technical‑driven, product‑driven, and business‑driven, each with different emphasis.

Summary

The author, while studying a course on architecture, reflects on how architects should position themselves, how architectural activities safeguard commercial value, and how employees can execute and manage these activities across different layers. The insights aim to help practitioners translate technical work into business support.

Recommended Reading

Lane‑level Data‑Based Navigation Scenario Construction and Simulation

Android High‑Performance, High‑Stability Code Coverage Practices

Gaode Business DDD Practice: Refactoring Glue Code with Domain‑Driven Design

Gaode Data Optimization: OceanBase Best Practices

software architectureresource managementdecision makingtechnical leadershipbusiness value
Amap Tech
Written by

Amap Tech

Official Amap technology account showcasing all of Amap's technical innovations.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.