Home United States USA — software The Death of the Architect

The Death of the Architect

133
0
SHARE

Using Neitzche as a philosophical foundation, an argument is made for the elimination of the "architect" title based on its lack of clarity and purpose.
I am going to take time to explain as to why this needs to happen. I have played different roles within architecture as well as engineering for many years across a variety of companies present in various countries.
My opinion is a reflection of my current thoughts formed based on my experience as well as many different discussions I had with a variety of engineering people I have met over many years. They are neither totally reflective nor the opinion of organizations I have been associated.
What exactly is the role of the architect? This isn’t clear in many places. Many of the organizations have a huge baggage of additional roles created to assist the Development Teams. Most common of these roles are:
There are umpteen definitions of an architect which makes an easy description of the role very difficult. Some of the examples are:
In many places, the responsibilities of the roles are not defined very clearly, leading to a good amount of ambiguity. Rather than having a clear understanding of how to add value to the organization, architects are left to provide meaning to their existence. This eventually ends up constructing a team of very complex people trying to define their value and many times at odds with the development teams, thereby slowing the delivery. If the roles and expectations are not very clear it is in the best interest of the enterprise to eliminate these roles.
Many times, companies make some of their brightest engineers architects. This is more of a retention mechanism. Slowly, the architect gets sucked into meetings. Though unsure, everybody fancies the title “architect” and enjoys hanging around with the architect. He gets less hands-on but keeps reading to keep himself updated. There are many who unleash their creative side and become an “Artist architect,” furiously producing a variety of artifacts without ever wondering whether they are really needed. Steadily an architect loses many of his engineering skills. This lack of skills brings fear and produces habits like:
These are solid smells of bad architecture teams in general and bad architecture leadership styles. In most of the cases, these teams tend to be led by management who have never done any coding but is still intelligent and able to identify the mistakes of others. The sooner this kind of leadership or the team is transformed, the better it is for the organization.
Despite many of the challenges outlined there are many smart architects who add immense value to the team. They make important technical decisions and drive the teams. However, most of the developers get accustomed to the majority of important decisions being made for them. This reduces them to mere coders who would simply like to code and solve the technical problems. Eventually, the organization is crippled with many development teams which depend on their architects for many decisions. The teams are unable to carve value in an independent fashion. This is what is meant by developer-architect Bondage. This isn’t in the best interest of the organization in the long term. It is better for teams to collectively tackle complexity so that an organization keeps hiring talent that could handle complexity. Otherwise, the organization reaches a pyramid where the top of a pyramid is filled by architects who can deal with complexity while most of the rest is pretty mediocre. This, in my opinion, is undesirable.
The advent of cloud computing has brought many benefits. Enterprises across the world are making innovations very rapidly. Concerns such as security, failovers, and scalability, which used to be taken for granted when everything was deployed in a secured data center, have now become concerns for any application. Many of the cloud providers support rich architectural guidelines & practices. As technology is getting democratized across the cloud, so is the architecture. Emergent patterns are supported by many of the providers are leading to widely-shared architectural best practices. Many of what was concerned with distinct architecture themes are now very much part of the mainstream. To deliver on the cloud, it is better for a developer to be architecture-savvy. Designing for failure and designing to be secure is no longer an option but a requirement. It’s better to have these baked into all of the development and have the entire team educated on these perspectives. This for me is another big reason why a separate role needs to go away.
When I say architect is dead, what I really mean is the death of this title and individual ownership of architecture. This should instead be a shared concern across the organization. Teams would deal with better engineering titles like staff engineers, principal engineers who are part of the development teams and forming focus groups than having a disconnected architecture team. Long live architecture!

Continue reading...