Exploring the Definition of Software Architecture

Although software architecture has been widely applied in the field of software engineering, to date there is still no universally accepted

software architecture

definition. Numerous experts and scholars have characterized software architecture from different perspectives and angles. Some representative definitions include:

　　(1) Dewayne Perry and Alex Wolf defined it as follows: software architecture is a structured collection of elements in a certain form—specifically, components—including processing components, data components, and connecting components. Processing components handle data manipulation, data components represent the information being processed, and connecting components link and integrate different parts of the architecture. This definition emphasizes the distinction among processing, data, and connecting components—a distinction largely preserved in other definitions and methodologies.

　　(2) Mary Shaw and David Garlan consider software architecture as a level within the software design process that goes beyond algorithm and data structure design in computational processes. Architectural concerns include overall organization and global control, communication protocols, synchronization, data access, assignment of specific functions to design elements, organization of design elements, scale and performance, and selection among design alternatives. Software architecture addresses system-wide structural design and descriptive issues above the level of algorithms and data structures, such as global organization and control structures, protocols for communication, synchronization, and data access, definition of component functionality, physical distribution and integration, and selection, evaluation, and implementation of design solutions.

　　(3) Kruchten pointed out that software architecture comprises four perspectives, each describing the system from a different angle: the conceptual perspective describes major components and their relationships; the modular perspective includes functional decomposition and hierarchical structure; the runtime perspective describes the system's dynamic structure; and the code perspective describes the organization of code and library functions within the development environment.

　　(4) Hayes Roth views software architecture as an abstract system specification, primarily consisting of functional components described by their behavior, along with the interconnections, interfaces, and relationships among these components.

　　(5) David Garlan and Dewayne Perry, in a 1995 paper published in the IEEE Transactions on Software Engineering, proposed the following definition: software architecture is the structure of the components of a program or system, their interrelationships, the principles guiding their design, and the guidelines governing their evolution over time.

　　(6) Barry Boehm and his students proposed that a software architecture includes a set of software and system components, their interconnections, and constraints; a set of system requirements; and a rationale explaining how these components, interconnections, and constraints satisfy the system requirements.

　　(7) In 1997, Bass, Clements, and Kazman, in their book Using Software Architecture, gave the following definition: the software architecture of a program or computer system consists of one or more software components, the externally visible properties of these components, and their interrelationships. Here, "externally visible properties" refer to services provided by the component, performance characteristics, error handling, shared resource usage, and other observable behaviors.

The development of the Internet has profoundly impacted traditional application software development. Internet- and Web-based software and application systems undoubtedly require more open and flexible architectures. As an increasing number of business systems are deployed on the Internet, a new and more robust architectural style has been widely adopted—commonly known as "three-tier/multi-tier computing."

　　. Client tier: where the user interface resides and user requests originate; typical examples include web browsers and thick clients (e.g., Java applications)

　　. Server tier: typically includes web servers and application servers running business logic

　　. Data tier: typically includes relational databases and other backend data resources such as Oracle and SAP R/3

　　In the three-tier architecture, clients (requesters), processing logic (request handlers), and data (the target of operations) are physically isolated. This architecture is more flexible, separating presentation logic from business logic, meaning business code can be developed independently of how and where data is displayed. The business logic layer, now in the middle tier, does not need to be concerned with the type of client displaying the data and can remain relatively independent from backend systems, facilitating system scalability. The three-tier architecture also offers better portability, enabling operation across different platforms and allowing user requests to be load-balanced across multiple servers. Security is easier to implement as applications are isolated from clients. Application servers, a key component of three-tier/multi-tier architectures, reside in the middle tier.

Emergence

　　The software crisis of the 1960s prompted increased attention to software engineering research. Initially, software design focused on the selection of data structures and algorithms. However, as software systems grew larger and more complex, the overall system structure and specification became increasingly critical. As the software crisis intensified, existing software engineering methods proved inadequate. For large, complex software systems, the design and specification of the overall system architecture have become significantly more important than the selection of algorithms and data structures. In this context, the importance of software architecture was recognized, and systematic, in-depth research into software architecture was seen as a promising new path toward improving software productivity and addressing software maintenance challenges.

Software Architecture Lifecycle Model

From the moment software systems were first divided into modules with interactions and collective properties, they possessed an architecture. Skilled developers often use certain architectural patterns as strategies for structuring software systems, but they often fail to express these patterns formally or explicitly, making it difficult to share their knowledge. Software architecture represents a further evolution of design abstraction, meeting the need for better understanding of software systems and enabling more convenient development of larger, more complex systems.

　　In fact, all software has an architecture—there is no such thing as architecture-less software. The term "architecture" in English literally means "building" or "construction." Comparing software to a building, at a high level, it has a foundation, structure, and finishing—infrastructure software above the operating system, core application programs implementing computational logic, and user interface programs for ease of use. At a detailed level, every program has its own structure. Early structured programming grouped statements into modules, and the aggregation and nesting of modules formed hierarchical call structures—essentially, architectures. The consistency between the program (expressive) structure and the (computational) logical structure in structured programming, along with the top-down development approach, naturally led to architectural formation. During the era of structured programming, program size was relatively small. By emphasizing structured programming methodologies, using top-down design, stepwise refinement, and attention to module coupling, reasonably good structures could be achieved, so software architecture was not studied in depth.

　　We can make a simple analogy: the structured programming era was like building bungalows and small buildings using bricks, tiles, sand, stone, and prefabricated beams, columns, and roof panels, whereas the object-oriented era is like constructing skyscrapers using prefabricated walls, rooms, and entire floor sections. How should components be combined effectively? How can architectures be constructed efficiently? When key components change, how can the entire system remain stable? What components are needed for different application domains (e.g., hospitals, factories, hotels)? What practical, aesthetically pleasing, structurally sound, and cost-effective component frameworks (architectures) best meet user needs? Just as civil engineering evolved into modern architecture, software has advanced from traditional software engineering into modern, object-oriented software engineering—studying the architecture of entire software systems to find the fastest, lowest-cost, highest-quality construction processes.