Over the last 12 years, I played role of solution architect on multiple projects. Here is summary of lessons I learned over the period.
Need for embracing ambiguity
As a developer, our demand for clear requirements is very logical. As an architect, it’s totally different story. For most of the projects, the requirements aren’t clear, partner systems aren’t ready, business analyst is in dual mind, and despite all this chaos you are expected to come up with a strong design. At start (especially if it is your first assignment as an architect) this becomes very frustrating, but as you start to live with this ambiguity your approach becomes adoptive. One key trap to avoid here is to build a design to satisfy imaginary future requirements.
Consistency in decision making with the help of guiding principles
Consistency will help you to quickly gain trust with team and customers. The guiding principles should be based on good practices, non-functional requirements, specific project needs etc. Note that principles should not be rigid but evolve over the period, and needs to be followed in the spirit (and not the text). As the team understands the reasoning behind your decisions and starts adopting the principles, bottleneck on you for every other decision will be reduced.
Some of the examples of guiding principles — “Lower memory footprint”, “Performance over data duplication”, or “No single point of failure”
Be there on shop floor
There is no point in being a visio architect, who keeps churning out fancy diagrams. As an architect, you must work with engineering teams, let them be involved in decision making. If possible, do pair programming with them to get first-hand experience of their challenges and how your own design is getting implemented.
Influencing without authority
Recently during a mentoring session, a senior developer told me that he doesn’t wants to be a manager because it involves lots of communication and interaction with others, but as an architect, he can work alone. This is a huge misconception. As an architect, one must learn to communicate and influence. As a manager, I don’t need to explain (most of the times) logic behind my decisions, I can simply dictate the things. But this is not a case with architect, you need to communicate to various stakeholders, understand each view point, influence developers/testers who don’t report to you.
On a lighter note, most difficult task as an architect is to convince developers and other parties to move to a better design from the current design, which you yourself has created few months (or days) back.
Thanks for reading, feel free to like, comment and share.
Top comments (0)