How Comprehensive Should Software Architecture Be?

Software architecture is widely recognized as a fundamental design artifact for complex software systems. However, its scope is interpreted quite differently across the software engineering community. In some contexts, architecture is viewed primarily as a high-level representation of major components and their relationships. In others, it encompasses multiple architectural perspectives, quality-related design decisions, design rationale, and sufficient technical detail to guide implementation and evolution.

This variation raises a fundamental question: What should software architecture actually encompass?

This article examines this question from the perspective of ISO/IEC/IEEE 42010 and argues that, particularly for large-scale and AI-based systems, software architecture should be regarded as a comprehensive architectural design rather than merely a high-level structural representation.

1. Why the Scope of Software Architecture Is Ambiguous

There is no single, universally adopted interpretation of the scope and level of detail of software architecture. Definitions in the literature emphasize different aspects. Some characterize architecture primarily in terms of a system’s fundamental structure and the relationships among its components. Others emphasize architectural styles, significant design decisions, stakeholder concerns, architecture views, quality attributes, or principles governing system evolution.

Another source of ambiguity is the common characterization of software architecture as high-level design. Architecture certainly operates at a higher level of abstraction than source code or detailed algorithm design. However, the term high-level can inadvertently imply that architecture should contain only coarse-grained structural information.

Such an interpretation may be adequate for a relatively simple system. For a large and complex system, however, identifying only major components and their relationships is unlikely to provide sufficient architectural guidance. Architects may also need to specify the allocation of functionality, organization and persistence of information, runtime interactions, deployment configurations, interfaces, quality-related design strategies, and other architecturally significant decisions.

As illustrated in Figure 1, the scope of software architecture can therefore range from a basic structural representation to a multi-view architecture and, for large-scale and AI-based systems, to a more comprehensive architecture incorporating quality-driven design decisions, rationale, and traceability. The issue is therefore not simply whether software architecture should be high-level or detailed. A more useful criterion is whether the architecture provides sufficient coverage of architecturally significant concerns and sufficient technical detail for its intended purposes.

2. Architecture in ISO/IEC/IEEE 42010

ISO/IEC/IEEE 42010 provides an important conceptual foundation for examining the scope of architecture. ISO/IEC/IEEE 42010:2022 specifies requirements for the structure and expression of an Architecture Description (AD) and distinguishes the architecture of an entity from the Architecture Description that expresses it [1]. The standard does not prescribe a particular architecting method, modeling notation, process, or tool.

Of particular relevance is the standard’s concern-oriented perspective. An Architecture Description addresses stakeholders and their concerns through appropriate architectural concepts and representations. Architecture viewpoints establish conventions for constructing and interpreting architecture views, while architecture views represent the system with respect to particular concerns.

Some concerns exert substantial influence on the architecture and therefore become important architecture drivers. These may arise from functional or quality requirements, business objectives, technological constraints, operational conditions, organizational policies, or other factors that materially influence architectural decisions.

This perspective has an important implication: an Architecture Description cannot generally be reduced to a single structural diagram. Different concerns may require different representations and architectural decisions. Functionality, information, runtime behavior, deployment, security, reliability, performance, and operation, for example, cannot ordinarily be represented adequately through one structural model.

ISO/IEC/IEEE 42010 therefore provides a conceptual basis for viewing an Architecture Description as a multi-faceted expression of architecture whose scope is determined by the architectural concerns that must be addressed.

3. A Practical Definition of Software Architecture

Considering representative definitions of software architecture and the practical demands of industrial software systems, the book Hands-on Software Architecture: Unified Architecture Process proposes the following definition:

The first sentence of this definition identifies three essential aspects of software architecture—system structure, architectural views, and architectural tactics—which correspond to Schematic Architecture, Design for Architecture Views, and Design for Non-Functional Requirements, respectively, as shown in Figure 2.

Schematic Architecture establishes the fundamental organization of the system. It defines major architectural elements—such as tiers, layers, partitions, components, and connectors—and the relationships among them. The resulting structure provides a stable framework for subsequent architectural decisions.

Design for Architecture Views represents the system from multiple perspectives. Different views enable architects to focus on distinct architectural concerns and reduce the complexity of reasoning about the entire system at once. Functional, information, behavior, and deployment views are representative examples.

Design for Non-Functional Requirements addresses architecturally significant non-functional requirements through appropriate architectural decisions and tactics. Requirements concerning performance, scalability, reliability, availability, security, maintainability, and similar quality attributes often have substantial architectural consequences.

The second sentence of the definition is equally important. It characterizes architecture as a comprehensive and sufficiently detailed design blueprint for implementation. Comprehensiveness, however, does not imply that architecture should descend to source-code or algorithmic detail. Rather, it means that architecturally significant design information should be sufficiently specified to support implementation, analysis, evaluation, and evolution.

4. Applicability to Large-Scale and AI-Based Systems

The need for a comprehensive interpretation of software architecture becomes particularly evident in large-scale and AI-based systems, where structural complexity is greater and stakeholder concerns, quality requirements, and dynamic behavior are more demanding. In such systems, software architecture must extend beyond high-level structure to encompass multiple architectural views and quality-driven design decisions.

For Large-Scale Systems

A large-scale software system may comprise numerous components, distributed computing resources, external systems, heterogeneous technologies, persistent data stores, communication networks, and multiple stakeholder groups. A high-level structural representation is useful for understanding the overall organization, but by itself it provides limited guidance for many critical design questions.

Architects must also determine how functionality is allocated among components, how information is organized and persisted, how components interact at runtime, where software elements are deployed, how external systems are integrated, and how the architecture satisfies significant quality requirements.

Quality requirements are particularly influential in large-scale systems. Scalability may require partitioning, replication, load balancing, or asynchronous processing. Availability may require redundancy, failure detection, failover, and recovery mechanisms. Security can influence trust boundaries, interfaces, communication paths, data management, and deployment. Such requirements are not peripheral to architecture; they can fundamentally reshape it.

For AI-Based Systems

AI-based systems are becoming increasingly diverse, complex, and dynamic, ranging from applications with embedded machine-learning models to generative AI, LLM-based, autonomous, and agentic AI systems. Their architectures commonly integrate conventional software components with datasets, data-processing pipelines, machine-learning models, inference services, external AI services, and specialized computing infrastructure. More advanced AI systems may introduce additional architectural concerns involving context and memory management, model and service integration, inference orchestration, agent coordination, runtime adaptation, and continuous monitoring.

AI-based systems must also satisfy demanding system-level quality requirements. High model accuracy alone does not ensure an acceptable software system. The overall system must address requirements for latency, throughput, scalability, availability, reliability, security, privacy, explainability, maintainability, adaptability, and operational resilience. These concerns become particularly significant in dynamically evolving systems such as agentic AI systems, whose runtime behavior, interactions, and decision processes may change in response to context, feedback, and environmental conditions. Consequently, a comprehensive architectural design is essential for systematically addressing both the structural complexity and quality requirements of modern AI-based systems.

Thus, for large-scale and AI-based systems, a purely structural interpretation of software architecture is insufficient. Architectural design must also encompass appropriate architecture views, quality-driven design decisions, and sufficient technical detail to guide implementation and evolution.

5. What Should a Comprehensive Architecture Description Contain?

Building on the three core aspects identified in Section 3, a comprehensive Architecture Description should also capture the context that shapes the architecture and the results of its evaluation. As shown in Figure 3, five elements of architectural information are particularly important.

System Context and Architecture Drivers should identify the stakeholder concerns, requirements, constraints, business objectives, and technological or operational conditions that materially influence the architecture.

Design of Schematic Architecture should document the fundamental structural organization of the system, including its principal architectural elements and their relationships.

Design for Architecture Views should provide complementary representations of architecturally significant concerns. As illustrated in Figure 3, representative views include functional, information, behavior, and deployment views.

Design for Non-Functional Requirements should document the architectural strategies, tactics, and design decisions used to address architecturally significant non-functional requirements.

Architecture Evaluation Results should document significant evaluation findings, including identified risks, weaknesses, trade-offs, and other relevant results.

Comprehensiveness does not mean documenting every implementation detail. The appropriate boundary is architectural significance: information should be included when it materially affects the architecture, significant requirements, implementation, evaluation, or evolution.

A comprehensive Architecture Description should therefore provide sufficient coverage of architecturally significant concerns and sufficient technical detail for its intended purposes, without extending unnecessarily into implementation-level design.

Article ID: ART-SA-01 · Published: September 2026 · Version: 1.0 · handsonse.org