Curriculum for

Certified Professional for
Software Architecture (CPSA)^®

: Foundation Level

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

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

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

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

analyze and evaluate software architecture, especially with respect to risks that involve meeting the requirements, see LG 4-3: Qualitative Analysis of Software Architectures (R2-R3) and LG 4-4: Quantitative Evaluation of Software Architectures (R2),

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

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

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.

should explicitly present assumptions or prerequisites, therefore avoiding implicit assumptions

know that implicit assumptions can lead to potential misunderstandings between stakeholders

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)

information systems

decision support, data warehouse or business intelligence systems

mobile systems

cloud native systems (refer to [Cloud-Native])

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)

identify distribution in a given software architecture

analyze consistency criteria for a given business problem

explain causality of events in a distributed system

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

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

view-based architecture development (R1)

iterative and incremental design (R1)

domain-driven design, see [Evans 2004] (R3)

evolutionary architecture, see [Ford 2017] (R3)

global analysis, see [Hofmeister et. al 1999] (R3)

model-driven architecture (R3)

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.

product-related requirements such as (R1)

technological constraints such as

organizational constraints such as

regulatory constraints such as (R2)

trends such as (R3)

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.

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)

layers:

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 [Newman 2015]

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. See [Yorgey 2012]

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

observer: An interested object (observer) registers with another object (the subject) so that the subject notifies the observer upon changes.

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 [Lange 2021] [Martin 2017]

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

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

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

information hiding and encapsulation (R1)

separation of concerns - SoC (R1)

loose, but functionally sufficient, coupling (R1) of building blocks, see LG 2-7

high cohesion (R1)

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

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

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

as a means to reduce complexity (R1)

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

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

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

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:

efficiency, runtime performance

availability

maintainability, modifiability, extensibility, adaptability

energy efficiency

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

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

the necessity to treat internal and external interfaces differently

different approaches for implementing interfaces (R3):

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:

understandability, correctness, efficiency, appropriateness, maintainability

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

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

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.

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

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

deployment diagrams (R2)

sequence and activity diagrams (R2)

state machine diagrams (R3)

Archimate, see [Archimate]

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

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)

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.

systematically take, justify, communicate, and document architectural decisions

identify, communicate, and document interdependencies between design decisions

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

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

possible tools for creating and maintaining architectural documentation

the concept of quality and quality characteristics (based on e.g. [ISO 25010] or [Bass+ 2021])

generic quality models (such as [ISO 25010], [Bass+ 2021], or [Q42])

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

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.

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):

quantitative evaluation can help to identify critical parts within systems

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

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