Driving Agile Architecting with Cost and Risk

Abstract

A lot has been said and written about the relationship between agile development and architecture. As long ago as four years back, IEEE Software had a special issue on it. It looks like the debate is starting to settle down: we see agile methods that include architecting, like the Scaled Agile Framework, and we see architecting frameworks like TOGAF add agile elements. As the dust is settling down, what have we learned? At CGI 1 , architects have learned to use economic drivers like risk and cost to enhance the agility of their work. Below are five pieces of advice that architects can use to become effective in an agile world, without having to implement a new method or framework. They describe changes in attitude or behavior rather than complete practices or principles, and so are easy to digest and apply. The ideas are based on a solution architecting approach called Risk-and Cost-Driven Architecture. Core to the approach is the use of risk and cost to determine the architectural significance of concerns. Agility is achieved by keeping the architecture lightweight , addressing only those concerns that are especially risky or costly to address. A risk-and cost-driven backlog of architectural concerns balances the generally value-driven product backlog to achieve "just enough anticipation" in the evolution of software solutions.

A process for DoDAF based systems architecting

“…It is necessary however to make the distinction between artifact and purpose, with regards to the latter, Poort [16] asserts that "the architect's main deliverable isn't a document but a stream of decisions". The architect's role consists in identifying architectural concerns to address, the options available for addressing those concerns, and appropriate courses of action given the current context [16]. Thus the artifacts of his work must consist of a record of the concerns from typically multiple stakeholders, and how this is translated into design options and rationale for decision making.…”

Faster is Better and Cheaper

“…In this section we link the principles of Agile/DevOps (Beck,2001, SAFe, 2015Poort 2014, Bass, 2015 to the knowledge and wisdom captured in the Systems Engineering processes (Walden,2015). First these principles are listed, then the coverage of Agile and DevOps is plotted on the Systems Engineering Processes.…”

“…• Teams define their quality standards explicitly in a definition of done statement and reflect on their own functioning and improve their way of working Scaled Agile practices (SAFe, 2015;Poort 2014) relevant for comparison are formulated as:…”

“…• In Scaled Agile methods inter-team and enterprise wide decision making is formalized. Enterprise Architecture or Technology decisions are addressed using the just enough anticipation principle (Poort, 2014), also called 'the architecture runway' a metaphor where enterprise architecture has to adjust the landing strip to the requirements of approaching aircraft.…”

Aligning Architecture Work with Agile Teams

“…Eltjo Poort ex-plained how to use risk and cost to drive this decision flow. 1 Capture clear architecture principles. Agile teams need each team member to be able to make good design decisions.…”