iSAQB® AGILA - Agile Software Architecture

This part settles how much architecture work a project genuinely needs.

• Which definitions of architecture suit agile settings, and where architecture borders on design
• Values and principles of the agile manifesto, complexity through the Cynefin framework
• The tasks of architecture development and how their working style shifts in an agile setting
• Just enough architecture work: criteria for architectural relevance and waste reduction from lean

Here you learn to create orientation without pre-empting a complete design.

• Developing an architecture vision and architecture communication canvas the lightweight way
• Planning a walking skeleton with broad architectural coverage and separating it from an MVP
• Risk-driven architecture work, prioritising architecture topics in the backlog
• Role models from architecture owner to a team with no explicit architecture role

The second-longest part puts quality requirements into a shape a team can work with.

• Naming quality attributes per ISO/IEC 25010 and phrasing them as scenarios or acceptance criteria
• Anchoring architecture requirements as quality stories, enabler stories or tech tasks
• Spotting technical debt and tracking it through static analysis and monitoring data
• Estimation and prioritisation, urgency and the last responsible moment

The longest part of the curriculum practises what agile architecture work comes down to: deciding together.

• Applying group decision procedures: consensing, voting and veto formats
• Facilitating decision processes and handling objections constructively
• Setting decision scopes and architecture principles as guard rails
• Just-in-time decisions, set-based design and architecture decision records

This part closes the loop: architecture gets checked continuously instead of signed off once.

• Running lightweight evaluation formats such as DCAR and LASR
• Finding the causes of architecture problems with root cause analysis and 5-why
• Selecting quality indicators, reading their trends and tracing them back to architecture goals
• Embedding fitness functions in CI/CD with tools such as ArchUnit or jQAssistant

This part is about several teams at once and how much autonomy an organisation can carry.

• Establishing architecture as a base capability through communities of practice and architecture katas
• Centralisation against decentralisation, governance through principles rather than rules
• Weighing architecture boards, advice forums and the architecture advice process
• Socio-technical systems, Conway's law and team topologies

To close, you work through real projects rather than textbook cases.

• At least two projects of differing size and how each of them reaches architecture decisions
• Architecture requirements as they actually appear in stories and backlogs
• Architecture walls, information radiators and architecture radars from practice
• Architecture communities and guilds: how companies build them and keep them alive