Everyone these days speaks of becoming an IT Architect, what exams should I take to become one? and they are confused, “the architect roles that I’m being interviewed for, don’t do exactly what I expected”.
There is a trend that organizations and/or customers are starting with a digital transformation journey, which is the evolution of traditional business and processes to the next level – to the public cloud. So, the cloud or innovation teams start with an architect. But, which type of architect is the right one, and who would be the right candidate for the identified position?
In this article, I would like to share with you what I’ve seen, discuss the different architect roles, and how to become an IT architect if you decide to take that path.
Table of Contents
Introduction
I’ve been working as an architect for a Microsoft partner in Switzerland for many years. During that time I have interacted with dozens of architects, in many different companies, in several verticals and countries.
I have fulfilled “architect” roles on many different projects. I have mentored several aspiring architects, some of whom had very successful careers with “architect” titles. I’ve seen all the frameworks and models come and go.
In IT, most of the architects I know started as engineers or consultants (some years ago), and becoming an architect is a natural career path by taking more and more responsibility and leadership.
The title “architect” in IT is very much in the eye of the beholder. It is not like “steam train driver” or “brain surgeon” which are probably fairly well-defined roles. It can mean different things in the IT industry, changing from one organization to the next one. You can have two “architects” in one company that do totally different jobs.
What Type of Architect Are You?
Usually, the architect is someone who creates a design for a solution before it gets implemented. The architect is usually the person who has to gather the requirements, identify the priorities, evaluate the technical options, recommend a solution, recommend an implementation plan, point out the dependencies, etc.
However, this is not always the case!
In some organizations, the architect is a glorified technician, very hands-on, sort of the escalation level above the most senior tier of admins or consultants.
In some organizations, the architects are very removed from the technical work – they will have meetings, write design documents and draw diagrams, but never touch any software except Office, Visio, Project, and/or Azure Boards in Azure DevOps.
In some organizations, the architect is a type of project manager. There are infrastructure architects who can’t write (or even read) one line of code, and there are application architects who are more “lead developers”. Some architects manage teams of people, including non-architects, while others sit in a quiet room and work solo most of the time.
Some architects are very involved in understanding the business context for the technology, working with business decision-makers, calculating Return on Investment (ROI), contributing to budgets, and other financial tasks; other architects feel it is beneath them to care about money.
Some architects are networking experts, some architects can’t consistently tell the difference between an IP address and a telephone number. Some architects live and breathe security, some believe security is somebody else’s problem.
Some architects are focused on one technology or one aspect of solutions – there are application, security, network, server, cloud, and data architects, and many other flavors as well. And many other architects are great generalists, able to integrate applications, infrastructure, networks, platforms, security, etc. across heterogeneous environments using multiple vendors.
Some architects will only create a general architectural framework for an organization but do not get involved in the implementation, others will create detailed technical designs for a specific solution and then disengage, and other architects will remain involved and guide a technical implementation of the project to completion, and even more, they go to the extra mile and support the operation teams for managed customers.
Oh, and by the way, there are also types of architects who build buildings. Architects who design entire buildings bring usually a university background rather than hands-on experience.
Bottom line: There is no single type of “architect”.
How Do You Become an IT Architect?
So, how do you become an IT architect?
My best advice: You don’t choose the architect life, the architect life chooses you.
There’s no four-step set of exams that will get you from “beginner” to “architect” in a year or five.
Yes, you can study architectural topics, and you can get certifications with “architect” in the name, such as the Open Group Architecture Framework (TOGAF).
Or more vendor-specific certifications, such as Azure Solutions Architect or Microsoft Cybersecurity Architect.
These certifications will possibly and probably be useful, but they’re not going to guarantee you a successful career as an architect.
What you probably do need to do, is to think about what you do, as you’re going through the “building and fixing things” years of your career. Try to understand the “why?”, not just the “how?” Think about the alternative approaches to solving a requirement, and why you might have selected one or the other.
In fact, think about “what real requirement is this solution fulfilling for the organization?” as opposed to “I like working on this technology, my mastery of it makes me feel good.” You need to start trying to identify risks of what can go wrong, and how to minimize those risks.
Start to answer the question “If this thing I am building had to be built in such a way that people who are not me, and have fewer skills than me, have to successfully build, administer and use this thing, how can I design and build it to make it easier for them to do their jobs successfully?”.
Try to understand the role and value of documentation, and build your skills of writing down or drawing what you are planning to build. Embrace the value of planning and writing concepts before doing.
Get good at explaining things to people, in such a way that they will buy into your plan for how to do things; these people you convince must not just be juniors in awe of your technical wizardry, they must also be non-technical managers who will sign off on the budget to let you do the technical stuff.
Get used to dealing with people who say “no, you can’t do the thing you want to do”; learn that you can’t just storm out; get good at picking yourself up off the floor, refining your ideas, and going back to say “OK, what if we try it another way?” Keep building your technical knowledge, but try not to laser-focus on one narrow field – think about adjacent technologies, alternatives, dependencies, and impact.
If you’re passionate about infrastructure, investigate application development; if you’re a developer, understand the Infrastructure your applications depend on.
And if networking is your thing, understand the workloads that connect to those networks; everyone needs to understand some security; everyone needs to understand some data…
Do you want to know more about architects? Have a look at iasaglobal.org, which is an association for all IT Architects.
To Conclude
In IT, the architect needs to have a bird’s-eye view of one scenario, while in the other situation, the architect already needs to dive deep into the problem area. Sometimes being an architect in IT can be tough! What architects do is a mystery to many, as the work is intangible – not always directly measurable as a lot happens in the background.
You do all these things, and one day you will realize that you’re spending more time planning things that are going to happen, than doing things that are already happening.
When you’re spending time thinking about topics such as requirements, risk, efficiency, integration, business case, ROI, transition, maturity, and roadmap… and you’re spending more time in Word, PowerPoint, Project, Azure Boards, and Visio than PowerShell or Visual Studio… then you will realize that you’re probably an architect.
Becoming an architect isn’t just a natural career progression. That’s just about it.
Let me know your thoughts in the comment section below.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
