How a Solution Architect thinks — Part 1, working with requirements

Understanding Solution Architecture When I was a developer who was writing source code days and nights, I had one understanding of Architecture and what Solution Architects do when they design systems

September 29, 2026· 10 min read· 13 views

Understanding Solution Architecture

When I was a developer who was writing source code days and nights, I had one understanding of Architecture and what Solution Architects do when they design systems. It was about designing the source code according to some patterns and best approaches, searching for new components, and the changes in the existing components. But my approach was too developer-like, without considering business needs, requirements, and goals. After many years of being a Solution Architect, I look back and smile at my approach at that time.

Moreover, whenever I meet developers, they are interested in Solution Architecture in my company. I always explain it shortly and effectively, but I need more in most cases. I need more time, some use cases handy, and a good example I can use to reveal details of concepts, ideas, and approaches. It is the main reason I am writing this article — I want to give something that those who want to become architects will use as their first reference and step in a beautiful journey of Solution Architecture.

The best way to understand is to take an example.

There is no better way to understand something than taking a task and showing how some abstract requirements can transform into a solution that will satisfy the business’s needs and goals. I will use an Architecture Kata way to cover everything that solution architects usually do when they design software systems. If you are still getting familiar with Architecture Katas' ideas, I recommend you check https://www.architecturalkatas.com and try it yourself.

Disclaimer: Please remember that my article covers a top of an iceberg, and Solution Architects work on many other aspects at different project stages. I have plans to illustrate them in my future writings, but this one is just a high-level flow that most Solution Architects follow when they design a new system.

Let’s say that we get a Request For a Proposal from business representatives, and they want the following:

A new medical startup is eager to develop a patient monitoring system. The business aims to create an innovative patient vital sign monitoring system that measures ECG, heart rate, temperature, SPO2, and blood pressure.

The system is about to be a complex solution for three categories of users: patients, nurses, and doctors. Each user needs to have a monitor to see the data.
For patients, it is needed a Patient monitor that displays the vital signs of this patient; for Nurse — Nurse’s monitor that displays information about several patients in a single view; for a Doctor — a Doctor’s monitor that has a list of his patients with the ability to select any of them and see patient’s vital signs.
The company’s main advantage is to provide the system at a minimal cost because of using wireless equipment for measurements. Also, the company won’t develop its hardware but will support integration with the existing measurement hardware of several vendors.

As Solution Architects, we should work on the task and guide our stakeholders. Architects must satisfy business needs and goals and key stakeholders’ requirements. Just imagine if someone from the business invests money and makes some promises to the whole company that the investment will bring value. How critical will it be for us architects to meet their requirements and goals?

How Solution Architects use business context

We, as people, have goals. Some want a higher salary, some get motivation in new job opportunities, and others want to become famous — in all these cases, people translate it into goals. If you have a goal, you will find a way to achieve it. Nothing will change in your life if you do not have a goal. I do not want to sound like a motivation coach; I want to show that companies and businesses have their goals. Business wants to get many things in the future: better sales, acquire new customers, open new markets, meet future laws and government restrictions, etc. In addition, I want to add that any healthy organization must have goals. It is the first step to the end if an organization does not have them.

Note: When we get a task in the format of Kata, there is always ample space for the unknown and uncertainty. If it is an authentic Kata way, we can use the assumptions approach, where we build the list of guesses/assumptions and make decisions around it. But here in my article, I presume we can talk to Business Representatives and other stakeholders and ask questions and get answers.

We should understand as much context as possible when working on a solution. By context, I mean the following concepts:

Business drivers and business goals
Business model
Some constraints: it can be technical or business type

Here are the first questions I asked the business representatives and their answers:

Press enter or click to view image in full size

If we take a closer look at our Medical Startup project and process answers from business representatives, we will find out the following business goals and drivers:

Press enter or click to view image in full size

And there are constraints that we could identify after talking to the business:

Press enter or click to view image in full size

How do Solution Architects analyze requirements?

Press enter or click to view image in full size

System Context View for the Medical Startup solution

I always recommend building a Context View somewhere in the beginning because it helps Solution Architects to understand and what is more important visualize a requested business need.

Considering the project's size and the complexity of the requirements, I will use the C4 model. Sometimes it is hard to choose what to use to model your solution, and it is one more thing for my future articles.

At the starting point, we have the following vision:

We have a Medical Organization that will use our solution to collect data from medical devices and to display all needed statistics and data for our end users
Every Medical Organization can have the following roles: Doctor, Nurse, and Patient. Each of them will have monitors to view their data.
Our solution will be working for several medical organizations and, from a high-level point of view, must support the following features: ingesting data from medical devices, processing and analyzing data, and providing API for all end-user roles

We also raised a couple of questions (they are mentioned in the previous section), and we know that:

Almost every medical organization will have the existing data and existing systems: in most cases, it will be CRM (Customer-Relationship Management), EHR (Electronic Health Record), and Identity Provider systems. We must leverage this capability as much as we can
We will have hardware providers for medical devices, and there is no need to work on the hardware part in the scope of our solution.
There is an existing Azure AD subscription that the business wants to get an advantage from it as much as possible.

Since we have a point of contact (remember what I mentioned at the beginning of this article) that can answer our questions, here is a table showing what I asked about functional requirements and what kind of answers I got:

Press enter or click to view image in full size

The first set of questions for the business

In any case, not all functional requirements are essential for the architecture. Some of the requirements we can implement with almost any style or set of patterns, but others will require some additional effort for the architects. There is a name for such requirements — Architecture Significant Requirements. Long story short, ASRs (Architecture Significant Requirements) potentially lead to critical architecture decisions. After analyzing all initial needs and requirements provided by stakeholders, here is the list of ASRs:

Press enter or click to view image in full size

ASRs

Please keep in mind that most of the functional requirements do not make any critical impact on the architecture. We can implement functional epic/user stories with any architecture. Usually, what is crucial for the architecture are Architecture Characteristics (Quality Attributes) and Non-Functional Requirements.

How Solution Architects identify critical Quality Attributes (or Architecture Characteristics)

Many different architectural styles and patterns are available these days, with many options for computing, database, caching, and other solution components. We can bring to life business needs with almost any of them, and functional parts will be covered and work according to the business requirements. The question is how well it will work. How scalable, secured, and available will be our solution? And does it meet business needs?

There are a lot of definitions for things like scalability, availability, performance, reliability, etc. Still, I will use the Quality Attributes term because it is used in my company more than others (although I favor Architecture Characteristics naming). I do not want to list all Quality Attributes usually considered by architects because you can find them by yourself (for example, this link is pretty good for that — https://syndicode.com/blog/12-software-architecture-quality-attributes). I would instead give a couple of ways that can help identify important Quality Attributes for the solution:

Business goals have hidden important system qualities and characteristics in most cases.
Discovery process, where architects talk to businesses and identify Non-Functional Requirements, prioritize them, and extract critical Quality Attributes. For example, you can use the Quality Attributes Workshop format or Stakeholders interview. I will explain the difference between all possible options in my future articles. In the current post, I assume all stakeholders are unavailable simultaneously, and I have to send my questions to get their answers.
A business domain also means that some Quality Attributes (Architecture Characteristics) will be super critical for the system. For example, if we work with the Medical and Insurance domain, the Security of Data will be on the list without any questions.

Let’s tackle the first part with business goals and try to understand if we can identify something meaningful for the business and the final solution. “Create an innovative patient vital sign monitoring system that measures ECG, heart rate, temperature, SPO2, and blood pressure.” does not have anything about the number of users, amount of data, regions, and planned availability, but if we go into the nutshell of the solution, we will realize that we have medical devices and most probably thousands of patients with sensors that will be sending signals almost every second. Eventually, it will mean that our solution must be able to process a massive amount of incoming data, save it and use it for future analysis. To summarize everything, the solution must have Scalability and Elasticity characteristics in place.

As well as for functional requirements, we can talk to the business, ask questions about Non-Functional Requirements, and get answers that will help us identify important system Quality Attributes.

Press enter or click to view image in full size

Summary of the first part

After analyzing the business context, and functional requirements, identifying Architecture Significant Requirements, getting Non-Functional Requirements, and understanding critical for the system Quality Attributes, we have the following:

User roles:

Press enter or click to view image in full size