What is an architect? I found a really nice explanation in the (dutch) dictionary which freely translates to the words: thinker, inventor.
Elaborating on that notion: what makes a good architect? Second guess :)
Apart from broad and extensive knowledge that provides a wide range of options to solve a challenge at hand. I think that continuously challenging your thinking is an important part of the process to improve and evolve.
Recently I read a really nice article written by Gregor Hohpe on the infamous discussion about the presence of architecture within a software developing enterprise and how this discipline could be part of your organisation. In this blog I would like to share my ideas on this topic.
During my career I often heard development teams challenging the need for an architect. Usually these words would be accompanied with the infamous ivory tower statement. Words spoken as if architects are from another island and if and when they visit your team. They don’t understand software and are more likely to impede than to contribute to the solution.
This may have been the case in the past where - with respect to software engineering itself - ‘enterprise architect’ was the only architectural role common within larger organizations. However the solution architect (introduced around 2005) was not a commonly known role and software architects were more or less what we now may consider to be the lead developer in a team. That past often lacked communication between the enterprise scoped architect and the development teams. Which is a pity because the architect can enlighten the teams with his or her knowledge about the organisation’s business, industry standards, legal and security constraints and the vision towards the future. The development team on the other hand has all knowledge of today's technological capabilities and current state of their IT products. These engineers are continuously challenged in the here and now and push changes upon their arbitrary companion. They need to comprehend and implement the features in every detail to support end users in their daily operations. The engineers know first hand what works well and what doesn’t. I would expect that when both work together and share their knowledge, this would enhance both. Which should result in the best possible decisions on the solutions that will shape your IT.
With the increasing complexity of software systems nowadays, it is more common to encounter a diversity of architectural roles within a software developing enterprise. For instance, nowadays it’s not uncommon to have architects specialized in the areas of your business domain, web technology, system integration, security, data management, quality assurance, delivery etc. The people fulfilling those roles today have a good understanding of the modern concepts within their area of expertise. Together they could in fact embody the enterprise architect with more detail. Additionally, by their quantity they should be able to align with the development teams more often.
This brings me to the added value of these architects... In my opinion architects should bring knowledge and awareness to the teams and align and interconnect them such that the goals and dependencies are clear and the best decisions will be made. Which in turn should lead to software products which are stable, deterministic and support the users in their daily operations effectively. All of this in a safe manner, eliminating risk of causing harm and keeping the cost of change and ownership reasonable.
Why is it hard for teams to keep these perspectives? Teams are primarily focused on delivering value each sprint and enable the users with new features. The team operates in the here and now at a very detailed level and have a great view of the current state (and desired improvements). They might even not be (or willing to be) involved in future topics, which makes it hard (not impossible) to step back and look at the greater scheme of things and best options regarding the future state.
This brings me back to Gregor Hohpe’s article addressing how to organize architects within an organisation. Let me keep it simple here and summarize the organizational model as a choice between either having an architect outside of the teams vs one or more team members taking the responsibility for this role within the team. In my opinion in an ideal world, the architect is part of the team. Additionally all team architects participate in some form of guild to address cross-team concerns, the overall IT landscape and maintain a roadmap addressing future demands. These team architects would have a close relationship with the business representatives to understand their operations, demands, concerns and future prospects. Ideally this would result in teams that have embraced quality, ownership, responsibility and collaboration to move as one. Being empathic and proactive in the collaboration, sharing relevant knowledge, deliberation during decision making while keeping an eye on the future. On top of craftsmanship, this is essentially what is needed at scale to remain successful.
From my experience the number of engineers who are truly capable in switching between contexts and to guide their team as a group, are unfortunately sparse. Additionally, the people having the desirable experience usually come at a price. Not every organisation has the means or luck to attract these people and create such a culture. And if so, it may be hard to consistently provide enough challenges to keep such a team architect engaged over time and remain happy to fulfill the role.
From the continuum, the person fulfilling the role will grow and mature as an architect. This could result in a desire for a bigger challenge ultimately leading back to the other side of the spectrum of the organizational model: the architect operating over multiple teams.
Which of course doesn’t necessarily have to be bad but it will require an additional way of working to operate at scale. A modern architecture framework like SAFe or LeSS could still preserve synergy in the work and the way it should be done. Just bear in mind that because the architect is no longer part of the team, the architectural maturity within the team needs to be restored in time. During this period product quality, team agility and cost of change may suffer a bit from this change. Architecture is always present in software development and in my experience can save your team(s) from pitfalls, unnecessary cost, delay or worse: failure.
In my opinion organisations should embrace both models to preserve the architecture maturity. Depending on the currently available skills, you can choose and combine the models where a team architect can grow to become the solution architect acting over multiple teams while training the next team architects to become the solution architect in due time.
