A discussion about changes in architecture in engineering
I started writing this with the question, “Is architecture dead,” which felt a bit clickbait, so I thought it better to focus on something that seems more useful to those who work in the industry. To be clear, I don’t think the role of architecture in engineering is dead, but there is no doubt that it has changed a lot in the last 30 years.
My position on this has changed several times over the years, but I have finally landed on the feeling that architecture is still a useful discipline – but how we think about it and how it is presented in an organization has changed. .
We are no longer building ornate cathedrals for teams to go away and build imagination. We are setting the direction, empowering the teams, and arranging a playing field to achieve the best results.
My ‘good’ answer to this question is that there was nothing wrong with the architecture – it adapted to the constraints of the time. 30 years ago, solving problems with software was complicated, expensive, and time-consuming. It was hard to build and test things fast, even aspects of a problem that required a complete solution built from the ground up, and it was easy to get it wrong.
Perhaps time and constraints resulted in well-crafted plans that teams of engineers followed to reach the end goal or solve a customer’s problem.
But if I’m honest, it always had problems.
My ‘not-so-nice’ answer is that building software was difficult in many ways, but the role of architecture was born out of a top-down, command and control, upfront planning approach. But worst of all, it encouraged ivory towers, engineering production lines, and attracted arrogance…
so while it May Been somewhat necessary, this was always the problem for me. I would also say that many of these problems still exist in some places today, but architecture has a role to play. It’s just not the role she was in.
The pace of technological change over the past 30 years has been incredible – both in technology and also in socio-technological practices. Some of the changes that have changed the face of engineering include the following:
- Compute power is increased and is readily available, allowing for much faster compile times
- Virtualization and then cloud computing have changed how easy it is to implement change
- Open source software has enabled the massive sharing of capacity in coding, accelerating our ability to create new things and solve new problems in new ways.
- The Internet has many influences, but especially here, it has intensified the ability to share and iterate code and practices.
- Continuous Integration and Automated Testing means we have very fast feedback loops during build, test and deployment
- Agile and lean delivery practices make us think differently about empowerment and flow
By combining these factors and many other tools we can create, transform and deploy things more fluidly, and we achieve the best results by making decisions closer to knowledge.
These things mean that top-down, command and control, and up-front planning require much less and produce worse results.
After all, you might think that architecture is a horrible, unnecessary evil that we should eliminate completely, but I think it has a place… it’s a different place with a different set of behaviors.
These days discipline is less about the architecture of a cathedral and more about turning the game out. If it were football, it would be like agreeing to the rules of the game, the pitch we’re playing on, maybe team formation, and maybe even a little coaching or help on the finer details.
The first aspect of the role is to give direction or to set a target position. It should not be a detailed instruction, but a vision of where we are going. Without a guiding light, it would be difficult to move in the right direction.
What makes this one of the most interesting aspects is that I see the role of architecture being adopted by many on the playground. Of course, there may be an enterprise, solutions, or technical architect whose focus is architecture – but everyone in the engineering endeavor has an architectural responsibility – all with a different set of constraints and at different levels of fidelity.
I am a great believer and proponent of a strong, self-sufficient team that can take a significant level of autonomy in their decision-making, but I have rarely seen a situation where this autonomy is sensible when it is absolute. Attacking each new initiative with different techniques, paradigms and approaches doesn’t make sense in most situations.
At Oakbrook, we take the freedom with fence approach—sometimes, those fences are the tough rules, but sometimes they’re the guidelines. In any case, those railings need to be laid and a direction setting – this is one of the major aspects architecture plays.
One way we often do this is to set strong rules and a golden path—a path that automatically delivers when those rules are followed. For example, we can say that all intraservice communications must use mutual TLS. You’ll get most of that built-in if you deploy to our technology stack, but if you choose a new approach outside the stack, you’ll have to build and test that capability yourself. The election is there, but a good reason is needed to pursue it.
Another role the architecture team can play is assisting with arrangement, especially in the early days of a project. Often, when we embark on a project, we have competing priorities – the priority is to deliver immediate customer value, but in most cases, this should not be done without considering capacity development.
We can help facilitate the delivery of capacity with customer value by using the reverse Conway maneuver. In this way, an architect can help arrange teams to ensure the best synergy of capacity development with customer value creation.
The ultimate role of a modern-day architect is that of advisor and servant leader. Generally speaking, architects will be highly competent and highly technical individuals – and they really need to be technically competent to be effective.
To this end, a good architecture function provides guidance, training, mentoring and proactive training for comprehensive engineering efforts to help them achieve their goals. It should be support servant leadership – help the team overcome cognitive barriers and overcome technical challenges.
Overall the role of architecture is important and valuable. It was not what it was or what many people think it is. It should not be an ivory tower role but a servant leader role adopted by many people throughout the organization.