Refactoring the architect's role

The autonomy that comes with microservices is very attractive to our customers. Sometimes it starts to become a double-edged sword of sorts. They realize that the power of autonomy comes with a great responsibility for the development teams and the organization in general. The need for a technical ear that hears as many designs as possible arises. Traditionally, that leads to architectural oversight. Then they gather a bunch of senior engineers and call them architects.

Things start to get worse because nobody can really figure out what the right level of oversight is. The group gets viewed as an “Ivory tower” that’s always busy in meetings when needed. Now, they have moved smart engineers from coding to meetings, anarchy is breeding, and nobody is happy. What’s going on here? What can we do?

I decided to think about this problem, similar to code smells. A code smell is a property of source code that shows a deeper problem than what you see at the surface level. It was coined by Kent Beck and got its fame with the Refactoring book by Martin Fowler. These smells do not make the code technically incorrect, but they make the problems a lot more subtle. For example, duplicated code still works, but you may just forget to update it everywhere and cause issues. The smells make the system inefficient. It can get very annoying to work these as they start contributing to technical debt.

Smells in the architect's role

Misunderstanding of what architecture is

Some of the ubiquitous signs of this smell are bad documentation, a constant need for meetings, and teams coming for rubber stamps from the architects. If someone comes to you and says, “I am supposed to talk to you, so I am talking to you.” that is a sign. So what is it? Is it pictures? Is it fancy documentation? Is it a big pie in the sky? It needs to have sequence diagrams, yeah? What about interactions? Where is my ideal picture? Does is it capture critical decisions? Did it involve business input? Does it capture one or more failure scenarios?

So many questions here. When there is no company-wide accepted definition of architecture, it creates mass confusion and nobody is productive. It feeds into almost every problem we are going to look at in this post.

Misconceptions about the role

Is an architect a superstar engineer? Many engineers think of architecture as their next step in their career, and they just jump in. Sometimes, the org thinks of them as scientists or magicians, etc. They are likely to get disappointed. In reality, architects are neither. It is a very specialized role. Good architects are capable of and do code from time to time. They are also able to elevate their vision from a tree to a forest, which is not everyone’s strong point or desire. Identifying and addressing common issues across the teams is not an easy task.

As a result, this role, at times, struggles to meet the expectations of the occupants and the leadership. It is perfectly fine to have area expertise such as distributed systems or SPA development, etc. It is unrealistic to expect everyone to know everything at all times. Not playing to people’s strong points only leads to more dysfunction and a lack of satisfaction in the role. It doesn’t make things productive.

Ineffective communication

Architecture involves a lot of interactions with people across the board in an enterprise. They should be able to talk to business leaders with zero technical knowledge as well as the immensely talented engineers working on features. Sometimes people find their comfort zone and sit there instead of building interfaces and bridges.

It is essential to make sure the company's overall strategy is well understood in the development group. It is equally critical for the C level management to hear the pain development has to go through to deliver the software. Failure in either form of communication usually is detrimental.

Lack of empathy

It has ties into the misunderstanding of the architect’s role. Architecture is not the next step in a career for a great engineer. With that, some architects don’t come across as peers. It unnecessarily creates contentiousness. It is important to stay humble enough to know that you may not have a complete picture of things. The questions asked from curiosity sound different than trolling ones. It is crucial to meet people where they are.

I can give an example from my recent experience. I am not a rule follower per se. It is unfathomable to me that sometimes people need rules. I have to consciously keep this in mind to meet them where they are.

It is vital to show an inspirational action than just demanding people to follow. For example, show your own presentation or documentation to set expectations instead of only finding faults in everyone else’s.

When these types of things don't happen, the ivory tower feeling only festers.

Unproductive working culture

Meetings Meetings Meetings! Some companies love their meetings. Everything turns into a two or more hour meeting or a working group session. It is very inefficient and expensive. They are hardly productive, and very rarely people come out of working group sessions energized. Sometimes people are too bought into the ceremonies instead of thinking of their effectiveness and changing them accordingly. You don’t have to have a 3-hour sprint planning meeting to be agile. It gets challenging. Slapping a bandaid on problems is not always the right idea. Some managers force teams to work this way. Eventually, it comes back to haunt them. It is essential to know when to address the underlying problem vs. slapping a bandaid on it. In this case, the problem is more deeply rooted than just architecture.

Premature solutioning

Who doesn’t like to develop the coolest algorithm to show off their Computer Science knowledge? Many times simplifying the problem is a lot cheaper than the fancy solution. Sometimes the business doesn’t even care about brilliant solutions. All of these arise from a lack of analysis of the problem domain. I have seen engineers working on a library but couldn’t tell why one needs their library. This results in wasted time and money. Having a clear definition of what needs to be solved along with business drive priority is very important before we think of how to solve a particular problem.

Failure to look beyond the obvious

It is an extension of premature solutions. The development teams could be addressing just a symptom of a more significant problem. The mighty Mayans ended up altering their local environment because of extreme farming. That resulted in extended droughts. Lack of resources made them even more susceptible to superstitions, self-sabotage, and vigorous infighting which eventually led them to their downfall. A more in-depth analysis was required to think about this.

I am sure you can find plenty of instances like this. Recently, a team of developers found that an HTTP endpoint was highly utilized by multiple services. It was getting called millions of times in a week. The development team could have optimized this endpoint to return results faster. That would be addressing the symptom. Upon further analysis, they found that the data doesn’t change much during the day. This could be easily cached at the caller’s end. The source could just raise an event when it changes and the destinations could bust the cache at their end with the latest value.

It is sometimes hard for dev teams to address this. Sometimes you are just too close to a problem or too far in the weeds to lift yourself to think properly. I have been there, and I have asked an outside eye to take a look to make sure I am not running in circles. This is one of the most significant responsibilities of an architect. A deviation from it can render teams very ineffective.

In the next post, we will take a look at addressing these problems.