iSAQB Foundation in Software Architecture Training (CPSA Foundation Level)

Who should attend

The key audience is software architects of all technical levels - when taken as a private course for your whole team, it will help bring a common understanding of good practices and aid collaboration, efficiency and transparency. 

Pre-requisites

Delegates will ideally have at least 6 months' experience of working within a software development environment - we are happy to adapt the delivery for people who are newer to the industry, for instance for graduate intake training schemes.

Live, instructor-led online and on-site training

We appreciate that you need flexibility to fit in with new working situations - whether you're an individual, part of a distributed team, or simply have projects and deadlines to meet.

Our remote training can take place online in a virtual classroom, with content split into modules to accommodate your scheduling challenges and meet your learning goals. Get in touch today to find out how we can help design a cost-effective, flexible training solution.

LG 1-1: Discuss Definitions of Software Architecture (R1)

Software architects know several definitions of software architecture (incl. ISO 42010/IEEE 1471, SEI, Booch etc.) and can name their similarities:

• components/building blocks with interfaces and relationships

• building blocks as a general term, components as a special form thereof

• structures, cross-cutting concepts, principles

• architecture decisions and their consequences on the entire systems and its lifecycle

LG 1-2: Understand and Explain the Goals and Benefits of Software Architecture (R1)

Software architects can justify the following essential goals and benefits of software architecture:

• support the design, implementation, maintenance, and operation of systems

• achieve functional requirements or ensure that they can be met

• achieve requirements such as reliability, maintainability, changeability, security, energy efficiency etc.

• ensure that the system’s structures and concepts are understood by all relevant stakeholders

• systematically reduce complexity

• specify architecturally relevant guidelines for implementation and operation

LG 1-3: Understand Software Architecture as Part of the Software Lifecycle (R2)

Software architects understand their tasks and can integrate their results into the overall lifecycle of IT systems. They can:

• identify the consequences of changes in requirements, technologies, or the system environment in relation to software architecture

• elaborate on relationships between IT-systems and the supported business and operational processes

LG 1-4: Understand Software Architects' Tasks and Responsibilities (R1)

Software architects are responsible for meeting requirements and creating the architecture design of a solution. Depending on the actual approach or process model used, they must align this responsibility with the overall responsibilities of project management and/or other roles.

Tasks and responsibilities of software architects:

• clarify and scrutinize requirements and constraints, and refine them if necessary, including required features and required constraints

• decide how to decompose the system into building blocks, while determining dependencies and interfaces between the building blocks

• determine and decide on cross-cutting concepts (for instance persistence, communication, GUI etc.)

• communicate and document software architecture based on views, architectural patterns, cross-cutting and technical concepts

• accompany the realization and implementation of the architecture; integrate feedback from relevant stakeholders into the architecture if necessary; review and ensure the consistency of source code and software architecture

• analyse and evaluate software architecture, especially with respect to risks that involve meeting the requirements

• identify, highlight, and justify the consequences of architectural decisions to other stakeholders

They should independently recognize the necessity of iterations in all tasks and point out possibilities for appropriate and relevant feedback.

LG 1-5: Relate the Role of Software Architects to Other Stakeholders (R1)

Software architects are able to explain their role. They should adapt their contribution to a software development in a specific context and in relation to other stakeholders and organizational units, in particular to:

• product management and product owners

• project managers

• requirement engineers (requirements- or business analysts, requirements managers, system analysts, business owners, subject-matter experts, etc.)

• developers

• quality assurance and testers

• IT operators and administrators (applies primarily to production environment or data centers for information systems),

• hardware developers

• enterprise architects and architecture board members

LG 1-6: Can Explain the Correlation between Development Approaches and Software Architecture (R2)

• software architects are able to explain the influence of iterative approaches on architectural decisions (with regard to risks and predictability).

• due to inherent uncertainty, software architects often have to work and make decisions iteratively. To do so, they have to systematically obtain feedback from other stakeholders.

LG 1-7: Differentiate between Short- and Long-Term Goals (R2)

Software architects can explain potential conflicts between short-term and long-term goals, in order to find a suitable solution for all stakeholders

LG 1-8: Distinguish Explicit Statements and Implicit Assumptions (R1)

Software architects:

• should explicitly present assumptions or prerequisites, therefore avoiding implicit assumptions

• know that implicit assumptions can lead to potential misunderstandings between stakeholders

• can formulate implicitly, if it is appropriate in the given context

LG 1-9: Responsibilities of Software Architects within the Greater Architectural Context (R3)

The focus of the iSAQB CPSA Foundation Level is on structures and concepts of individual software systems.

In addition, software architects are familiar with other architectural domains, for example:

• enterprise IT architecture: Structure of application landscapes

• business and process architecture: Structure of, among other things, business processes

• information architecture: cross-system structure and use of information and data

• infrastructure or technology architecture: Structure of the technical infrastructure, hardware, networks, etc.

• hardware or processor architecture (for hardware-related systems)

These architectural domains are not the content focus of CPSA-F.

LG 1-10: Differentiate Types of IT Systems (R3)

Software architects know different types of IT systems, for example:

• information systems

• decision support, data warehouse or business intelligence systems

• mobile systems

• cloud native systems

• batch processes or systems

• systems based upon machine learning or artificial intelligence

• hardware-related systems; here they understand the necessity of hardware/software co-design (temporal and content-related dependencies of hardware and software design)

LG 1-11: Challenges of Distributed Systems (R3)

Software architects are able to:

• identify distribution in a given software architecture

• analyze consistency criteria for a given business problem

• explain causality of events in a distributed system

Software architects know:

• communication may fail in a distributed system

• limitations regarding consistency in real-world databases

• what the "split-brain" problem is and why it is difficult

• that it is impossible to determine the temporal order of events in a distributed system

2. Design and Development of Software Architectures

Duration: 330 min.

Excercises: 90 min.

Relevant Terms

Design; design approach; design decision; views; interfaces; technical and cross-cutting concepts; architectural patterns; pattern languages; design principles; dependencies; coupling; cohesion; top-down and bottom-up approaches; model-based design; iterative/incremental design; domain-driven design

Learning Goals

LG 2-1: Select and Use Approaches and Heuristics for Architecture Development (R1,R3)

Software architects are able to name, explain, and use fundamental approaches of architecture development, for example:

• top-down and bottom-up approaches to design (R1)

• view-based architecture development (R1)

• iterative and incremental design (R1)

  • necessity of iterations, especially when decision-making is affected by uncertainties (R1)

  • necessity of feedback on design decisions (R1)

• domain-driven design (R3)

• evolutionary architecture (R3)

• global analysis (R3)

• model-driven architecture (R3)

LG 2-2: Design Software Architectures (R1)

Software architects are able to:

• design and appropriately communicate and document software architectures based upon known functional and quality requirements for software systems that are neither safety- nor business-critical

• make structure-relevant decisions regarding system decomposition and building-block structure and deliberately design dependencies between building blocks

• recognize and justify interdependencies and trade-offs of design decisions

• explain the terms black box and white box and apply them purposefully

• apply stepwise refinement and specify building blocks

• design architecture views, especially building-block view, runtime view and deployment view

• explain the consequences of these decisions on the corresponding source code

• separate technical and domain-related elements of architectures and justify these decisions

• identify risks related to architecture decisions.

LG 2-3: Identify and Consider Factors Influencing Software Architecture (R1-R3)

Software architects are able to clarify and consider requirements (including constraints that restrict their decisions). They understand that their decisions can lead to additional requirements (including constraints) on the system being designed, its architecture, or the development process.

They should recognize and account for the impact of:

• product-related requirements such as (R1)

  • functional requirements

  • quality requirements

• technological constraints such as

  • existing or planned hardware and software infrastructure (R1)

  • technological constraints on data structures and interfaces (R2)

  • reference architectures, libraries, components, and frameworks (R1)

  • programming languages (R2)

• organizational constraints such as

  • organizational structure of the development team and of the customer (R1), in particular Conway’s law (R2).

  • company and team cultures (R3)

  • partnerships and cooperation agreements (R2)

  • standards, guidelines, and process models (e.g. approval and release processes) (R2)

  • available resources like budget, time, and staff (R1)

  • availability, skill set, and commitment of staff (R1)

• regulatory constraints such as (R2)

  • local and international legal constraints

  • contract and liability issues

  • data protection​ and privacy laws

  • compliance issues or obligations to provide burden of proof​

• trends such as (R3)

  • market trends

  • technology trends (e.g. blockchain, microservices)

  • methodology trends (e.g. agile)

  • (potential) impact of further stakeholder concerns and mandated design decisions

Software architects are able to describe how those factors can influence design decisions and can elaborate on the consequences of changing influencing factors by providing examples for some of them (R2).

LG 2-4: Design and Implement Cross-Cutting Concepts (R1)

Software architects are able to:

• explain the significance of such cross-cutting concepts

• decide on and design cross-cutting concepts, for example persistence, communication, GUI, error handling, concurrency, energy efficiency

• identify and assess potential interdependencies between these decisions.

Software architects know that such cross-cutting concepts may be re-used throughout the system.

LG 2-5: Describe, Explain and Appropriately Apply Important Solution Patterns (R1, R3)

Software architects know:

• various architectural patterns and can apply them when appropriate

• that patterns are a way to achieve certain qualities for given problems and requirements within given contexts

• that various categories of patterns exist (R3)

• additional sources for patterns related to their specific technical or application domain (R3)

Software architects can explain and provide examples for the following patterns (R1):

• layers:

  • abstraction layers hide details, example: ISO/OSI network layers, or "hardware abstraction layer"

  • another interpretation are Layers to (physically) separate functionality or responsibility

• pipes and filters: representative for data flow patterns, breaking down stepwise processing into a series of processing-activities ("Filters") and associated data transport/buffering capabilities ("Pipes").

• microservices split applications into separate executables that communicate via a network

• dependency injection as a possible solution for the Dependency-Inversion-Principle 

Software architects can explain several of the following patterns, explain their relevance for concrete systems, and provide examples. (R3)

• blackboard: handle problems that cannot be solved by deterministic algorithms but require diverse knowledge

• broker: responsible for coordinating communication between provider(s) and consumer(s), applied in distributed systems. Responsible for forwarding requests and/or transmitting results and exceptions

• combinator (synonym: closure of operations), for domain object of type T, look for operations with both input and output type T.

• CQRS (Command-Query-Responsibility-Segregation): separates read from write concerns in information systems. Requires some context on database-/persistence technology to understand the different properties and requirements of "read" versus "write" operations

• event sourcing: handle operations on data by a sequence of events, each of which is recorded in an append-only store

• interpreter: represent domain object or DSL as syntax, provide function implementing a semantic interpretation of domain object separately from domain object itself

• integration and messaging patterns (e.g. from Hohpe+2004])

• the MVC (Model View Controller), MVVM (Model View ViewModel), MVU (Model View Update), PAC (Presentation Abstraction Control) family of patterns, separating external representation (view) from data, services and their coordination

• interfacing patterns like Adapter, Facade, Proxy. Such patterns help in integration of subsystems and/or simplification of dependencies. Architects should know that these patterns can be used independent of (object) technology

  • adapter: decouple consumer and provider - where the interface of the provider does not exactly match that of the consumer. The Adapter decouples one party from interface-changes in the other

  • facade: simplifies usage of a provider for consumer(s) by providing simplified access

  • proxy: an intermediate between consumer and provider, enabling temporal decoupling, caching of results, controlling access to the provider etc.

• observer: a producer of values over time notifies a central switchboards where consumers can register to be notified of them

• plug-in: extend the behaviour of a component

• ports & adapters (syn. Onion-Architecture, Hexagonal-Architecture, Clean-Architecture): concentrate domain logic in the center of the system, have connections to the outside world (database, UI) at the edges, dependencies only outside-in, never inside-out

• remote procedure call: make a function or algorithm execute in a different address space

• SOA (Service-Oriented Architecture): an approach to provide abstract services rather than concrete implementations to users of the system to promote reuse of services across departments and between companies

• template and strategy: make specific algorithms flexible by encapsulating them

• visitor: separate data-structure traversal from specific processing

LG 2-6: Explain and Use Design Principles (R1-R3)

Software architects are able to explain what design principles are. They can outline their general objectives and applications with regard to software architecture. (R2)

Software architects are able to:

• explain the design principles listed below and can illustrate them with examples

• explain how those principles are to be applied

• explain how the requirements determine which principles should be applied

• explain the impact of design principles on the implementation

• analyze source code and architecture designs to evaluate whether these design principles have been applied or should be applied

Abstraction (R1)

• in the sense of a means for deriving useful generalizations

• as a design technique, where building blocks are dependent on the abstractions rather than depending on implementations

• interfaces as abstractions

Modularization (R1-R3)

• information hiding and encapsulation (R1)

• separation of concerns - SoC (R1)

• loose, but functionally sufficient, coupling (R1) of building blocks

• high cohesion (R1)

• SOLID principles (R1-R3), which have, to a certain extent, relevance at the architectural level

  • S: Single responsibility principle (R1) and its relation to SoC

  • O: Open/closed principle (R1)

  • L: Liskov substitution principle (R3) as a way to achieve consistency and conceptual integrity in OO design

  • I: Interface segregation principle (R2)

  • D: Dependency inversion principle (R1) by means of interfaces or similar abstractions

Conceptual integrity (R2)

• meaning uniformity (homogeneity, consistency) of solutions for similar problems (R2)

• as a means to achieve the principle of least surprise (R3)

Simplicity (R1-R2)

• as a means to reduce complexity (R1)

• as the driving factor behind KISS (R3) and YAGNI (R3)

Expect errors (R1-R2)

• as a means to design for robust and resilient systems (R1)

• as a generalization of the robustness principle (Postel’s law) (R2)

Other principles (R3)

Software architects know other principles (such as CUPID), and can apply them.

LG 2-7: Manage Dependencies between Building Blocks (R1)

Software architects understand dependencies and coupling between building blocks and can use them in a targeted manner. They:

• know and understand different types of dependencies of building blocks (e.g. coupling via use/delegation, messaging/events, composition, creation, inheritance, temporal coupling, coupling via data, data types or hardware)

• understand how dependencies increase coupling

• can use such types of coupling in a targeted manner and can assess the consequences of such dependencies

• know and can apply possibilities to reduce or eliminate coupling, for example:

  • patterns

  • fundamental design principles

  • externalization of dependencies, i.e. defining concrete dependencies at installation- or runtime, for example by using Dependency Injection.

LG 2-8: Achieve Quality Requirements with Appropriate Approaches and Techniques (R1)

Software architects understand and consider the considerable influence of quality requirements in architecture and design decisions, e.g. for:

• efficiency, runtime performance

• availability

• maintainability, modifiability, extensibility, adaptability

• energy efficiency

They can:

• explain and apply solution options, Architectural Tactics, suitable practices as well as technical possibilities to achieve important quality requirements of software systems (different for embedded systems or information systems)

• identify and communicate possible trade-offs between such solutions and their associated risks

LG 2-9: Design and Define Interfaces (R1-R3)

Software architects know about the importance of interfaces. They are able to design or specify interfaces between architectural building blocks as well as external interfaces between the system and elements outside of the system.

They know:

• desired characteristics of interfaces and can use them in the design:

  • easy to learn, easy to use, easy to extend

  • hard to misuse

  • functionally complete from the perspective of users or building blocks using them.

• the necessity to treat internal and external interfaces differently

• different approaches for implementing interfaces (R3):

  • resource oriented approach (REST, Representational State Transfer)

  • service oriented approach (see WS-*/SOAP-based web services.

LG 2-10: Know Fundamental Principles of Software Deployment (R3)

Software architects:

• know that software deployment is the process of making new or updated software available to its users

• are able to name and explain fundamental concepts of software deployment, for example:

  • automated deployments

  • repeatable builds

  • consistent environments (e.g. use immutable and disposable infrastructure)

  • put everything under version-control

  • releases are easy-to-undo

3. Specification and Communication of Software Architectures

Learning Goals

LG 3-1: Explain and Consider the Requirements of Technical Documentation (R1)

Software architects know the requirements of technical documentation and can consider and fulfil them when documenting systems:

• understandability, correctness, efficiency, appropriateness, maintainability

• form, content, and level of detail tailored to the stakeholders

They know that only the target audiences can assess the understandability of technical documentation.

LG 3-2: Describe and Communicate Software Architectures (R1-R3)

Software architects use documentation to support the design, implementation and further development (also called maintenance or evolution) of systems (R2)

Software architects are able to (R1):

• document and communicate architectures for corresponding stakeholders, thereby addressing different target groups, e.g. management, development teams, QA, other software architects, and possibly additional stakeholders

• consolidate and harmonise the style and content of contributions from different groups of authors

• develop and implement measures to support the convergence of written and verbal communication, and balance one against the other appropriately

Software architects know (R1):

• the benefits of template-based documentation

• that various properties of documentation depend on specific properties of the system, its requirements, risks, development process, organization or other factors.

For example, software architects can adjust the following documentation characteristics according to the situation (R3):

• the amount and level of detail of documentation needed

• the documentation format

• the accessibility of the documentation

• formality of documentation (e.g. diagrams compliant to a meta model or simple drawings)

• formal reviews and sign-off processes for documentation

LG 3-3: Explain and Apply Notations/Models to Describe Software Architecture (R2-R3)

Software architects know at least the following UML diagrams to describe architectural views:

• class, package, component (all R2) and composite-structure diagrams (R3)

• deployment diagrams (R2)

• sequence and activity diagrams (R2)

• state machine diagrams (R3)

Software architects know alternative notations to UML diagrams, for example: (R3)

• Archimate

• for runtime views for example flow charts, numbered lists or business-process-modeling-notation (BPMN).

LG 3-4: Explain and Use Architectural Views (R1)

Software architects are able to use the following architectural views:

• context view

• building block or component view (composition of software building blocks)

• runtime view (dynamic view, interaction between software building blocks at runtime, state machines)

• deployment view (hardware and technical infrastructure as well as the mapping of software building blocks onto the infrastructure)

LG 3-5: Explain and Apply Context View of Systems (R1)

Software architects are able to:

• depict the context of systems, e.g. in the form of context diagrams with explanations

• represent external interfaces of systems in the context view

• differentiate business and technical context.

LG 3-6: Document and Communicate Cross-Cutting Concepts (R2)

Software architects are able to adequately document and communicate typical cross-cutting concepts (synonym: principles, aspects), e. g., persistence, workflow management, UI, deployment/integration, logging.

LG 3-7: Describe Interfaces (R1)

Software architects are able to describe and specify both internal and external interfaces.

LG 3-8: Explain and Document Architectural Decisions (R1-R2)

Software architects are able to:

• systematically take, justify, communicate, and document architectural decisions

• identify, communicate, and document interdependencies between design decisions

Software architects know about Architecture-Decision-Records (ADR) and can apply these to document decisions (R2).

LG 3-9: Know Additional Resources and Tools for Documentation (R3)

Software architects know:

• basics of several published frameworks for the description of software architectures, for example:

  • ISO/IEEE-42010 (formerly 1471)

  • arc42

  • C4

  • FMC

• ideas and examples of checklists for the creation, documentation, and testing of software architectures

• possible tools for creating and maintaining architectural documentation

4. Software Architecture and Quality

Relevant Terms

Quality; quality characteristics (also called quality attributes); DIN/ISO 25010; quality scenarios; quality tree; trade-offs between quality characteristics; qualitative architecture analysis; metrics and quantitative analysis

Learning Goals

LG 4-1: Discuss Quality Models and Quality Characteristics (R1)

Software architects can explain:

• the concept of quality and quality characteristics

• generic quality models

• correlations and trade-offs of quality characteristics, for example:

  • configurability versus reliability

  • memory requirements versus performance efficiency

  • security versus usability

  • runtime flexibility versus maintainability.

LG 4-2: Clarify Quality Requirements for Software Architectures (R1)

Software architects can:

• clarify and formulate specific quality requirements for the software to be developed and its architectures, for example in the form of scenarios and quality trees

• explain and apply scenarios and quality trees.

LG 4-3: Qualitative Analysis of Software Architectures (R2-R3)

Software architects:

• know methodical approaches for the qualitative analysis of software architectures (R2), for example, as specified by ATAM (R3);

• can qualitatively analyze smaller systems (R2)

• know that the following sources of information can help in the qualitative analysis of architectures (R2):

  • quality requirements, e.g. in the form of quality trees and scenarios

  • architecture documentation

  • architecture and design models

  • source code

  • metrics

  • other documentation of the system, such as requirements, operational or test documentation.

LG 4-4: Quantitative Evaluation of Software Architectures (R2)

Software architects know approaches for the quantitative analysis and evaluation (measurement) of software.

They know that:

• quantitative evaluation can help to identify critical parts within systems

• further information can be helpful for the evaluation of architectures, for example:

  • requirements and architecture documentation

  • source code and related metrics such as lines of code, (cyclomatic) complexity, inbound and outbound dependencies

  • known errors in source code, especially error clusters

  • test cases and test results.

• the use of a metric as a target can lead to its invalidation (R2), as described, e.g., by Goodhart’s law (R3).