So you want to be an architect, do you? At least, that is why I am guessing you came to this page! Well, you came to the right place! I have gone through this transition myself, and here are some topics I wanted to write about the role.
What is an architect?
But first things first, let us define what an architect is before we go any further.
We will not be designing buildings. If that is why you are here, you came to the wrong blog!
Let us first dig into the different types of architects. Do you look surprised? Yes, there are multiple types, each of which has a different role in this world.
Solution Architect
If we have to define a Solution Architect in a few sentences, it would be to evaluate all business requirements and develop the best solutions by proposing products and services. Solution Architects are given a business challenge/problem and are tasked with coming up with the answers to these questions.
Solution Architects keep a high-level overview of all the different systems and their capabilities to make the best decisions for a specific business question. After weighing all the pros and cons, they propose various possibilities to answer the question.
If we look at this role within Salesforce, solution architects understand all ( or a reasonable amount ) of Salesforce’s offerings to provide solutions using them. And, of course, if there is no product within the Salesforce ecosystem, look at third-party vendors to fill in the gaps.
Are you interested in B2C Solution Architecture? Then be sure to read the Salesforce B2C Solution Architect’s Handbook, authored by Mike King.
Enterprise Architect
A completely different type of architect than the Solution Architect. The main goal of an Enterprise Architect is to validate the solutions provided to the business and that they are aligned with the organisation’s strategy.
An Enterprise Architect has a top-level overview of the organisation regarding knowledge, capabilities, and potential.
I could write an elaborate article on this, but I will forward you an excellent article on Apex Hours.
Technical Architect
The final one in this list is the Technical Architect, the most specialised one. This type of architect will take a single part or implementation of the big puzzle and focus on that. They will focus on this domain and gain in-depth knowledge that the Enterprise and Solution Architect lacks.
If we look at the Technical Architect certification within Salesforce, these Architects have a deep knowledge of everything related to the Salesforce CRM system. They know the ins and outs of all the different cogs that make that system work – and make them work for them, which is not an easy feat!
To learn more about it, you can go to Trailhead.
Putting them together
If we look at the different architects listed above, it is clear that they work as a team to get “things done.” Each has its specialisation and stakeholders to get projects towards the finish line.
I am a Technical B2C Commerce Cloud Architect moving to a Salesforce B2C Solution Architect if I look at myself. I have specialised knowledge of B2C Commerce Cloud platform and a high-level understanding of different clouds within and outside the Salesforce domain.
Using that knowledge, I look at business cases to develop solutions using Salesforce products (or third-party solutions), mainly connecting them with Salesforce B2C Commerce Cloud.
The journey
But I am getting ahead of myself; how does everything change if you go from being a developer to an architect? Well, a lot will change!
Development
One of the most significant changes going from developer to architect (or any lead position for that matter) is that the amount of time a day you spend writing code will go down dramatically.
And that is something you need to prepare yourself for. You will handle the theoretical more and guide others to implement the practical.
Meetings
One of the reasons you will be doing less development is because you will be in many more meetings than before. You will be gathering requirements from a client, internal discussions about architecture, follow-up meetings to answer questions you still have and many more reasons to have meetings.
People will also contact you more with questions about decisions that have to be made and help support the team during development (without developing yourself).
Responsibility
Do not take the title ‘architect’ lightly. You will lay the groundwork for the projects in any of the different types. If this is not done correctly, things can go awry rather quickly.
It is the same with, and yes, I will compare with buildings, civil architecture. If the groundworks are shabby, the building will topple over sooner or later.
A large proportion of the success or failure of a project lies with the architect, so be prepared to shoulder it!
Make yourself heard
Get used to voicing your opinion toward your colleagues and your clients. Since you will be shouldering a large proportion of the responsibility, be sure that your views are heard and taken into account.
So, learn to be vocal and get used to talking to all types of people. You will be doing it a lot! And remember: it is OK to make mistakes, but take responsibility for them!
Documentation / Analysis
Instead of writing code, you will write text to support the team doing the implementation and the business.
Get used to writing a lot of documents and drawing diagrams! I decided to use Grammarly to help write English (as it is not my native language).
Don't reinvent the wheel
There is a lot of excellent documentation and help available on the web. Make use of it! If you have been in development for a long time, you might need some refreshers about diagramming and other things.
A good place to start is the Architect Help site of Salesforce!
In the end
The role of an architect is quite diverse if you consider the various “types”. However, it’s crucial to evaluate if you’re willing to make the necessary changes to your daily work routine.
If you have a passion for development and want to continue in that field, it might be best to delay pursuing a career as an architect for a few years. There is nothing wrong with growing within the developer role.
In the end, if every developer becomes an architect, there will be no one left to actually build anything.
