Many of you may have heard of the Disciplined Agile Framework (DA) created by Scott Ambler and Mark Lines but many have not realised the Architectural input this framework gives us for putting architecture back on the Agile roadmap.
Agile has forgotten Architecture?
In many respects the discipline of Architecture has been at best missed out from Agile frameworks and at worst is scorned by emergent design evangelists.
The Scaled Agile Framework (SAFe) is brilliant for many things and talks about Architecture as a first class citizen, but there is little to address architecture in practice.
The DA framework however is created by Scott and Mark who both come from an architectural background, with Scott having written many books such as Agile Modelling, Refactoring Databases, Elements of UML and a Practical Guide to Enterprise Architecture. This is consolidated in his book and work on the Disciplined Agile Delivery Framework.
Disciplined Agile
The framework is an end to end delivery system with enterprise awareness and scaling agility built in and therefore includes the items other frameworks shy away from such as Architectural Governance, Architectural Modelling and Continuous Documentation.
The framework is a hybrid and includes core values, principles and practices from Extreme Programming, Agile Modelling and Agile Data. All of these lend a strong architectural bias to the delivery.
The Architect Owner Role
The framework has a number of primary roles at the team level, one of which is the Architecture Owner. The Architectural Owner is responsible for identifying and managing key elements of project risk and is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design. This role is the equivalent to the roles we know as Software Architect, Solutions Architect or Technical Architect but has significant differences too.
The responsibilities identified for the Architecture Owner are:
- Guiding the creation and evolution of the architecture of the solution that the team is working on. Note that the architecture owner is not solely responsible for the architecture but leads the technical discussions.
- Mentoring and coaching other team members in architecture practices and issues.
- Understanding the architectural direction and standards of your organisation and helping to ensure that the team adheres to them appropriately.
- Understanding existing enterprise assets such as frameworks, patterns, and subsystems, and ensuring that the team uses them where appropriate.
- Ensuring that the solution will be easy to support by encouraging good design and refactoring to minimise technical debt.
- Ensuring that the solution is integrated and tested on a regular basis, ideally via the practice of continuous integration (CI). Having the final say regarding technical decisions, but they try to avoid dictating the architectural direction in favour of a collaborative, team- based approach. The architecture owner should work closely with the team lead to identify and determine strategies to mitigate key project technical risks.
- Leading the initial architecture envisioning effort at the beginning of the project and supporting the initial requirements envisioning effort (particularly when it comes to understanding and evolving the nonfunctional requirements for the solution).
To summarise then, the Architecture Owner needs to be able to facilitate the creation of the architecture but not enforce it, they need to coach and train other team members, perform architectural spikes to reduce technical risk and mentor teams in the participation of enterprise level technical guidance, for example coding standards, database guidelines and global asset libraries.
As part of the delivery process, Architect owners envision the initial architecture using high level modelling. The emphasis is learning by doing the modelling, not on the models themselves. Architects then communicate and sell the architecture rather than telling to stakeholders and then using feedback and working with developers, architects then update models and work products.
Scaling Agile Architecture
As the size of the projects scale, Scott and Mark make use of the Agile Scaling Model (ASM) and use Architect owner coordinators and the concept of Enterprise Disciplines such as Enterprise Architecture.
Using the Agile Data Method’s third philosophy:
“Enterprise groups exist to nurture enterprise assets and to support other groups, such as development teams, within your organization. These enterprise groups should act in an agile manner that reflects the expectations of their customers and the ways in which their customers work.”
Scott and Mark address six fundamental issues:
- Focus on people, not technology or techniques
- Keep it simple
- Work iteratively and incrementally
- Roll up your sleeves
- Look at the whole picture
- Make enterprise architecture attractive to your customers
In addition to guiding on roles, responsibilities and how Architects fit into a scaled agile organisation, the framework also addresses governance.
Transitioning to Agile
Scott and Mark has also done work overcoming the challenges that traditional architects face when making the transition to agile, believe architects need to be able to prove the architecture by coding NFR testing, have leadership skills and not be the product owner.
The framework focuses architects on favouring enterprise assets instead of teams building their own and allowing self-organizing design over ivory tower architecture or gold plated architecture.
The disciplined Agile Framework is the only scaling agile framework to properly look at architecture, artefacts, and the roles and responsibilities of an architect.