Credit: https://bit.ly/3ZNf1ay
Introduction
In Part 1, we covered some of the basics of ADRs Architecture Decision Records, mainly their structure and implementation options. After a surprising amount of feedback, In Part 2 we will look more closely at the history of why change is needed and, the cultural side of implementing ADRs. Then the final part will look at the process, the people, and the all important role of an advisory board in the success of ADRs.
Culture Change
There is quite a large culture shift that occurs when an organisation goes through the implementation of ADRs. Not surprisingly, this is because every organisation is different across many different levels. Some may have almost religiously followed frameworks such as TOGAF in the past, while others may have taken an alternate route. The important note here is that change, is still change, no matter how large or small and being attuned to people throughout this process is critically important, as after all, it is the people who will champion the adoption and cultural shift required.
Traditional Architecture Process
For as long as I have been working, there has always been this concept of Tower Syndrome or Ivory Tower Architects, especially when it comes to large enterprise or heavily regulated environments. Early on in my career, I like many other aspiring technologists wanted to become a Solution Architect and change the world one solution at a time.
However, I always found it intriguing that whilst everyone wanted to be an architect. There seemed to be this negative connotation towards any kind of formal architecture practice. This led me to dive deeper into what are these concepts of Tower Syndrome and Ivory Tower Architects and the impact these practices may cause.
How Did We Get Here?
In a world before cloud, when workloads were hosted, managed and developed in physical data centers, either virtualised on a hypervisor or on actual hardware. There was a large amount of inherent risk when it came to the update, change or deployment of systems. Largely due to the fact that these workloads did not have an unlimited bucket of compute and/or storage available on demand, which had an impact on reliability, availability and led to the creation of single points of failure. this daily challenge was usually navigated by skilful engineers, through the use of manual actions driven by verbal processes, rather than the code-driven and automated solutions we know today.
This meant that the oversight needed on changes was large, as the impact of an incident in production could be catastrophic to the business. One of the ways that developed as a solution for this risk was the use of ITIL, a framework of practices for IT Service Management (ITSM), focused on the alignment of Operations and Services.
On the other side of the coin, in development and design land, a practice that gained traction and popularity was the concept of architecture frameworks such as TOGAF, focused on not only the technology decisions but also the business requirements and risk mitigation for changes to environments and systems.
For decades this worked quite effectively, however, as technology changed and virtualisation became more and more popularised, cracks began to form in the process. Namely when it came down to the speed at which the traditional architecture frameworks and processes could be executed within large enterprise. This gap that formed is what I believe lead to the creation of Ivory Tower Architects. That being said, what does that mean?
Scott Ambler in his article on the Agile Modelling Approach defined it as:
Ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).
What Does This Look Like?
Above, you can see my, some may say, cheeky interpretation of what a simplified architecture practice may look like before implementing a process such as Architecture Decision Records. As we spoke about before with the use of ITIL and TOGAF we need frameworks to contain risk, this can be seen directly in this visualisation through the singular pillar of architects. It is within this type of structure where Tower Syndrome can grow and thrive, especially if an enterprise is in a position to hire more and more architects. We saw prolific examples of this structure within Financial sectors and major Banks within Australia.
This article announces changes to a more agile architectural approach for ANZ Bank back in 2017.
This Before stage worked for quite some time, enabling architecture to be a point of control, audit and risk management. But as Cloud Technologies became more heavily consumed this structure came under more and more pressure to scale, as more and more technical staff, needed often smaller, design decisions to be completed at a much higher throughput than ever before.
So the question really became how do we enable a new architectural model that can scale the same way our systems do in the cloud. How do we remove the bottlenecks?
The answer, is to use principles that empower and provide guidance with a light-touch governance wrapper to enable speed and scale, without sacrificing standards.
New Way of Working
As you may have suspected the use of ADRs enables us to segment those decisions into smaller, faster and more frequent decisions. But there are a few important points to consider, as simply rolling out ADR Confluence Pages won’t transform architectural practice that has largely succeeded for decades.
The first change we see in this model on the left side is that we are now interacting with Business Requirements instead of Technical Staff. Changes like this usually happen in conjunction with holistic agile transformations. Agile Programs or Digital Transformations are typically leveraged in an effort to reshape businesses to bring technology closer to their customers. This is what leads us to have our design decisions now more directly linked to the Business Requirements.
The biggest change is that we no longer have the Ivory Tower, we have multiple groups of roles, such as Infrastructure Engineers, Developers, Security Engineers and Architects. All who are able to work on documenting design decisions through ADRs before finally being presented to the Advisory Board.
Much to the surprise of some, the role of Architects does not disappear, and in some elements becomes more important. Below we can see a very high-level diagram of what this New Way of Working begins to look like. Immediately it can be seen that there is alot more than the traditional role of Architects leveraged in this model.
The Role of Architects
It is important to note that in the above diagram Architects is a group, not a function, so there may be Data, Security or Cloud Architects all playing the functional role of architecture in this diagram.
In this new model, architects have a critical role to play, whilst continuing to provide technical leadership, the role pivots to enable spending more time in an advisory or consultative capacity to others leveraging this process. Helping to empower and enable the newer roles to this style of documentation and design decisions. The objective of this model is not to undermine the business value that architecture has given in the past but aims to broaden the roles that are empowered to make decisions and to diversify the impact of architects by employing more scalable methods.
Think of that favourite architect you worked with in your career. Maybe it is one you are working with now or one from when you were much earlier in your career. At least for me, this architect was a champion of the deeply technical and gave a safe space where they could voice their concerns, ideas and thoughts. They were passionate about ensuring that the value in diversity of ideas was understood amongst all, and most importantly would push the envelope of common sense, when it seemed to escape others.
This led not only to a more collaborative approach, between engineers, developers, and other technical roles, but to a greater value outcome for the business.
Final Thoughts
There is a lot of water under the bridge when it comes to technology architecture in large enterprise. Just as we have evolved how we leverage infrastructure services, moving from On-Premises to Cloud, we have to also look at our non-technical processes and ensure they can keep pace with new and enabling technologies.
Part 3, the final part of this series will look much closer at the people, process and the role of a Technology Advisory Board (TAB) in the ADR Process.