kontakt@guidiconsulting.pl
 +48 606 911 700

How to became a solution architect: lessons learned from clients and candidates

Dear all, I would like – before start this article- ask forgiveness in advance to all IT architect, developer and in general IT professional who will read it for the simplicity and the limited technical competence of the undersigned, anyway I was inspired from many IT professional I had the pleasure and great honour to talk with during last year. I learned a lot from my clients and candidates about a specific environment that for me is still a magic world still to be discovered, so any of your comments, suggestions, corrections will be more than welcome.

So, my first believe is that many solution architects, come from a developer background. I want to be very clear that what I am not saying is that a solution architects are better than developers – that would be palpably untrue- However, rightly or wrongly, in many workplaces the role of solution architect is more highly valued (and paid) than that of a developer. 

Even if that’s not true in your workplace, adding solution architecting to developer skills can be an excellent way to expand your role, and increase your value to current and future employers. Plus, with the increasing move into Cloud solutions, many of IT architects believe that there will be greater need of solution architects and far less need of traditional developer/programmers, due to the very nature of how cloud solutions are structured.

During my interviews with architects it’s happen I asked “how do you know if being a solution architect would suit you?”  My thoughts about architect as professional is essentially a job where you are called on to design something where the whole is greater than the sum of its parts. This is not some high-level design, it is a terribly intricate and detailed blueprint. If as a child you enjoyed puzzles, Lego, mechano, or simulation games like Sim City then solution architecting might appeal to you.

In the beginning of my journey with recruiting architects, I tried to used my previous engineering experience to focus on the role. The main question to myself was: “what does a solution architect do?” I find comparing solution architect vs developer to architect vs builder is helpful in understanding the solution architect role. In designing a building an architect considers many aspects (such as the land to be built on, plumbing, electrical connections, government regulations and most importantly the desires and budget of the owners); the builder implements the architect’s design. But an architect does not simply create blueprints and then walk away; often the architect returns to review progress, and to resolve problems and deal with changes caused by real-life issues that could not have been foreseen when the original design was made. In the same way solution architects design how one or more software solutions will fit with their IT environment to meet business requirements; the majority of the developments will be done by developers; while the solution architect is often called on to shepherd the solution to completion.

My assumption – for somebody probably obvious- often as a developer you are limited to working on just a few small pieces of the overall IT puzzle. As a solution architect, you are expected to design all or large parts of that IT puzzle, and have a greater influence over how the whole IT solution comes together….and…coordinate people, the whole project and keep the team focus and motivated. Simple. Well…not at all I guess, this is one of the reasons why not only technical knowledge can make a junior or semi-senior a great architect. Experience, problems solved, solution implemented, fails and ability to find the best way for your IT environment make the difference from a potential architect and the real one.

Looking back to the pool of professional I had the pleasure to place into the role and discussed with I had the presumption to prepare a list of some top skills that must be part of the cultural and professional background of an architect:

The first skill relates to how you direct your solution learning. Solution architects generally work across a suite of interrelated solutions. The general idea here for most solutions is to direct your learning to be “wide and deep” like a salesperson you need to know a little about a lot of solutions. The more solutions you understand the more possibilities you can discuss and recommend as part of your design.

Practice the art of simplification: a major part of the solution architect’s role is not just to create a design but to socialize that design with a range of different audiences – Senior Executive Managers, Project Managers, Subject Matter Experts, Change Managers, other Solution Architects, Developers and even the End Users themselves. All of these groups have very different perspectives and information needs: you must be able to communicate effectively with all of them.

Get great at writing down: what mostly of senior architect I spoke with, they have been told me: if you don’t record your design don’t be surprised if it doesn’t get followed. It’s physically impossible to be everywhere you would need to be explaining your design to all the different audiences that need to understand it during implementation. 

Play well with others!!! Solution architecting is not a solo role – you can’t just work out a design, hand it over and walk away. The major part of the job involves working with others – listening to needs and concerns, discussing pros and cons of options, cross checking your design with others where it moves outside of your deep skill areas, cross checking how your design will work in concert with other parts of the overall solution, and communicating your design to many different audiences.

Last but not least, a great mantra I learned from the most “seasoned” professionals: as solution architect, you see a lot of mistakes that other people have made: don’t laugh, don’t criticize. Just be observant, be grateful for the heads-up, and if at all possible, learn from the mistakes of others, because it’s so much less painful than learning from your own.

That’s all. Hope you will enjoy my contribution especially if you are considering to move up your career toward an architectural role.

back