Who is the architect?
In a few words, a solution architect is a professional who specializes in designing and developing solutions to address the specific needs and challenges of stakeholders within an organization. They are responsible for understanding the requirements and objectives of various stakeholders and then formulating an architectural plan for the solution. The final output of an architect’s activities should be a new (or changed) architecture of the system.
Let’s imagine first a relationship between all these terms as a simple picture and explain in detail all its parts.
System architecture
System architecture refers to the conceptual structure and design of a complex system, defining its components, relationships, and interaction.
IMPORTANT: The architecture of a system is a fundamental property that is present whether or not it has been documented and understood.
Let’s explain a system architecture using a simple example:
EXAMPLE: Let’s imagine we have a bicycle. It contains wheels and a handlebar,
brakes and a seat, pedal, and gears. All this stuff is connected to a bicycle frame.
We can name all these things as “bicycle components”. When we pedal, they transfer the action through the gears to the wheels and they start spinning. When we push the brakes — they slow the wheels and the bicycle stops. We can name all this behavior as “interactions between bicycle components”.
Ok. An explanation of architecture using a bicycle looks like kissing training using tomatoes.
Let’s use some examples from the IT world:
EXAMPLE: We have a pet clinic web application. It consists of a user interface component (you can decide any of your favorite technologies here since it’s out of scope), backend service, and database — “pet clinic web application components”. A user interface sends HTTP requests to a backend service and retrieves HTTP responses from it. A back-end service saves the data into a database and retrieves the data from it. This can be called “interactions between pet clinic web application components”
In both cases, it doesn’t depend on whether we have an architecture description (a bicycle schema, or a web application technical design) — a system architecture is exist since the system itself is present.
The last (but not less) about the system architecture — is should cover stakeholders’ needs. But who these stakeholders are? Let’s take a look…
Stakeholders
Stakeholders are individuals, groups, or organizations that have an interest in a system we are implementing or extending. There are not only system users or customers included: people who are going to develop the system, who is going to test and deploy it, and people responsible for the security of the environment this system will work in — all of them are stakeholders of this system. Stakeholders are typically impacted by or can influence the outcomes, decisions, or success of the initiative. Stakeholders can be internal or external to the organization, and they often have different roles, perspectives, and levels of influence.
IMPORTANT: Goals and requirements of different groups of stakeholders may
be different and sometimes even may have conflicts and opposite views.
Our goal is to collect these goals and requirements, prioritize them with stakeholders and find tradeoffs for conflict cases.
Let’s move back to our examples and explain, what possible stakeholders may we have there:
EXAMPLE: We have a few people interested in a purchase of a bicycle:
The father — wants to buy a bicycle for his son.
The mother — wants to buy a bicycle for her son as well.
The son — wants a bicycle (and it’s the important part).
A bicycle seller — wants to sell a bicycle.
In the same way, let’s imagine possible stakeholders for a web application:
EXAMPLE: We have a few groups of people and organizations that are
interested in a pet clinic web application:
Individual patients — use the pet clinic application to request an encounter with a
doctor for their pets.
Pet doctors — use the pet clinic application to see their encounter schedule and
available slots.
Developers (SRE, testers, designers) — implement a feature of a pet clinic
application and support it in production
Pet shops — use pet clinic applications to place their advertising there.
As we can see the system may have a very group of stakeholders with their own use cases need and goals. And it seems reasonable that these groups of stakeholders may have different views about how the system looks like and these groups definitely will have different requirements for the system. Let’s take a look deeper into this topic in the next article.
Next: https://medium.com/@svosh2/functional-requirements-27345ea1fd19
