There is no universally agreed-upon definition of "software architecture" in the IT industry. The subject was primarily researched and introduced at institutes like SEI CMU, with contributions from various authors who helped define the discipline. Later, organizations such as IEEE attempted to formalize the subject by proposing definitions. However, this has led to the challenge of having multiple definitions and no single standard.
Meanwhile, industry practitioners have coined their own terms due to the absence of a single governing body. As a result, in practice, software architecture evolves based on the needs of various organizations.
Simple Definition of Software Architecture
In simple terms, software architecture is the organization of a system, its components, their relationships with each other, and their interaction with the environment.
This organization is driven by principles that guide the design of the system and help it evolve over time.
A system may refer to a set of applications, a subsystem, systems of subsystems, or even the entire organization. The environment influences the system, and the system, in turn, helps fulfill one or more objectives of its stakeholders. A stakeholder may be an individual, a group, or an organization with an interest in the system.
Components in Software Architecture
The formal definition of a component in software architecture is not strictly defined. It can be:
- Logical or physical
- Coarse-grained or fine-grained
- Technology-specific or technology-neutral
UML (Unified Modeling Language) provides a definition of a component within its scope. However, in practice, a component is best understood as a basic building block of a system, fulfilling a set of features or covering specific aspects of the system.
These aspects may relate to functional or non-functional requirements.
A common misconception is considering low-level, technology-specific artifacts as architectural components. This approach blurs the line between architecture and design. Architecture deals with high-level structures, while design focuses on detailed implementation.
Prescriptive, Descriptive, and Implemented Architecture
The term "architecture" is used in three contexts:
1. Prescriptive Architecture
- Describes the target architecture of a system before development.
- It acts as a blueprint for how the system should be structured.
- Often documented in a Software Architecture Document (SAD).
- Important decisions regarding system design are captured here.
- Some authors refer to this as "prescriptive architecture" because it prescribes the intended architecture.
2. Descriptive Architecture
- Represents the current architecture of an existing system.
- If a prescriptive architecture document stays in sync with the system’s evolution, it effectively becomes a descriptive architecture document.
- This is also known as "as-is architecture."
3. Implemented Architecture
- Represents the actual running system with its behaviors and attributes.
- It exists independently of documentation—even if no document is available, architecture still exists in the system, just as buildings have an architecture regardless of blueprints.
Enterprise Architecture and Other Related Terms
There are several terms that include "architecture" in their name:
- Enterprise Architecture, Segment Architecture, Solution Architecture
- Enterprise Architecture, Solution Architecture, Technology Architecture
- Enterprise Architecture, Business Architecture, Application Architecture, Data Architecture, Technology Architecture
- Information Architecture and Information System Architecture
These terms are commonly used in the context of Enterprise Architecture (EA), which has a broader scope than software architecture. Enterprise Architecture covers an entire organization, including its vision, business, people, processes, and IT.
The first well-known standard in software architecture was IEEE 1471, approved in 2000. The latest version is known as ISO/IEC/IEEE 42010:2011.
Software Architecture Key Drivers
Architecture drivers are key factors that influence the architecture of a system. These include:
- Functional Requirements – What the system is supposed to do.
- Constraints – Business and technical limitations.
- Quality Attributes – Performance, scalability, security, maintainability, etc.
Constraints (Predefined Design Decisions)
Constraints are design decisions already made for the architects:
Business Constraints:
- Target market
- Time to market
- Budget and cost
- Schedule constraints
- Human resource limitations
Technical Constraints:
- Integration with existing systems
- Compatibility with older software versions
- Operating system restrictions
- Hardware and network limitations
- Compliance with protocols, standards, and regulations
Constraints cannot be changed and must be considered during architectural decision-making.
A Note on Architecturally Significant Requirements (ASRs)
Architecturally Significant Requirements (ASRs) impact key architectural decisions. ASRs may come from:
- Requirement documents
- Stakeholder interviews/workshops
- Business objectives
Architects must identify ASRs early, as they shape the foundation of the system.
Interesting resources
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=513862
(Views and beyond SEI CMU Template for SAD)
http://www.iso-architecture.org/42010/
https://resources.sei.cmu.edu/asset_files/TechnicalNote/2005_004_001_14498.pdf
(Comparison of Views & beyond template and ANSI-IEEE 1471-2000)
https://resources.sei.cmu.edu/asset_files/TechnicalNote/2003_004_001_14171.pdf
(Documenting Software Architecture in an Agile world)
http://www.informit.com/articles/article.aspx?p=2738304&seqNum=4
http://www.neverletdown.net/2014/10/architectural-drivers.html
https://www.slideshare.net/NghiaLe36/architectural-driver
https://www.linkedin.com/pulse/software-architecture-drivers-konstantinos-bakopanos/
Software Architect Handbook (https://books.google.co.in/books?id=6EZsDwAAQBAJ)
http://www.cs.uu.nl/docs/vakken/ie/ppts/ICTE06-Architecture.pdf
Comments
Post a Comment