What is Software Architecture in Software Engineering?

Understanding the essence of software architecture is crucial for comprehensive software engineering.


Software architecture refers to the high-level structures of a software system and the discipline of creating such structures. It involves the set of significant decisions about the organization of a software system including the selection of structural elements and their interfaces by which the system is composed and behavior as specified in collaborations among those elements. Software architecture positions at the core of software engineering and plays the ultimate role of providing fundamental organization of a software system. Software architecture is an important source for influencing the quality of software’s entity and it is a critical research topic in software engineering.

One of the key roles played by software architecture is handling inherent difficulties experienced when designing and developing complex software systems. Establishment of a suitable architecture is crucial in ensuring quality attributes in performance and modifications. Architecture also supports primary decisions that define collective software engineering activities. Software architecture gives an abstract view of a system, omitting details of implementation, algorithms, and data representation. Instead, it focuses on external properties of the system, the kinds of design patterns, and how they are interconnected.

Software engineering architecture is the high-level structure of a software system and the discipline of creating such structures. More formally, the architecture of a computer system can be defined as:

  • The structure or structures of the system, which comprise elements, the externally visible properties of those elements, and the relationships among them.
  • The manner in which the structures fulfill the requirements and behaviors of the system.

However, most software architects believe that this discipline is primarily concerned with abstraction, composition and decomposition. Software architecture is one of the emerging disciplines in the field of software engineering. Abstraction allows hiding unimportant details. Decomposition provides separation of concerns while composition helps coordinate between elements. Such embedment of software design and definition of processes enhances early design and development and eases evolution of complex systems over time. Software architecture is thus pivotal in software development and plays a crucial role in software engineering.


Read more about software architecture in the Software Engineer Book of Knowledge (SWEBOK)


Back to Top


Software Architecture Fundamentals

In software engineering, architecture refers to the fundamental structures of a software system and the discipline of creating such structures. A system’s software architecture depicts its components and how they interact. The systems architecture operates as the blueprint for the entire system. Although software architecture is an emerging discipline within software engineering, it is widely recognized as a key stage in software development.

Architecture refers to the overall structure and organization of a software system. Software architecture entails the integration of various components, interrelationships between those components, and the properties of both components and relationships. Software architecture provides an abstract view of the system design. It focuses on external aspects of all components and interactions while omitting internal implementation details such as algorithms and code.

The purpose of effective software architecture is to design a system that is free from common engineering challenges by meeting performance, reliability, maintainability and scalability. Architecture deals with tradeoffs between competing quality attributes and makes early design pattern decisions that impact the system quality. A well-designed architecture can produce a system that meets business needs and is robust, performant, usable, reusable and maintainable. It also facilitates communication between stakeholders and guides the system implementation.

In general, reverse engineering software architecture is not advisable. Reverse engineering means reconstructing the architecture from existing code. However, code often diverges from architecture during development. So the reconstructed architecture may not reflect the original intent. Also, undocumented code lacks abstraction and does not provide any rationale behind design decisions. Thus, it is better to document the architecture separately from, and prior to, implementation to avoid divergence. However, reverse engineering can provide insights when original architecture documentation is lost.

Software architecture is a key aspect of applied science of software engineering. It refers to the high-level structure and organization of a software system. The purpose of architecture is to design a system that meets quality attribute requirements. And architecture should be proactively designed and documented, not reverse engineered from code.

Back to Top


Architecture Description

Companies need to have a clear representation and description of their architecture especially when they have large and complex software systems. A well-documented architecture provides a common understanding of the system design within the built environment. It serves as a communication medium between stakeholders like managers, developers, users etc. A clearly planned and documented architecture guides the entire process of system implementation and future development. Architecture documentation captures initial design decisions, components, interfaces, and patterns that widely impact the system.

An architecture view is a representation of the whole system or some part of it from a particular perspective. Since software architecture represents a complex system, no single view is sufficient. Various architectural views represent unique concerns and identify relevant structures, components, and connections. Common architecture views include logical view, development view, process view and physical view. Various views are crucial in providing comprehensive architectural descriptions.

There are different styles and patterns used to organize software architecture. Styles provide reusable architectures like layered pattern, pipe-and-filter style etc. that embody structural and behavioral constraints. Patterns are reusable solutions to commonly occurring problems within a given context. Examples include the MVC (model-view-controller) pattern and the client-server pattern. Software architectural style and architecture patterns present effective architecture designs that solve common issues of performance and reliability within the built environment for a given type of application.

An architecture framework also captures conventions and common practices for describing architectures within a domain or stakeholder community. It provides standard taxonomies, view templates and a consistent methodology for architecture description. Using a common framework improves communication and comparison between architectures. Examples include DoDAF (Department of Defense Architecture Framework), and TOGAF (The Open Group Architecture Framework). Frameworks help ensure architecture descriptions are complete, relevant and understandable.

Architecture representation, views, styles, patterns and frameworks are important for comprehensively describing software architectures within the built environment, especially for large, enterprise systems with massive development teams. Architecture description facilitates communication, implementation guidance and future development. Documenting architectural rationale is also important to capture why certain decisions were made, to guide future maintenance and evolution.

Back to Top


Read more about software architecture in the Software Engineer Book of Knowledge (SWEBOK)



Architecture Processes

Software architecture manifests itself in systems at different levels. At enterprise level, it provides a high-level structure unifying business processes and software systems enabling information sharing. At the software system level, it describes components and connections between process elements within the system. At component level, it deals with internal architecture of individual components. Some examples of software architecture in real-world contexts are:

  • The architecture of enterprise resource planning systems like SAP, Oracle etc.
  • The architecture of web-based systems like Amazon, eBay, Google etc.
  • The architecture of real-time embedded systems like airplane control systems.

Architectural design involves balancing a multitude of complex and often competing concerns. The software architect must juggle many factors to produce an optimal system architecture aligned with the business process architecture.

Key considerations include functional requirements, quality attributes, business drivers, technologies, system constraints and tradeoffs. Functional requirements define capabilities the system should provide. Quality attributes like performance, availability and security specify how well the system should deliver those capabilities. Business goals impact priorities and timelines for development. The existing technology landscape and infrastructure constraints are viable architectural options.

Additional restrictions arise from legacy system interoperability needs, regulatory compliance demands, and hardware limitations. With so many diverse factors in play, compromises are inevitable. Not all desired system qualities can be maximized simultaneously. The software engineer must carefully analyze tradeoffs between competing needs like performance versus security. The developer must also manage technical debt accrued through expedient shortcuts.

There is no perfect or one-size-fits-all architecture. But through understanding and balancing this array of concerns, a thoughtful architectural design process can yield an architecture tailored to meet the system’s intended purpose. Considering the uniquely defined constraints, the architecture should represent suitable solutions.

Enterprise architecture refers to the architecture of an entire organization’s portfolio of IT systems, processes, information flows and personnel to align IT strategy with business objectives. It provides an overarching structure and view for guiding systems integration, standardization, development and evolution within the enterprise.

Architecture synthesis is the process of creating an architecture description that satisfies the concerns and requirements. It evaluates different architecture options and makes optimal choices. The resulting architecture drives analysis, requirements specification, design and implementation. Architecture synthesis helps define the architecture at an early stage when changes to process elements have lower impacts.

Capturing architectural design rationale is an important part of the architecture process. Design rationale documents why certain decisions were made, the alternatives considered, and the tradeoffs involved. This helps guide future maintenance and evolution when new architects unfamiliar with the original design are involved.

Architecture deals with systems at multiple levels. Key architectural concerns include functional and quality requirements, business priorities, technologies and constraints. Enterprise architecture guides IT across the organization. Architecture synthesis creates optimal architecture aligned with business process architecture to address these concerns. Documenting design rationale is crucial for long-term maintenance.

Back to Top


Architecture Evaluation

Architectural evaluation occurs throughout the software development lifecycle. During initial architecture synthesis, alternative architectures are analyzed to select optimal solutions. After an architecture baseline is established, it is evaluated to ensure it satisfies requirements. In design and implementation, architecture conformity is evaluated to prevent divergence. Testing verifies architecture qualities like performance meet requirements. Maintenance requires evaluating architecture changes.

Effective architecture evaluation relies on having clear, measurable quality goals and requirements to judge against. Architectural quality attributes like performance, reliability, and maintainability should be made quantifiable through metrics and acceptance criteria wherever possible. This provides objective evaluation criteria rather than subjective judgments.

When designing the architecture, quality requirements analysis is crucial to understand stakeholders’ key evaluation benchmarks. These measurable quality goals drive the architecture design process and serve as the basis for subsequent evaluation through the lifecycle via inspections, testing, and metrics tracking. With testable quality requirements as evaluation criteria, architecture defects can be definitively identified and remedied through iterative refinement. This helps ensure the software architecture achieves its intended business purpose and quality goals.

Some key questions to ask when evaluating software architecture are: Does it meet functional and quality requirements? Does it conform to business goals, constraints and technology decisions? Does it use appropriate styles, patterns and industry best practices? Does it balance competing concerns like performance vs. security? Does it provide required flexibility for future changes? Does it produce components with well-defined interfaces and interactions? Is it comprehensible to stakeholders and implementation teams?

There are several techniques to use when evaluating an architecture. Requirements, use cases and risks should be examined to identify key quality attributes like performance, user interface, and system availability. Leverage checklists, questionnaires and metrics based on best practices and software architecture patterns. Use methods like simulation, artificial intelligence, mathematical modeling and prototyping to analyze architecture qualities. Perform expert reviews, inspections and system walk-throughs to identify issues. Finally, be sure to assess architecture documentation quality since it directly impacts development and affects the long term success of the project.

Architectural metrics quantify structural aspects like component size, coupling, cohesion and other factors, as well as quality attributes like performance, reliability and maintainability. Metrics enable objective evaluation and tracking of architecture quality over time. Widely used metrics include component re-use percentage, defect density, cyclomatic complexity and response time. Assessment of architecture effectiveness is also enhanced through benchmarking against comparable systems.

Evaluation of architecture throughout the lifecycle of software development presents an opportunity to assess overall quality while also providing opportunities for improvement. Continually focusing on key software requirements, business needs, and conforming to constraints can significantly improve a project, especially over the longer term.


Read more about software architecture in the Software Engineer Book of Knowledge (SWEBOK)


Back to Top

Inside the Computer Society