1 - Understand the problem
The first essential thing I want to mention right at the beginning is: Think problems first, then solutions!
Please don’t start thinking about technologies before you didn’t understand your customer’s problem precisely. Thinking in solutions from the start might guide you in the wrong direction.
Problems might seem the same from a first look; however, the solutions are always different in the end!
It would help if you always take your time to study the requirements in detail and be not afraid to ask and challenge the elements with the product owner or business analyst.
Since the solution architect is the binding element between the functional requirements and the technical solution, he must understand both sides to make the right decisions.
Better to ask one time “to often” than to continue without precise understanding!
If you don’t follow the advice, you might get into trouble in a later phase of the project since there were one or more crucial things you did not see or did not spend enough detail on it.
2 - Stay High-Level
The solution architect creates a high-level solution architecture that holistically considers all requirements; nevertheless, it describes the solution from a helicopter perspective.
Based on the solution architecture document, and the selected technologies, the lead developer creates a technical concept regarding the implementation.
There might be some cases where the solution architect might be the only one familiar with a chosen technology, and so he also needs to write the technical documentation. But this should happen for the minority of cases since the development team must do the implementation.
3 - Be Open For Feedback
Live is a continuous journey of gathering knowledge, and due to this fact, each individual can make mistakes. Moreover, no one can know everything. Therefore, the solution architect should be open to qualified feedback.
Feedback is a gift! (even it turns out later that the input wasn’t adequate)
It is always valuable to consider a second meaning, especially during the solution architecture documents’ review process. Two eyes see more than one, right?
A good example is, for instance, the feedback from the operations team. If they complain about the chosen technologies, this could turn out into a real problem, since those guys have to run the solution after development.
Besides, it could be a problem regarding implementation quality, if it turns out that the development team does not own the appropriate skills to realize the solution. In the best case, qualification training before the start of implementation is mitigation here.
4 - Stay Open-Minded
A solution architect is continuously scanning new technologies, methods, processes, and tools that could help him architect kick-ass solutions. Still, the new stuff must pay into problem-solving.
The inspiration comes, among others, from reading other architects’ blogs, studying best practice approaches, or try real-world examples of solutions based on new technologies.
Furthermore, attending conferences or workshops can enlarge one’s horizon, and sharing knowledge inside the company would be a fruitful option.
A solution architect must have a broad knowledge of different technologies. But he should have at least one specialization, something he is a real master, e.g., IoT, Cloud, Big Data, AI, etc.
5 - Feel and Take the Responsibility
The solution architect is responsible for not less than the success of the running solution. Sure, he does not code on its own or setups the production environment, but the product owner will blame him for missing the objectives in the end.
Consequently, the solution architect should take an eye on the quality of all the project’s concerns, and especially the solution’s matters.
6 - Eye for Quality
After handing over the reviewed solution architecture documents, the implementation by the development teams starts. Up from now, the solution architect must rely on the experience, knowledge, and leadership skills of the lead developer.
For example, the solution architect should monitor the progress and efficiency of the development team to support them proactively.
7 - Leader and Motivator
Part of the job of a solution architect is to guide, mentor, and challenge the development team. Especially with the lead developer, he should have a close relationship.
The lead developer is the one to work tightly with the developers, and his motivation and experience will directly impact the work of the entire team.
8 - Keep Agile, but also say: "No!"
During the implementation of the solution, there will come requests for changes. The solution architect must verify the claims and prove what kind of difference it might have on the current architecture or the ongoing development.
In case it turns out that there would be a need for an impacting transformation, he should take a clear position and evaluate potential negative results.
The solution architect is responsible for the entire solution! Due to this fact, he should not try to be everybody’s darling, since this is not realizable. It’s about the art of making compromises.
Summary
I won’t say that if you cannot cover all the aspects that you are not a good solution architect. Maybe I also forgot an element you would expect to be listed here.
But it should give you a brief overview of the experience I gained over many years of professional work as a solution architect, and from the view of a developer or lead developer.
Hope to see you again in the next chapter!
Photos on Unsplash
Top comments (0)