Does Agile need architecture to be successful?
At a recent Agile conference, one of the speakers opened his speech with the words: “Agile without a plan is only chaos”. Agile without effective architecture in place will eventually lead to chaos, especially when organizations try to scale their Agile practice without any reference framework.
As architects, we all try to operate within partially given constraints, which in their nature can be customer oriented, financial, regulatory, technical or competitive. While agile practices have traditionally been limited to software development, companies, especially large enterprises, are under considerable pressure to use agile practices to manage traditional business functions. This new trend is euphemistically referred to as “New Ways of Working”. The benefits of using agile practices are many, with the fundamental advantage that companies see agile practices as a way to deliver better results to their customers and stakeholders – faster, more efficiently, continuously and more consistently. This can only work if basic enterprise architecture elements are defined and a framework is provided that supports agile procedures.
The use of an architectural framework that is perceived as old-fashioned, such as TOGAF®, seems to stand in direct contrast to the agile and slim view of the world. It is extremely detailed with numerous frameworks, techniques, and templates described in a fairly sterile manual covering nearly 700 pages. This does not fit in well with the agile focus on favouring working software over documentation.
There’s a cultural difference here, like everything else. Agile is committed to unrestricted teams and promotes direct collaboration, while the world perceives TOGAF as architecture boards and carefully indexed document repositories.
It is important to note that TOGAF captures delivery objects that are created and needed in a large organization anyway, regardless of whether they are executed as part of a framework. Enterprises should all have a kind of architectural vision that is aligned with a business strategy. They need to track their capabilities and applications portfolio, perform costing calculations, make architectural decisions, reduce unnecessary repetitions, document processes, enable common agreement on how to proceed, and ensure that decisions are fair and transparent. At the same time, TOGAF artifacts such as lists, matrices and models can be reused in other organizations such as quality management, business process management, ISO certification documentation, etc. New approaches in low-code application development such as APPIAN allow the direct reuse of BPMN 2.0 models – created e.g. during architectural work – for the agile development of applications with minimal programming effort.
TOGAF is not a rigid frame that must be strictly followed. Rather, it is intended to actively encourage practitioners to adapt and modify the framework to the circumstances. This means that the different parts of TOGAF can be adapted and adopted to agile development. Many believe that TOGAF implies a waterfall approach – and that’s not exactly true.
SAFe
Most agile frameworks that try to implement Scrum for large organizations always have a placeholder for architecture. The main difference is that they tend to emphasise cooperation, simplicity and decentralised governance. This can take place in its full beauty in the capability architecture within the framework of strategic and segment architecture.
The SAFe (Scaled Agile Framework) framework has contributed most to identifying the role of architecture in an agile environment. As with all things around Agile, it’s about creating a consistent value, and architecture is no different.
The Architecture Domains in SAFe are the same as the Architecture Domains in TOGAF, which simplifies the assignment very much.
Emergent Design
Emergent Design provides the technical foundation for the development and gradual implementation of initiatives. It helps designers and architects respond to changing customer and stakeholder needs to ensure that the initiative continues to create value. At this level, SAFe practitioners see architecture as a collaborative and interactive exercise that can create the design element.
Intentional Architecture
Intentional architecture is a more structured approach and is more aligned with what many would call traditional architecture, i.e. a set of defined and planned architectural initiatives designed to support and improve the performance and usability of the initiative. Indeed, Intentional Architecture is a clear realization that we all must operate within certain constraints, such as the choice of architectural guidelines, technology platform, financial budget, etc. If these constraints can be identified and integrated into the initiative, the likelihood that the initiative will be successful and deliver value increases, or the results will trigger architectural adjustments as part of Architecture Change Management.
SAFe practitioners claim that by balancing emerging design and intentionality, agile practices can be scaled to deliver enterprise-level solutions. In SAFe, this combination is related to the Architectural Runway, which provides the technical foundation for creating business value, which is fully consistent with traditional views of architecture.
The key to the success of this approach lies in the level of abstraction at which the balance between Enterprise Architecture, Emergent Design and Intentional Architecture takes place.
Even in an agile world, the role of the architect remains a key one. Training and, if necessary, certification in one of the frameworks, such as TOGAF, is sensible and effective. Some architects must also have knowledge, skills and experience in Agile, SAFe and SCRUM. All team members must understand how enterprise architecture and Agile fit together.
The ability to work together is one of the key skills needed here. Architects must be able to productively collaborate with Agile teams to provide rapid and local support in the application of Emergent Design, while helping Agile teams identify and manage the constraints defined by Intentional Architecture. One of the most important features of Agile Practices is the fact that Agile teams are encouraged to provide continuous feedback to their stakeholders. When developing new designs, architects can use this information to adapt and develop Intentional Architecture to ensure that the overall architecture of the organization evolves with the organization in the medium to long term.