Back to Basics: How to Become an (Solution) Architect

Several years ago, I was given the opportunity to serve as a Solution Architect. Since then, I have often been asked how to become an architect.

A Google Search (yes, this one still exists, as an AI Agent isn’t required for every query… 😁) results in at least 10 subject experts, 20 different answers, 30 different roadmaps, and a multitude of confusion…

In this article I’ll try to explain this role from my own experience. So, here we go!

When I started in IT I always looked up to the Architect and thought: “one day I’ll be just like him/her.” Yes, those kinds of dreams also exist…. In the years I worked as a Junior Consultant I always thought that those who would qualify to become an Architect were the ones with the most prolific Techno-Functional (read: hard) skills: the fastest Programmer, the most tech-savvy Web Developer, the slick BI Analyst, and so on.

Boy… did I get it wrong!

The road to becoming a Solution Architect is not a bed of roses. It is full of holes, thorns, obstacles, and if you’re lucky you may meet an occasional rose. I’ve gone through all of these:

• Sleepless nights
• Unthankful assignments
• The occasional pad on the back (=the beforementioned rose. Although I’ve trained myself to not await those)
• Unsatisfied, unwilling stakeholders
• Managers with a lack of vision (I formulated this diplomatically…)
• Trying to keep up with Best Practices, Technologies, Industry developments, ….
• Project flops, or what some would like to call ‘project scars’
• Botched presentations and unflattering demo’s
• Continuous Education aka The Neverending Story
• And so on…

So, if someone tells you that you can get an Architect-level certification and than you’ve become an Architect: They are wrong. A certification alone does NOT make you an architect. Or at least not a good one per se. Believe it or not but becoming a ‘true’ Architect requires far more than hard skills. And I am still learning those other skills, everyday! Well, if it is not about those cool hard skills, what is it about, you may ask?

The Architecture Role is a People Manager role. It is all about convincing the people involved. This is especially the case for Enterprise -and Business Architects. To be able to convince people, you need a combination of soft skills alongside the hard skills:

• Communication better known as Stakeholder Management: You need to be able to communicate effectively with actors across all layers throughout an organization. From the janitor mopping the floor, and the colleague from the Support Team, all the way up to the Board. You need to be able to determine which tone to use under which circumstances. Also, the level of detail is important. In some cases, if you present too much information, you’ve lost the audience. In other circumstances, offering limited information may be perceived as a lack of preparation. It could also be seen as an insult. Stakeholder Management involves a lot of politics. Thus, be prepared! If you are allergic for politics, the Architecture role is not for you.
• Industry Understanding: You will not be able to convince (Upper) Management if you cannot speak their language. In other words: they will not listen if they get the impression that you don’t understand the business they are in. So, if your running projects for a car manufacturer make sure you know what is happening in the Automative Industry. If you run a project for a Telecom Provider, make sure you are on top of what is happening in the Telecom Industry. Don’t hold a presentation in front of IKEA’s Stakeholders if you don’t know what is happening in the Retail Industry. Industry-specific knowledge is the only way that you will be able to provide a meaningful perspective. Alternatively, you will be equipped to offer valuable insights and constructive feedback.
• Business Language: Another way to make sure no one listens to you, is by being ignorant of basic Business terms. Get a basic understanding of Business terminology if you want to be heard. There is nothing more annoying for a Business Leader than if they are in a meeting with ‘technology nerds,’ who do not know what a Business Process entails…. Understand the basics of Enterprise and- Business Architecture, Business Process Management, and so on. A Business Analyses course in combination with a foundational Enterprise/Business Architecture course can get you up to speed quickly.
• Financial Literacy: When you submit a proposal, most often it is the Financial Decision-Makers who have the last say, as these actors determine what is possible (or impossible) from a budgetary standpoint. Most often these actors are not Technology experts, but on a high level they are aware of the potential benefits modern technology can offer. The challenge for aspiring Architects is the translation of the Techno-Functional story to one they understand: the (Financial) Business Case. If you lack these skills, I recommend learning the basics. Eventually it will be beneficial for both you and the other parties involved.
• Project Management: About this one I can be brief. I think it makes sense that you have basic Project Management skills, as you are the person leading the project from an Architectural standpoint. Namely, as an Architect you have a big say in Architectural decision-making. The overall governance is usually delegated to a dedicated Project Manager, Account Manager, or Delivery Executive. Also equally important is Time Management skills. Especially with fixed-price projects, exceeding the agreed lead time is seen as a major sin.

Why NOT to merge the Architecture Role with an Operational Role

Over the years I’ve seen many organizations make the ‘mistake’ of merging the Architecture role with an operational role such as Lead Developer. This combination proofed to cause problems. An Architect has a Governance function and operates on a (semi-)Strategic / Tactical level and must therefore continuously look at the bigger picture during project execution. This actor needs to make sure that Developer activities are aligned to stakeholder expectations. If you merge the Architecture and Developer role, the actor tends to dive deep into the practical details: there is always a bug to fix, a feature to add, a functionality to improve, and so on. Therefore, this actor will lose oversight of the bigger picture. In some projects this can have dire (financial and reputational) consequences. Therefore, I strongly recommend keeping these roles separate.

Resources to Become an Architect

Now the magic question may arise: What resources can be consulted to gain the necessary Architectural skills? There is not a perfect answer for this question. I personally gained (some of) these skills through a combination of on-the-job training (work experience) and formal education. Did I mention that I’m still learning…? One thing to remember as an Architect: it is a never-ending learning journey. You will need to develop a continuous growth mindset. If you are not that type of person, then maybe this role is not for you.

But to answer the question, here are my recommended learning resources:

• Communication -and Presentation Techniques and Stakeholder Management: There are plenty of online courses to tap into. Just do a Google Search.
• Industry Understanding: Many industries have their own qualifications and corresponding certifications. If you work for an IT Service Provider, they usually offer in-house training for the industries they serve.
• Business Language: There is a plethora of resources available on this front. I would suggest starting of with a basic Business Analyses course on Udemy, for example. Once you’ve gained more knowledge and experience you can investigate basic Enterprise Architecture courses such as TOGAF Foundation and move upward from this point. Enterprise Architecture helps you to put all the pieces together from a helicopter point of view. As an Architect this is especially important. If you aspire to become a ‘dedicated’ Enterprise Architect, I suggest a formal education. Usually this takes 1 to 2 academic years. Also, most of these programmes require a Bachelor degree to qualify for entrance into the programme.
• Financial Literacy: I would suggest a course like ‘Financial Management for IT Professionals’ as a starting point. Google it, and check if there are any courses that fit your needs. The skills gained in this course will be good enough to build a convincing image towards financial stakeholders.
• Project Management: When it comes to project management there is an uncountable number of resources. I personally prefer the PMI Disciplined Agile approach, due to its ‘toolkit’ nature. In other words, it offers a toolkit that can be immediately applied and does not prescribe a certain Way of Working. Therefore, it is applicable to any situation, project, and industry. But feel free to pick any Project Management framework that fits your needs. Just remember that the framework you choose will be depended on the environments in which you operate. And with this I’m opening the door to another topic for another time (in a different format😉): Organization Science.

For now, this is it! It’s been a while since I wrote my last blog article. I will try to write a blog every now and then. But I’m not promising anything. Until the next time!