The Death of the Architect

"God is Dead and Man is free" is a prophetic saying of German philosopher Friedrich Nietzsche. This was a milestone statement in the history of human consciousness. The very belief in God implies an all-powerful creator and reduces human to mere puppets. Death of God meant the death of mental slavery and freedom for the human mind to explore in a totally independent manner.

In the context of information technology, I would like to make a bold new statement: "Architects are Dead and Developers are free." I know that this could bring many raised eyebrows and conflicts. However, there are many places where they have already eliminated the title "architect."

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.

Role of the Architect: Lack of Clarity

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:

• Product Manager - Often considered the CEO of the product and is responsible for the strategy, roadmap, and feature definition for that product or product line.

• Scrum Master - Facilitates for an agile development team.

• Business Analyst - Analyzes an organization or business domain and documents its business or processes or systems, assessing the business model or its integration with technology.

• Software Development Manager - Manages development projects from initial design through testing while providing strategic management direction.

Processes like Agile, make a bold statement as to the "best architectures, requirements, and designs emerge from self-organizing teams." Most of these roles have clear-cut responsibilities and augments the agile processes very well. However, architecture, as well as some other roles, are in contention from the very start.

There are umpteen definitions of an architect which makes an easy description of the role very difficult. Some of the examples are:

• A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.

• An enterprise architect is a practitioner of enterprise architecture, an enterprise strategic management discipline that operates within organizations.^[1]

• A solution architect, in information technology, is a practitioner of solution architecture. Typically part of the solution development team, the solution architect translates requirements created by functional analysts into the architecture for that solution and describing it through architecture and design artifacts.

• A domain architect is a specialist responsible for the architecture solution for that domain.

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.

Ivory Tower: Architecture

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:

• Attending meetings frequently and never being available;
• Treating developers with disdain;
• Producing multiple artifacts with little concern about whether they add any value;
• Finding faults on the development team around issues which don’t add much business value;
• Creating a culture of fear and unworthiness, rather than building a culture of creativity and appreciation; and,
• Describing things in a very complex and incomprehensible fashion.

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.

Developer-Architect Bondage

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.

Architecture Democratized

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.

Conclusion

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!

Image Courtesy:

https://bartholomusings.wordpress.com/2015/04/16/god-is-dead-what-nietzsche-meant/