“As architects, you have the opportunity to create spaces that inspire, uplift, and bring people together.”
I recently wrote a blog on whether software architects matter. The blog was written quickly and without much consideration, which sparked discussions among my professional network, particularly among architects. Many of these discussions focused on the role of an “agile” software architect. My suggestion that most design decisions be made by the team appeared to be the trigger point for these discussions. In light of this, I have compiled a list of things that I believe “agile” software architects should be doing:
Be part of the development team – You are there to inform, motivate, and influence the team without expending social capital by forcing your decisions. Being removed from the actual development effort and simply flinging architectural documents (that probably don’t reflect actual system code) at developers is not good enough anymore.
Adapt to the team’s way of working – Not the other way around. In order to build high-performance teams, you need to create space for autonomy, mastery, and purpose. The autonomy boundary can be constrained, but each team’s sweet spot in terms of their way of working will differ slightly. Standardizing your approach will simply lack the flexibility and variability that modern teams need and require.
Your job is to accelerate the project, not to slow it down – Your goal is to keep the project moving forward and avoid slowing it down. Be flexible and willing to change priorities, discard unnecessary requirements, and experiment with new ideas. Above all, keep the flow of value creation going. Don’t get stuck trying to understand or gain consensus on every detail. Instead, defer decision-making as long as possible and focus on the high-risk areas that could derail your design. This will help you avoid becoming a bottleneck in the development process
Your job is primarily about communication; do it often and early – Keep the lines of communication open and start early. It can be difficult to achieve a shared understanding among all project stakeholders, but transparency and simplicity can help. Avoid complicated diagrams and strive to provide context and understanding. Repeat key points until a common understanding is reached and people start taking initiative. Then, simply curate and ensure accuracy without stifling people’s attempts to contextualize the information.
Focus on the essence of the problem, the simpler the better – Stop creating artefacts, documents, and stuff that nobody can contextualize. Even if you have to explain things over and over again, this will refine the concept in your head and provide extra insights. Look at initiatives like C4 diagrams to get your drawings more in line with the actual thing being built.
Test your architecture – Prototypes and POCs are single-handedly the best way to validate parts of your architecture. But in too many organizations, this is seen as a waste of time and money. Change the way you fund projects and cater for this activity. While you are at it, always add slack for testing the non-functionals of your architecture (scalability, performance, and robustness).
Question standard practices and seek out new ideas – Don’t be afraid to challenge the status quo and seek out new ideas and approaches. The world of software development is constantly evolving, and it is important for architects to stay current and adapt to new methodologies and technologies. This will help you to stay relevant and effective in your role.
In conclusion, the role of the agile architect is to be an active and influential member of the development team, adapt to the team’s way of working, accelerate the project, communicate effectively, focus on the essence of the problem, test the architecture, and seek out new ideas. By following these principles, you can help your team to build better software and achieve greater success.