From Requirements to Software Architecture

Building software architecture the right way means using a strategic approach. Good architecture is invisible and easy to maintain. It will sometimes be restricted by the client’s budget and time limitations. But it will also evolve over time. This means that the starting architecture needs to accommodate change, so it will not necessarily be the final one.

The purpose of this article is to review the basics of solution architecture and how it can help the client’s needs. We will start by defining what solution architecture is and the steps needed to start translating the clients ideas into a proper software architecture.

Solution Architecture

Solution architecture is a practice to provide foundation for software development projects. It is achieved by tailoring IT solutions to specific business needs and defining their functional requirements and stages of implementation. It contains many subprocesses that provide guidance from various architecture viewpoints.

In solution architecture, the client needs are broadened into business needs that are ultimately related to technology.

You could also say that solution architecture translates technical business needs into practical IT solutions. At the same time it establishes rules or instructions for adequate implementation and delivery. It also considers all external factors that could have an impact on the development process.

Software architect responsibilities

The person in the role of Software Architect will have several main responsibilities when it comes to enabling the build of scalable solutions.

In general terms, when we see a good solution it’s because the Architect sat down and worked to understand the need and problem from a holistic perspective. This is particularly important provided that most problems have an impact on the business, but they can most frequently be presented as technical issues. That is why understanding the context of that problem to be solved is important for Architects BEFORE they adventure on creating a good solution.

Information lives in people. Therefore, the Architect’s role is to work with people to get that information out, even when those team members didn’t even know they had it. That is why being a good listener is a key part of the skill set. Another important skill is to be oriented to tracking. Not only do problems need to be persistently tracked, but also the reasons behind that problem, and the opportunity that comes from it. Finally, the architect needs to evaluate and communicate the business implications of a good solutions architecture, as many people that are non-technical could lack the insights regarding business impact.

To sum up, we could say that the four main responsibilities are:

• Making architectural decisions and solving problems
• Conceptualizing and analyzing the architecture (focusing on the “how”)
• Keeping an account of the latest software development trends
• Aligning expectations with reality in the present as well as for the future

The most important Soft skills needed are:

• Leadership — To oversee the development and coordination of different teams and projects to meet the needs.
• Problem-Solving & Conflict Resolution — Both technical and human.
• Communication — This is key. Communication has to be clear in terms of expectations and deadlines.
• Organization — A systematic way of thinking has to be meticulously documented in order to get everything organized.
• Prioritizing — Sometimes there’s a lot going on and prioritizing is not easy but very needed.
• Detailed Thinking — In any development project, there are a significant number of details that must be managed correctly. This requires extreme attention to detail to make sure the project code meets objectives.
• Creative Thinking — Sometimes alternative solutions are needed.

Requirements

When it comes to defining an architecture the first step is to review the requirements with the stakeholders. Trying to understand the clients’ needs, what they intend to build, and how to bring it to reality.

Most probably, the clients requirements will not be structured or technically oriented. It’s our responsibility to understand and organize them working alongside product, business analysts, designers, and other stakeholders.

Non-functional requirements are as important as functional requirements. Many times they are not identified (or taken into account) by the client. It’s our responsibility to identify and communicate those non-functional requirements and how we intend to include them in the roadmap.

The architect must provide a vision of the solution and how it will fulfil the requirements.

That vision needs to guide the rest of the team and the stakeholders. Therefore, while the team needs to believe that the result of their work will meet the requirements and will be successful, the product or business owner has to trust that the proposed solution will be a commercial success.

Making Definitions

There are two main definitions when it comes to software architecture and development. Team and Tech definitions. Personally, I believe that team definition is absolutely key, but once chosen both the team and the technologies, they will not be easy to change. So they should both be mindful decisions.

Team definition: Choosing the right team members from the start is key to achieving a good product. Involving every team member in decision making is important for them to understand the scope of the project and the objectives.

Having the right people will help the process in the short -and long- term and finding people that align with the values of what’s going to be built is very important.

Tech stack definition: The technology stack has to be defined based on the product being built. Some technologies might be interchangeable, but some are not. Development and maintenance costs might vary as well.

Here are the basic things to analyze before choosing technologies:

• What is the go-to-market strategy
• What is the platform for building an app
• What are the UX goals
• What are the load requirements
• What is the future scalability needed
• What is the availability and cost of engineering talent

Aligning with the business

Business and IT alignment is vital for market impact and growth. This tactic means as business goals pivot, IT can more readily respond with necessary solutions to support and maintain enterprise momentum.

It’s not easy to foresee what the business cycle will look like. Nevertheless it’s a good exercise when defining an architecture to work on roadmaps and desirable future-state features with the stakeholders.

Conclusion

A good software architect is responsible for ensuring that the architectural solution they provide is a commercial success as well as a technical success.

There’s no recipe for building a proper software architecture, but understanding the client’s present and future needs, choosing the right technologies and the right team is the base foundation for it.

To provide everyone with context and information, it will be key to set up a roadmap that can be shared both with the client’s stakeholders and the team, to be able to glimpse what the future looks like.

Gastón Kolocsar — Software Architect @ Spark Digital