Solutions Architect. Personal Vision.

Who exactly is a solutions architect? Intuitively, everyone has their own definition. In most cases these definitions are incomplete and depend on what a given project requires. When I talk to project managers, technical leaders, software developers, clients, or business analysts, it looks like an architect as a one-man band. Someone whose expertise, experience, flexibility, and responsibility can be used to patch all holes in a project, both those related to processes and those resulting from lack of competence or communication problems.

Each project is different and in each of them responsibilities of solutions architects may be distributed differently. Sometimes an architect works together with a team, often providing a code. Sometimes it is a high-level work related to architectural concepts and defining a path that a project is to follow in the field of technology. In fact, architects’ involvement is a product of their character, their team’s needs, and project definitions.

Different visions of a solutions architect are perfectly justified, and it is difficult to bring them to a common denominator. However, architects can help themselves and a project if they are aware of certain aspects of their work.

Technological clairvoyant

Architects usually focus on the project current challenges; they solve unsolvable problems and plan future operations. They should not, however, forget about business technological challenges and they cannot lose sight of what is about to happen. This is of course very difficult, because it is hard to predict how a given technology will develop, how changes to a project itself will evolve, or, most importantly, what technology to use.

Usually, it is a team that chooses technology. With the help of specialists in MVC application, we will not execute a difficult project in serverless technologies. And even if it is technically possible, we can’t guarantee that we will deliver a working solution. Naturally, it may turn out that a client will impose technology; should this be the case, an architect’s role is to make a client aware of the consequences of such a choice.

“More difficult” doesn’t mean “better”. Architects must be aware of an environment they work in, clients’ requirements, and above all, of what their top priorities are: is it delivering the MVP, providing fantastic quality, or maybe brilliant architecture? An architect’s job is to decide whether a project should be executed right away or maybe its execution should take a bit more time, with the assumption that the latter will eventually pay off.

How to do it?

• Understand the business context. Cooperate with a client, business analyst, project manager, product owner, UX etc. In other words, work with anyone who can provide a perspective of a client’s needs. These needs will often affect the choice of technology and even the architecture.
• Help put a team together (if it is possible).
• Meet team members, talk to them about their experience. In case of projects in progress, ask for their opinion on the selected technology. Sometimes it may turn out that a team’s skills do not allow it to work effectively. If so, take some actions. For instance, suggest a change of technology or try to improve your team’s competences in a given area. Both solutions are difficult, but the worst thing is to do nothing.
• Fail fast. If architects can test some ideas themselves to confirm them in practice, that’s fantastic. But it is also a great move to involve team members in such tests. This is how a team’s competence related to a specific technology develops.
• Predict what may go wrong or where you or your team lack knowledge or belief you are going the right way.

Soft leader

Most architects will probably be surprised now… An architect as a leader? A leader? Why? A solutions architect’s job is to design, not to manage people. But you are half-right.

Of course, it is easy to imagine architects being only an authority on technology. However, such architects will not have it easy. Perhaps they will have to work with other architects, software developers with extensive experience or technical leads with their own vision. Perhaps there will be too many seniors per square meter in a team.

Architects’ vision will only work if they have natural authority. Of course, they discuss their ideas with their team, but they also want to win others over if their visions are controversial. Sometimes they should be uncompromising and bossy to achieve their goals. They often have to tell their team members that they are wrong and must not be reluctant. To do so, they need highly developed soft skills and conciliation approach. They have to be able to listen carefully to other team members, notice their needs, and fulfil their ambitions. Only then is it possible to make a considerable change (e.g. to decide authoritatively) without damaging consequences.

Nothing that architects intend to do will work if they do not pay attention to reliable communication, fact-based arguments, explaining their own perspective, or conversation. I have seen a lot of conflicts in teams caused by an architect that was too domineering and did not pay attention to the fact that team members had their own visions and ambitions. This almost always leads to a communication disaster, or, when the worst comes to the worst, to employees, including the best ones, leaving a project or even a company.

Architects don’t like it, but it is a project “must-have”. Not only should they be technological visionaries, but also soft leaders, communication masters, experts in listening to team members, geniuses in manoeuvring between different, often clashing visions.

Yes, it is difficult. But nobody said it would be easy.

How to do it?

• Talk, talk, talk. This may seem like a waste of time, but it is not. Authority cannot be established based on making the right decisions. To prove the rightness of one’s decisions, time is needed, and authority must be established way ahead.
• If something goes wrong, say it. Never pretend that nothing is happening. Remember that when it comes to technology you are the highest authority.
• Recognize the needs and ambitions of team members. Maybe someone can help you with what you feel is your responsibility. For you it is a responsibility, but for someone else it may be an ennoblement.
• If you think something needs to be changed, do it. Of course, you should agree it with others, talk to a client, a team, a project manager. But do not hesitate to take actions as failure to make a change — assuming that a problem has been correctly diagnosed — may have far-reaching consequences.
• Clearly show the purpose. It is a bad sign if a team sees nothing but problems. So take a step back, turn problems into challenges, help your team formulate the MVP (if possible) and find the right path.

Thick-skinned visionary

A project is an area where various interests meet. Reality can be harsh when a client has a slightly different point of view than a project manager, a technical leader, or a developer. Architects should wise up to it and act like a peacemaker between business and technology. They have to consider different perspectives, make it easier to share them and help find a solution.

Each of us has participated in many discussions about software quality. We all would like to do it the right way: follow all good practices, run tests, adhere to design patterns, etc. However, it is not always possible, as the client’s strictly business perspective holds us back. “Business perspective” usually means “as soon as possible” or “as inexpensive as possible”. The reasons behind this approach may differ as sometimes it is a desire to enter the market quickly, sometimes it is limited budget. We should understand it. After all, it is the clients’ money, their business, and they know best what their limits are.

These divergent perspectives usually lead to micro-conflicts that architects should be able to manage. Technical leaders and developers sometimes complain that they do not have time to run tests. Project managers may be worry about the code quality, but they feel pushed by their clients. Clients ask architects for the best solutions and they do not want to hear about obstacles. Architects are often caught between the devil and the deep blue sea and so it is better if they are thick-skinned and pursue their goals regardless of the resistance of matter.

It takes a bit of visionary. Do you remember how Prince Radziwiłł, a figure from “The Deluge”, a historical novel by Henryk Sienkiewicz, explained his betrayal and the signing of the treaty with the king of Sweden? Well, his plan was simple: Poland will surrender to Sweden, Karl Gustav will place Radziwiłł on the throne of Poland, then then Prince will rebuild the Republic and expel the Swedes. Regardless of whether these were Radziwiłł’s true intentions (truth be told, they were not), it may be a lesson for architects: they sometimes have to sacrifice one thing to gain the other. If the MVP allows the client to earn money, it must be delivered on time and its quality may be improved later.

All this requires the ability to manoeuvre between a team’s natural tendency to provide a high-quality solution, for which there may not be enough time at a given moment, and the necessity to provide a working solution. All software developers dream of executing their next project exactly as planned but such dreams rarely come true. Architects will sometimes have to face criticism from all sides, but they should have a far-reaching perspective in mind and must not sacrifice it for short-term benefits.

How to do it?

• If providing some solution in the shortest possible time is the most important thing for your clients, talk openly about the consequences, i.e. about the resulting technical debt that will have to be handled.
• Modify the architecture vision based on the business context. Show the clients what and how they can achieve by using different approaches.
• Make a long-term plan. For example, if you think that the best option is to migrate to the cloud, but it is currently not feasible due to short-term benefits for your clients, think about it ahead. Prepare at least an outline of the concept on how to do it and present it to your clients. It doesn’t have to be a perfect plan. It doesn’t have to be a strict plan at all. It can be for instance a high-level concept of a final solution. It might be imperfect or incomplete, but at least it will show some direction.
• If your team has to take a short cut, make sure that it doesn’t become the norm. And remember that dealing with a technical debt is usually not a one-time operation, but a slow, tedious process. Make the team aware that the boy scout rule applies to everyone. This is, of course, the primary responsibility of technical leaders, but it doesn’t mean that architects should not support them.

Responsible support

We sometimes say that responsibilities must be precisely divided in a project. For example, a person responsible for a release should be appointed. We agree not only who will lend their name to a release but also who will physically do the job and check the effects. In the end, it is the entire team that bears responsible for the project success.

But you know what? From the technological point of view, clients and project managers primarily deal with solutions architects. If we realize it, we will quickly notice that despite precisely formulated RACI matrix, the main responsibility for processes in the project and for the project as such rests with architects. They may try to take the burden off their shoulders, but it will only work until the first failure. Then only an architect will be responsible both for this failure and further work. It is always easier to find one scapegoat.

Therefore, architects should take an attitude of responsible support. They don’t cut themselves off from the problems of team members, they support them not only in task performance, but also in technological development. They notice the team’s weaknesses, identify potential threats, and try to eliminate them. In other words, architects perform risk analysis on an ongoing basis in the context of technology and cooperation between team members. If necessary, they go beyond the scope of their responsibilities. Therefore, they do not ignore potential or existing problems.

As it was said , whatever the RACI matrix shows, architects are responsible for technological success of the project.

How to do it?

• I will say it again — talk, talk, talk. Effective team communication will help you a lot.
• Support team members in their own self-development. Naturally, this support may take various forms, but the better your teammates are at doing their job, the easier it will be for you to pursue your vision of architecture (naturally, in line with the client’s needs).
• Don’t be afraid of challenges, not only for you but also for the team. Paradoxically, difficult tasks that make people learn willingly and develop for the sake of the project.

Team member

It sounds banally, but it is not such. Architects, due to the nature of their work, tend to distance themselves from their team’s everyday work. This is usually because they spend most of their time delivering high-level designs and having discussions with clients. And sometimes they simply have too little time to participate in a given project. Every so often their low participation in performing tasks with the team results from objective factors; if so, it is necessary to compromise.

If it is possible, work with your team. Integrate, take responsibility for low-level tasks, support your colleagues, share your knowledge. This is how authority is established. You may need it if one day you will have to act with conviction, or tell someone point-blank that they are doing a bad job, or make everyone listen to you carefully when you say that the team’s vision is leading the project astray and it needs to be immediately changed.

If a project is executed using the technology you are not familiar with, nothing is lost. The “hands-on” approach is not necessary, although your experience will definitely help solve the problem. It is, however, necessary to provide support, help with releases, understand the processes, and explain them. Sometimes an architect’s involvement in a project is part-time job and then working with a team is difficult, if not impossible. Too bad, that’s the way it goes. But this does not mean that in such a situation an architect is doomed to fail. In such a case, responsibilities will be distributed differently.

One-man band

All the-above mentioned aspects of architects’ work make their clients sleep well. Architects give them a sense of security and deal with all problems so that clients do not have to do research at night to make sure whether team-suggested solutions will work. They also do not have to worry that they will have to report to their CFOs, because AWS costs have grown astronomically. They have a sense of control, even if not all solutions have been delivered.

Architects’ life is not simple, and nobody has ever said it is. An architect is a lot like a one-man band, both in terms of hard and soft skills, which is extremely important. They should have extensive experience and know how to use it wise to successfully complete a project. And last but not least, architects should be aware of their own weaknesses, because humility will help them establish authority, win the team’s trust, and do what they have intended to do.

Originally published at https://www.pgs-soft.com.