Skip to main content

What is software architecture?

 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:

  1. Functional Requirements – What the system is supposed to do.
  2. Constraints – Business and technical limitations.
  3. 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

Popular posts from this blog

Virtual environments in python

 Creating virtual environments is essential for isolating dependencies and ensuring consistency across different projects. Here are the main methods and tools available, along with their pros, cons, and recommendations : 1. venv (Built-in Python Virtual Environment) Overview: venv is a lightweight virtual environment module included in Python (since Python 3.3). It allows you to create isolated environments without additional dependencies. How to Use: python -m venv myenv source myenv/bin/activate # On macOS/Linux myenv\Scripts\activate # On Windows Pros: ✅ Built-in – No need to install anything extra. ✅ Lightweight – Minimal overhead compared to other tools. ✅ Works across all platforms . ✅ Good for simple projects . Cons: ❌ No dependency management – You still need pip and requirements.txt . ❌ Not as feature-rich as other tools . ❌ No package isolation per project directory (requires manual activation). Recommendation: Use venv if you need a simple, lightweight solut...

Building a Simple Text Generator: A Hands-on Introduction

Introduction Text generation is one of the most exciting applications of Natural Language Processing (NLP) . From autocorrect and chatbots to AI-generated stories and news articles , text generation models help machines produce human-like text. In this blog post, we’ll introduce a simple yet effective text generation method using Markov Chains . Unlike deep learning models like GPT, this approach doesn’t require complex neural networks—it relies on probability-based word transitions to create text. We’ll walk through: ✅ The concept of Markov Chains and how they apply to text generation. ✅ A step-by-step implementation , fetching Wikipedia text and training a basic text generator. ✅ Example outputs and future improvements. The Concept of Markov Chains in Text Generation A Markov Chain is a probabilistic model that predicts future states (or words) based only on the current state (or word), rather than the full sentence history. How it works in text generation: 1️⃣ We analyze a gi...

Mastering Trade-Off Analysis in System Architecture: A Strategic Guide for Architects

 In system architecture and design, balancing conflicting system qualities is both an art and a science. Trade-off analysis is a strategic evaluation process that enables architects to make informed decisions that align with business goals and technical constraints. By prioritizing essential system attributes while acknowledging inevitable compromises, architects can craft resilient and efficient solutions. This enhanced guide provides actionable insights and recommendations for architects aiming to master trade-off analysis for impactful architectural decisions. 1. Understanding Trade-Off Analysis Trade-off analysis involves identifying and evaluating the conflicting requirements and design decisions within a system. Architects must balance critical aspects like performance, scalability, cost, security, and maintainability. Since no system can be optimized for every quality simultaneously, prioritization based on project goals is essential. Actionable Insights: Define key quality ...