5 things to deal with, as a new Software Architect!

I was promoted to a Software Architect role in 2018 and have spent some time reflecting on my journey of transition into this role. It has become evident that meaningful architecture is an act of continuous trade-offs while making timely design decisions. The definition I quoted in my previous article, “What does it take to be an architect?“, is actually making more sense now.

Meaningful architecture is a living, vibrant process of deliberation, design, & decision, not just documentation.

This journey emphasized that designing an application is a process of executing prompt solutions by identifying and solving the “real” customer problem. The reason I highlighted the word “real” is, that the problem surfaced and discussed may not be the real underlying issue. We have to systematically extract, define the problem, and then design the solution.

It was overwhelming and confusing in the beginning. I felt that there is no tangible output to the work I did as an architect. I constantly looked for quick wins and morale boosters. I also got easily discouraged when things didn’t go as planned. I learned that this is all normal and expected part of the transition. Talking to my peers and my manager about how I felt and frequently checking-in with them helped me overcome that state quickly.

Throughout the journey, a few of my design decisions went through and got successfully implemented; Some had to be revised along the way as we learned newer constraints. As I compare and contrast those experiences, here are few takeaways:

Dealing with communication

Proactive and effective communication is a required quality to be successful in this role. Ensuring that the key stakeholders are informed at all times reduces the stress and unnecessary chaos at the workplace. Providing a central location for all the required documentation and keeping it up to date helped in keeping all the stakeholders on the same page. The ability to understand other’s perspectives and addressing their concerns first helped me to make decisions efficiently.

Dealing with ambiguity

We have to work very closely with the product team to gather the requirements. It requires a lot of analysis to understand the real problem at hand. Most times, the actual problem is hidden under the factual requirements provided.

For instance, there was once a business requirement to increase the max length allowed for a text field that persists value into the database. One customer complained that the value was getting truncated when saving it. The team came up with a very large effort which would take up 3 to 4 sprints to fix since it is a very extensive change. When we took a step back and asked the question — “Why only for this customer?”, the answer highlighted the real underlying issue of the application. The customer was using the text field to store additional information that it was not intended to accept. We were able to fix the underlying issue and train the customer accordingly. This helped us solve the “real” customer problem and also make the application more robust.

While we work on ambiguous problems, it is imperative to proactively identify and mitigate any risks before they turn into roadblocks. Vetting my thought process with my peers helped me learn ways to navigate around ambiguity and gain clarity.

Dealing with negotiations

If you are pitching a new technology choice as a solution idea, there will be push back, mostly due to fear of change or lack of sufficient information. It is essential to push through your idea until you find valid reasons to change it. We must present our ideas confidently and back it up evidence from outside resources if required. Knowledge and familiarity will improve confidence. Creating a POC often helps to present the idea effectively.

Dealing with design

You may end up designing a new project from scratch or extend an application by adding new features. The success of any given project depends on how clearly we can envision the end product from the beginning. Design thinking involves thinking backward — start from the end and break it down to the required steps to reach there. It is an iterative process that involves understanding the end-user, redefining the problem, and finding the right approach to solve the problem. We may have to challenge some preset assumptions sometimes, to get to the right level of understanding. The customer must be involved through all the steps, so we can adjust and course-correct as needed to meet their needs.

Dealing with trade-offs

Our goal is to design and build reliable, cost-effective, and scalable solutions. Solving the customer’s problem is the key and technology choice is only a medium to get to that solution. Our focus should be on the problem and to understand the real issue that we are trying to address. If we focus merely on technology, we will end up building the wrong product; if we choose the right tool and fail to leverage its strengths, we will not be able to solve the real customer problem. We have several tradeoffs to consider when weighing the solution options. At times, releasing to market with minimal features is the right approach. Even if the solution is not complete, it may help resolve some roadblocks to implement future features.

For instance, we wanted to provide stable and effective search functionality to get to the required guidelines/content easily. We choose to build a central search service and use Elastic search as a backend to store the search metadata. Elastic search can provide the most capabilities we wanted right out of the box. Although we did not update or extend our applications to leverage those capabilities. On the other hand, we added a lot more complexity to the new search service in order to support the existing as-is capabilities. The outcome — yes we have a great technology that centralized the search functionality and helped streamline the release process. The “real” customer problem is still being resolved as we continue to build “Smart Search” into our applications.

For every problem, there is one ideal solution and several compromised solutions. Especially, If you are a long time employee of the company, you may be already knowledgeable about the existing constraints and bottlenecks and tend to design the solution around those constraints. Take every opportunity to start with an ideal solution and make adjustments as needed. This helps us make informed decisions when cutting corners or making few compromises to meet the market needs.

Another important aspect of the design is to be able to choose the right tool for the job. With endless open-source projects available it is very important to be familiar (not necessarily fluent) in all technologies and stacks that can be evaluated.

Parting thoughts

In conclusion, I learned a lot more in the past 2 years which definitely is helping me grow as a technologist and a thought leader. The valuable lessons came in the form of a few failures which taught me how to take a step back and redefine the problem from the customer’s perspective. They taught me that it is ok to ask for help and when you do, together we will create wonders. The most critical takeaway is to spend more time on understanding and defining the problem. If the problem is clear, the implemented solutions can seldom go wrong.

A well-executed solution that solved a real customer problem, in our case, enables clinicians to provide the right level of care and thereby help save lives.

I believe transitioning to any new role is intriguing in the beginning, but, transitioning to a software architect role is slightly more challenging, primarily because it requires us to expand our horizons and build the ability to envision the end product even before it is built. As a filmmaker by hobby, I think an architect can be compared to the director of a movie who will see the movie in the head even before planning the shots. One day, I hope to become Steven Spielberg or James Cameron in the software world. The journey continues on…