Software Architecture Fundamentals
Architecture principles, roles, requirements & risk management.
Introduction to Software Architecture
The word "architecture" derives from the Greek arkhi- (chief) + tekton (builder), meaning master builder. Vitruvius codified architecture principles in De Architectura (1st century AD), establishing an analogy to software: planning, designing, and constructing systems that provide rules and structure.
Before the 1960s
- Hardware was complex and expensive
- Software complexity was low
- No structured approach needed
Software Crisis (1960s)
- Computing power outpaced engineers' ability to build "good" IT systems
- Projects delivered late, over budget
- High project failure rate
- Solution → Software Architecture
Common objections — "Too expensive," "Slows us down," "Just get it done" — reveal a misunderstanding of architecture's long-term value. The real cost lies in not having it.
Good architecture takes ALL factors into account — making the role of a software architect both important and challenging.
Architecture exists to avoid expensive and disruptive changes in the future. Good software architecture considers many factors beyond mere functionality, addressing the long-term goals of a system.
- Motivation for software architecture → analogy to physical architecture
- We need architecture to avoid:
- Expensive
- Disruptive changes in the future
- Origins of software architecture → solution to managing growing complexity
- Intuition for good software architecture:
- We need to consider many factors
- Not just functionality
Key Concepts for Software Architecture
The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.
Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
Software is broader than a single program — it encompasses programs, procedures, documentation, and data. The diagram below shows what software comprises:
A component (ISO/IEC 25010:2011) is an "entity with discrete structure, considered at a particular level of analysis." Components are units of hierarchical decomposition and encapsulation that provide static structure.
Small
Function, class, data structure, module
Medium
Package, library, framework, program, script, container, pod
Large
Application cluster, container cluster
Any component can be described as either a Black Box or a White Box. The decision depends on the required level of abstraction and the quality attributes that need to be understood.
- Hides internal structure
- Only exposes interface / behavior
- Focuses on what a component does
- Better for encapsulation
- Shows internal structure
- Reveals implementation details
- Shows sub-components & connections
- Needed for deep analysis or debugging
An interface (ISO/IEC 2382:2015) is a "shared boundary between two functional units." It acts as a contract that components must abide by — a well-defined access point providing syntax, data structures, functional behavior, error handling, and protocol details.
Provided Interface (API)
"Please do stuff for me — I will do it THIS way."
Required Interface (SPI)
"Please do stuff for me AND do it THIS way." Plugin interfaces.
Standard Interface
"You shall do stuff THIS way." — Provided by a 3rd party.
A stakeholder (ISO/IEC/IEEE 24765:2017) is any individual or organization having a right, share, claim, or interest in a system — or that may affect or be affected by a project's decisions or outcomes.
Requirements fall into three distinct categories, each playing a different role in shaping the software architecture:
Functional Requirements
What shall X do? — "required feature." When A happens, the system shall do B.
Quality Requirements
How shall X be? — "required quality." The system shall be secure, maintainable, efficient…
Constraints
Externally imposed limitations on design, implementation, or the development process (technical, budget, legal).
Changes in quality requirements can have a significant impact on the software architecture — potentially requiring a complete redesign. Two key examples:
Small Scale vs Large Scale Application
A small-scale app (e.g. single-user desktop) can use a simple layered architecture. Scaling to millions of users requires distributed systems, caching layers, load balancers, and horizontal scalability — a fundamentally different architecture.
Non-Secure vs Secure System
Adding security requirements to an existing non-secure system is disruptive. It requires adding authentication, authorization, encryption, audit trails, and security boundaries — changes that touch nearly every component.
Functional requirement changes do happen and can be managed. Quality requirement changes might happen and can imply significant risks to the architecture.
- ○ Technical constraints
- ○ Budget constraints
- ○ Legal constraints
Why Requirements Change
- Customers are not sure what they want
- Legal uncertainties (legislation in progress)
- Market or business context shifts
Danger of Unstable Requirements
- May require major rework
- Cause "scope creep"
- → Missed delivery of the project
What the Architect Must Do
- Cannot eliminate unstable requirements
- Needs to identify them early
- Design for flexibility where instability is expected
- There are many valid definitions of Software Architecture.
- Common concepts:
- Building blocks / Components
- Relationship between components and each other
- Relationship between components and their environment
- Principles, rules and guidelines
- Building blocks / components can be of any size
- Can be described as:
- Black Boxes — Hide internal structure / implementation details
- White Boxes — Show internal structure / implementation details
- Interface in Software Architecture — Contract components must abide by.
- Types of interfaces:
- Provided Interface (API)
- Required Interface (SPI)
- Standard Interface (Provided by 3rd party)
- Learned the definitions of a "Stakeholder" — Groups/Individuals that:
- Are affected by our system
- Affect/influence our system
- Types of requirements:
- Functional Requirements
- Quality Requirements
- Constraints
Roles and Responsibilities of a Software Architect
Establish a Business Case
- Consider costs and desired benefits
- Understand business value from customer perspective
- Create economically viable solutions
- Shape and constrain future requirements
Clarify Requirements
- Identify, refine, and scrutinize functional & quality requirements
- Analyze feasibility and contradictions
- Identify missing/implicit requirements → make them explicit
- Estimate stability of requirements
The Software Architect is NOT a Requirements Engineer. It is not their responsibility to define or gather requirements — their role is to guarantee the fulfillment of requirements.
Contradiction Example
Req. A: "Absolute data privacy — no entity may access user data under any circumstances."
Req. B: "Law enforcement must be allowed to access user data without consent in criminal investigations."
Implicit Requirements Example
Explicit: "Allow users to stream videos on mobile devices."
Implicit: "The system should use adaptive streaming so quality adjusts to connection speed."
- → Customers are not sure what they want
- → Legal uncertainties (legislation in progress)
- ⚠ May require major rework
- ⚠ Cause "scope creep" → missed delivery of the project
- ● Cannot eliminate those unstable requirements
- ● Needs to identify them early
Design / Select Architecture
- Select existing solutions or design new ones
- Consider costs, integration difficulty, alignment
- Decompose into building blocks (domain, technology layers)
- Define interfaces and dependencies
- Decide cross-cutting concerns (persistence, GUI, communication)
- Test concepts with prototypes
Document & Communicate
- Create shared understanding via diagrams, views, illustrations
- Depict functionality and technical elements
- Make architecture visible and understandable to all stakeholders
Guide & Support Implementation
- Ensure implementation compliance via code reviews and tests
- Integrate stakeholder feedback
- Analyze architecturally-relevant issues
- Support testers with test conditions and constraints
Evaluate the Architecture
- Quantitative assessment: metrics
- Qualitative assessment: adherence to requirements, constraints, goals
- Identify risks regarding quality requirements
- Justify consequences and derive mitigation strategies
- → Security and Privacy
- → Deployment on public cloud
- → Compliance and encryption
A good architect combines technical depth with broad soft skills — they must negotiate, listen, organize, and guide while maintaining strong technical expertise.
Cognitive Skills
- Capacity for abstract & system thinking
- Knowledge in breadth (not always depth)
- Fast learner
- Innovative / creative
- Open and adaptable to changes
Interpersonal Skills
- Assertiveness and decision-making
- Interpersonal communication & negotiation
- Ability to work in teams and independently
- Guide, negotiate, listen, organize
vs Analyst / Requirements Engineer / Product Owner
Architect accepts requirements, examines feasibility, detects inconsistencies, and asks for changes to improve architecture.
vs Customer
Acts as the customer's "lawyer" — ensures requirements are sensible, feasible, and fulfilled from an architectural perspective.
vs Project Manager
Acts as "advisor" — supports project planning, work packages, risk analysis and prevention.
vs Developer
Provides architecture guidelines, know-how transfer, and code reviews. Receives status and change requests.
vs Tester
Provides guidelines, test constraints, test cases, sequencing, and prioritization of tests.
vs IT Operations
Considers operational framework — network topology, hardware/software, OS. Defines deployment structure.
- Better understanding of additional concerns
- Improved context and situational awareness
- Conflicts of interests
- Less time for documentation
- Less time for code review
- Less time working with developers
- The expected output of a Software Architect is the System's Architecture that:
- Fulfills the: Functional requirements, Quality requirements
- Aligns with: The project goals, Business objectives
- Software Architect's main responsibility is the fulfilment of the long-term strategic, software architecture goals
- Tasks of a Software Architect:
- Helping establish a business case
- Identifying, clarifying and analyzing requirements
- Designing/selecting the architecture and technologies
- Documenting and Communicating the Software Architecture
- Guiding and Supporting Implementation
- Evaluating the Software Architecture
- Software Architect's activities are not linear
- In some organizations, the Software Architect takes on other responsibilities
- Benefits: Better understanding and context
- Drawbacks: Conflict of interests, Time conflict
- Relationship between a Software Architect and:
- Analyst / Requirements Engineer / Product Owner
- Customer
- Project Manager
- Developer
- Tester
- IT Operations
Influencing Factors, Quality Goals & Design Constraints
"The part of reality that is relevant for the requirements of a system." — Pohl+2016
People
Stakeholders or groups of stakeholders
Systems in Operation
Other technical systems or hardware
Documents
Laws, standards, system documentation
Events
Technical or physical events
Processes
Technical and business processes
- Org structure & team
- Decision makers
- Partnerships
- Resources (Budget, Time, Staff)
- Standards & process models
- Legal: GDPR, CCPA, HIPAA, COPPA
- Functional requirements
- Quality requirements
- Product cost & licensing
- Business model
- Open-source vs closed-source
- Commercial vs internal usage
- Software infrastructure
- Hardware infrastructure
- Programming language
- Communication protocols
- Libraries, frameworks
- Operating environment
- → Technical constraints
- → Legal constraints
- ⚠ Conflicting priorities → Time constraints
- ⚠ Hourly pay → Budget constraints
- → Technical / Data Constraints
- → More requirements on:
- ● Availability
- ● Security
- ● Performance
- ○ Describe desired functionalities, data, or behavior of the system or product
- (what the system should / can do).
- ○ Describe desired quality attributes of the system or product.
- (how the system should be)
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
— Conway, Melvin E. (1968)
- 4 teams → likely 4 large building blocks
- Often no technical necessity for this
- Communication quality influences interface quality
- Inverse Conway Maneuver: Design org structure to match desired architecture
Quality Attributes
- Properties of the system
- Performance, Availability, Security, Usability
- Can be positively or negatively correlated with each other
Quality Goals
- High-level objectives
- May utilize multiple quality attributes
Example:
"Improve user experience and satisfaction"
Quality attributes: Performance, Usability
Quality Requirements
- Specific, actionable, measurable statements
- Derived from quality goals
Examples:
- "A user should see the product homepage in the browser within 500ms at most"
- "The product search feature shall return relevant results within 2 seconds with at least 90% accuracy"
Quality goals and requirements can:
- Align with, or contradict, each other
- Support or compete with other influencing factors (e.g., project or business goals)
- Not all quality requirements are easily quantifiable
- Examples:
- Sustainability
- Maintainability
- Understandability
- Important: Clear criteria of when:
- The requirement is met
- The work is done
- Open-source vs closed-source
- One-time purchase vs subscription-based vs consumption-based
Additional services / packages can be purchased.
Impact on requirements / design:
- Reserve performance tricks/tools for paid version
- Additional capabilities need to be easy to plug-in
One-time purchase price
Impact on requirements / design:
- No cloud provider / third-party services
- Increase capacity of a single resource
- Replace with a more powerful resource
- Example: Increase DB server memory
- Example: Upgrade to a faster computer
- Add more resources to the system
- Distribute the workload
- Example: Add servers to a stateless web app
- Example: Add database replicas
- Origin of requirements and System Context: "The part of reality that is relevant to the requirements of a system."
- People/Stakeholders
- Systems in Operation
- Events
- Processes
- Documents (standards / agreements..)
- Categories of influencing factors on our Software Architecture:
- Organizational
- Product-Related
- Technological — Limit the technologies, frameworks, programming languages etc. Set constraints on our design. Can be both good and bad.
- Product-related Influencing factors:
- Functional requirements
- Quality requirements
→ Main factor that drives software architecture
→ Commonly neglected by inexperienced engineers/architects
- Quality attributes — properties (e.g., performance, reliability, scalability). Can support/contradict each other.
- Quality goals — high-level objectives related to software quality that an organization wants to achieve.
- Quality requirements — Specific, actionable, and detailed statements derived from a quality goal, targeted toward a specific quality attribute.
- Other product-related influencing factors:
- Product cost
- Product service
- Licensing
- Business model
- etc.
Identifying Uncertainty and Risks
A risk is a threat to the successful fulfillment of project or architectural goals.
Even with extremely low probability, a very high amount of harm can still produce significant risk.
Recognize
Identify risks early across all project dimensions — technical, organizational, and human.
Communicate
Justify consequences of architectural decisions to stakeholders clearly and proactively.
Assess & Limit
Derive solutions and strategies to mitigate risks. Quantify via probability × harm.
Organizational Context Risks
- Long physical distance to stakeholders
- Complex market conditions
- Fixed budget / fixed project duration
- Greenfield project uncertainty
Product Risks
- Mission-critical system
- Demanding quality requirements
- Unknown quality requirements
- High complexity / large system
Human Factor Risks
- Poor communication skills
- Problematic group dynamics
- Low commitment
- "Subconscious" knowledge (not shared)
The Danger
Implicit assumptions are very risky — phrases like "it should have been clear to everyone" or "we always assumed that…" signal undocumented expectations.
The Solution
Anticipate and address implicit assumptions. Don't just say what a component is responsible for — explicitly state what it is NOT responsible for.
Be Explicit! Not implicit. A component's scope should be unambiguous to all team members, documented in both positive and negative terms.
Security & Privacy Risk
Decision: Deployment on public cloud
Justification: Implement compliance measures and encryption to address data privacy and access control risks.
Outage / Data Unavailability
Mitigation strategies:
- Ongoing backups
- Multiple data centers
- Multiple cloud providers
Example 1: Microservice A
✔ In Scope:
"Microservice A is responsible for managing Users."
✘ Out of Scope:
"Microservice A is not responsible for storing user profile pictures."
Example 2: Image Processing Library
✔ In Scope:
"The Image processing library is responsible for detecting objects in the image and improving its quality."
✘ Out of Scope:
"The image processing library is not responsible for compressing and storing the processed data in a file."
- Nobody works more productive or faster under high pressure
→ Increasing error rate, quick-and-dirty solutions - Hiring more people for a delayed project, delays it further.
- Murphy's Law: Additional problems always arise.
- Be a pessimist: Prefer to plan too many rather than too few resources.
- Calculate safety margins.
- Expect unknown unknowns.
- If the political issues are not managed, the system development will never be successful.
Investing in good architecture has a short-term productivity cost but yields long-term gains. Quick-and-dirty approaches create net negative productivity over time — rework, bugs, and tech debt slow the team down progressively.
- What is "Risk":
- Threat to the successful fulfilment of project goals / architectural goals
- [Probability of an adverse event] × [amount of harm]
- Risk categories:
- Organizational Context risks
- Product risks
- Human factor risks
- Mitigating the implicit influencing factor — implicit assumptions
- Making assumptions explicit
- Tips for managing risks
What Is Software Architecture?
- Fundamental structural decisions — hard & expensive to change later
- Components, relationships & guiding principles
- Bridges requirements to implementation
Building Blocks & Relationships
- Components (building blocks) with defined interfaces
- Dependencies, data flow & communication relationships
- Architecture views: context, building block, runtime, deployment
The Software Architect
- Clarify requirements, make & document design decisions
- Communicate architecture to all stakeholders
- Evaluate, validate & continuously improve architecture
Constraints & Quality Goals
- Functional requirements, quality goals & constraints shape decisions
- Conway's Law — team structure mirrors system structure
- Quality attributes have correlations & trade-offs
Uncertainty & Risk Management
- Identify organizational, product & human-factor risks early
- Make implicit assumptions explicit
- Balance technical debt against delivery speed