How to Identify Architectural Characteristics: Three Sources and a Top-3 Selection Process
This article explains three sources of architectural characteristics—domain concerns, project requirements, and implicit domain knowledge—and outlines a three-step process to extract explicit characteristics from requirements, supplement implicit ones from domain knowledge, and collaboratively select the top three driving characteristics that guide architectural decisions.
1. Three Sources of Architectural Characteristics
Architectural characteristics typically originate from three sources.
1.1 Domain Concerns
The first source is listening to key domain stakeholders to determine what matters most from a business perspective. The challenge lies in translation: architects speak of scalability, interoperability, fault tolerance, and availability, while stakeholders discuss mergers and acquisitions, user satisfaction, time-to-market, and competitive advantage. The two sides often fail to understand each other.
1.2 Project Requirements
The second source is the requirements document , the most direct input. Architects extract characteristics line by line from documented requirements.
1.3 Implicit Domain Knowledge
The third source is the architect's internal domain knowledge . These characteristics appear neither in requirements nor in stakeholder discussions.
2. Architectural Characteristics Identification Process
The identification process can be divided into three steps.
2.1 Extract Explicit Characteristics from Requirements
Read each requirement and ask: what system capability is needed to fulfill this requirement? The following examples illustrate the mapping:
Requirement: "Support thousands of users, potentially millions in the future" → Characteristic: Scalability
Requirement: "University promotion period: 1,000 registrations within 10 hours" → Characteristic: Elasticity (burst traffic)
Requirement: "Users can save personalized preferences" → Characteristic: Customizability
Requirement: "Support users from multiple countries" → Characteristic: Localization capability
Requirement: "Users log in to view personal homepage" → Characteristic: Authentication, Authorization
2.2 Supplement Implicit Characteristics from Domain Knowledge
Supplement based on domain concerns:
Concern: Mergers and integration → Characteristics: Interoperability, Scalability, Adaptability, Extensibility
Concern: Speed to market → Characteristics: Agility, Testability, Deployability
Concern: User satisfaction → Characteristics: Performance, Availability, Fault tolerance, Testability, Deployability, Agility, Security
Concern: Competitive advantage → Characteristics: Agility, Testability, Deployability, Scalability, Availability, Fault tolerance
Concern: Time and budget → Characteristics: Simplicity, Feasibility
Supplement based on domain experience:
Domain: Payments → Characteristics: Security, Data integrity
Domain: Social platforms → Characteristics: Observability, Maintainability
Domain: Financial industry → Characteristics: Auditability
2.3 Filter Top 3 Driving Characteristics
This is the critical step. Attempting to design a universal architecture that supports all characteristics leads to failure.
Limit to 7 candidate slots
The worksheet provides 7 slots on the left for listing desired architectural characteristics. The exact number is not important; the key is setting an upper bound to prevent the list from growing indefinitely.
Handle implicit characteristics
The worksheet's second column lists implicit architectural characteristics present in most systems. Sometimes architects elevate these to driving characteristics requiring special design consideration. In such cases, move the implicit characteristic from the second column to the first.
Eliminate and replace
If the first column's 7 slots are full and a more important characteristic emerges, move the existing characteristic to an "Others Considered" category to make room for the new one.
Collaborate to select Top 3
Work with stakeholders to choose the three highest-priority architectural characteristics (order does not matter, simply check them). These three become the driving forces behind architectural decisions and trade-off analysis.
3. Summary
Ultimately, identifying architectural characteristics answers the question: In this system, what is non-negotiable? Once this question is clear, subsequent architectural design will not lose direction. 1. Fundamentals of Software Architecture 2nd Edition Chapter 5↩︎
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.