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 inn 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.
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.