Disclaimer: this is the service company's perspective. It may differ from an architect in a product company (say, Stripe).
Gathering Requirements
Solution Architect does a lot in a day to day job. The first thing to do is gathering requirements.
Requirements are described well-enough here. However, there is nothing on how the Solution architect gathers those requirements. Let's fill this gap now.
Should you create a new feature in the existing system, or create a new system from scratch you have to gather requirements. But imagine you skipped this part. You designed and implemented a system which fails to fulfill say a security requirement. The system doesn't pass the security audit and the customer has to pay the same price to do the whole work from scratch. Your company is fired, and you may be too. So, the architect's responsibility is to gather the requirements. The source of those requirements are primarily stakeholders.
Working with Stakeholders
Stakeholders are the people who have some interest in the project. For example, there is always a project sponsor, also known as the person who gives money for the development. If the project fails, sponsor loses money, and nobody likes that. The other example of the stakeholder is an end user. This person waits for the software, and expects it to be fast, usable and useful. Or maybe a developer is a stakeholder: this person will be implementing the project impacting their growth and future compensation rise.
An architect should distinguish the stakeholders according to their impact and project interest. People with high impact and high interest require close monitoring, i.e. end users. Project sponsors, being low interest and high power, have the ability to influence the project overall, you need to keep them informed. You also need to communicate regularly with high interest/low impact stakeholders like team members. The last group with both low power and low interest should be observed, as they can demotivate the project team and impact the delivery.
So, working with stakeholders is another job responsibility of an architect.
System Design
Once we have requirements, constraints and assumptions the architect can start with the system design. It's far from just drawing rectangles and arrows: it's a separate discipline on applying design tactics to different requirements for different parts of the system.
The most important thing to know is that there are no good or bad architectures; there are architectures with a better choice of tradeoffs for a particular solution. It comes from the fact the requirements conflict between each other. Say, the security requirement will force you to encrypt the traffic decreasing performance etc. So the architect's job is to balance the trade-offs so that they become the most beneficial for the business task.
It's rare the architect does this job alone. Particular parts of the system would require deep expertise; chances are the architect do not own it. It this cases the architect should involve technology experts to help with this job.
Once the design is done, it should be estimated. The business would like to know if the project is worth the implementation. Imagine a business wants to launch a rocket to Mars for the tourism, and understands the money will be returned in 3,5 centuries. Obviously, the business will wait for better technologies.
Communication
The system design should be communicated to stakeholders. Would be strange the designed system would be kept on the architect's computer and not shown to anyone, right?
The architect will be presenting the design: in particular how it should work in general, which assumptions were made and how much will it cost to implement. The architect defends the solution, why it's optimal for a given set of requirements. The stakeholders obviously will challenge the solution from the time and cost perspectives, and the architect should defend the solution or agree to adapt it.
Once the design is approved, the architect should communicate it to the teams: web, mobile, backend, data engineers and so on. Obviously other architects take place in those communications.
Documentation
Once the architect finishes designing the solution it should be properly documented. Luckily enough there is already a couple of articles I wrote on the topic.
Aside from Context, Container and Deployment diagrams(or any others which happen to be useful), the architect documents the decisions. System design doesn't happen in one go: there is a sequence of decision made by the architect. Those decisions happen in some technical and business context and should be properly written down. The main value of those records is not what exactly what decided, but rather why it was decided that way. For example, the architect may say we are not going to use RabbitMQ, we pick Kafka instead. It scales better and it's critical for our case.
I bet in half a year some engineer will challenge this decision and you will be happy the decision is documented. You will be able to understand if the context remains the same and the decision is still valid or not.
There is a set of tools for it, you can read more about them here.
Providing Guidelines
Ok, the application is being built. The developers write code, review it and deploy. However, they are not necessarily have all the requirements in their context. Therefore, some of the requirements can be failed to fulfill by the system, especially closer to the end of the project. Everybody wants to avoid that, but it's architect's responsibility to assure the fact. It happens through the guidelines on how to build new services, which quality gates to set up, what tools to use for measurements etc. For example, the architect should be sure there is performance testing in place to ensure the performance requirements. Or there should be some security analyzers in the pipeline to meet security requirements etc.
Launching to Production
The project should go live. Once the time comes architect is there to be sure all the requirements are met, the documentation is ready and the software operates normally in production environment. At this point the software either continues it's development in the same team, or can be transitioned to the customer or another vendor. Architect helps with knowledge transfer.
Staying on the technology edge
Short story here. Imagine you go 10 years in the past and start telling everybody to have their backends split into microservices and make them separate deployable units. Everybody would say you were crazy: how on Earth you would do that? How you would monitor everything? Where would you get so many system administrators?
Today we rarely build solutions without containers, microservices, constant monitoring and so on. The responsibility of an architect is to stay on top of the new technologies, evaluate them and decide if any of those are useful on the project. Architect may write Proof of Concepts using new technologies to do that. This also helps not to go too far from the code.
Don't forget to smile alright! 🤩
Also, if you liked the article, don't forget to Subscribe to get notified once a new article is published. Sharing the article in your social networks are always welcome as well.