Making better Architectural decisions

Patterns in the streets of Berlin, Germany — Credits: @herrreiprich

How do you know which design pattern you have to choose for your new project? Is the good old monolith (layered architecture) the solution to all our problems? or what if we go with an event-driven architecture? Most of my friends are working with microservices, should I join them?

There is no specific path to become a Software Architect, that’s a fact, some people say it just grows in you after spending enough time (years) working as a Software Engineer and being exposed to software design scenarios. Then you realize how design patterns go well in some cases and in others fail … but why?

There are several factors that can influence you in the moment of making Software Architectural decisions, some of these factors are:

1. Business
2. Technical
3. Project
4. Professional

In this article, I will provide an overview of the above four factors, since Software Architects need to go the extra mile to fully understand why the stakeholders and influencers need what they say they need.

Influencers in Architecture — My artistic skills … drawing on Google Slides.

Understanding these four influencers will require you to gather all the project stakeholders and decision-makers in a room full of coffee and cookies. The result or output of these meetings should provide you with enough context and architectural characteristics to start designing solutions.

Business

The business plans and goals are an important factor to consider, we have to know what is the current business situation and where are we going (direction). Some of the things to consider when you talk to business stakeholders are:

• The funds. Do we have enough money to support the project?
• Business Strategy. Is there any important business need that we could have in the near future (three, six months)? This could be anything from going to different markets, expected growth in users or transactions due to partnerships, and so on.
• Future plans. Future integrations or business acquisition plans are important as well so we can design architectures to embrace the future. Imagine that a few months after you designed the architecture, the development team is almost done with the implementation, then you receive an email from the CEO with the good news! We have acquired XYZ startup which product will be used heavily as part of our offer. Wouldn’t it be great if we could prepare for this before?
• The industry. The business industry, the more we know about the specific industry the better. Nothing beats domain knowledge.

Technical

The technical influences are a collection of tools and practices that are constantly evolving and have an indirect impact on the project.

Back in 2005, I was starting my Computer Science Bachelor’s degree and we only had a couple of options to deploy our software applications, basically taking care of physical servers, manual set up and with love and care, we had to run our applications. Back in those days, Ruby on Rails was the new kid on the block and Facebook was testing a closed version of the Social Network on High-schools while hosting the web app on a server for 85 USD / month.

Nowadays we live in the Cloud era, we count on a variety of IAAS (Infrastructure as a Service) providers such as Amazon AWS, Digital Ocean, Microsoft Azure or Google Computing Engine, just to mention a few. Amazon leading the way since ± 2006 with the creation of elastic computing instances called EC2. You can forget about the whole process that we had to do in the past. No more racks and days in the cold server room of the office, because for some dollars per hour we can have an entire team of professionals in charge of our servers.

Here are some technical influencers that can affect our architectural design:

• Current patterns that can help us to solve problems. Design patterns are a must-have in our toolbox. However, there is a saying “Today’s best practices are tomorrow’s Anti-Patterns”. As Software Architects we need to understand that this is a natural side effect of progress in technology, every six months we have new tools and methodologies, chances are that in 12 months we could have a better solution for today’s specific problem.
• Technology changes every day. One of our goals as Architects is always to scan the horizon for new technologies, tools, and practices. We have to be comfortable doing the uncomfortable, judging when is the more appropriate time to incorporate new technology in our infrastructure.

Project

Projects differ from company to company, two companies from the same industry can be working on similar products or services but the stakeholder’s vision could be totally different, this represents to the Software Architect different characteristics that we need to inspect, evaluate and analyze the trade-offs between them.

• Beyond the hype. Most of the time, starting a new project comes with a lot of hype, emotions, and desire to create a successful product. However, an architect should be focus on gathering all the project requirements.
• Existing architectures and pieces of software. It is important to know if we will have to design a new system that works in cooperation with existing solutions. This leads to further discussion as different technologies, support, and available expertise for the current solutions.
• Time to market. What is the deadline to launch the project? This variable helps us to negotiate with stakeholders the different project attributes, simply put the trade-offs on the table and let them prioritize. A project can be designed and built in a totally different way if we have enough time and human talent to build it.

Professional

We make decisions based on our previous experience, this is why your education, background, and professional experience are important as well in designing architecture.

One of the best things we can do is to expose ourselves to scenarios where we have to make decisions based on the interviews with the stakeholders, the often the better.

Great, after having discussed the above influencers in architecture, it is time to finally answer the question …

How to make better architectural decisions?

You start making better and accurate architectural decisions when you take into consideration all the prioritized project characteristics collected in your business, technical and project meetings.

It sounds pretty simple, isn’t it? The reality is that this takes a lot of effort, time, and soft skills. Keep learning and practicing your skills.

Notice that I did not mention quality attributes and how to actually collect them. I will describe the process in a new post, if this post was helpful for you, feel free to share it or leave comments below, I would love to get feedback.