When starting to write this article, I first asked myself, “What exactly is a Software Architect?”
Think about traditional Architects, the ones who design the buildings. There are many similarities between them. Imagine the software like a house: there are the rooms (the modules/features), the foundations (the infrastructure), the water pipes and the electrical cables (the frameworks and the tools), the fence or a wall around the house (the security aspect), the way to access the street (the integration).
Is the house next to a river (or a legacy system… or a Data Lake 😂)? An Architect needs to consider this before designing and sizing the foundations. Maybe one day there will be the need to add a floor with new rooms. Are the foundations going to support that? Will it be possible to quickly bring electricity and water to these rooms without impacting the ones already in place? Are there “private” rooms in which only specific users (or family members) can enter?
That’s why it is essential to have an excellent Architect on board. The Architect is most likely not the one who will physically build the building but is the one that is going to consider all these aspects before the works start. They should be present also during changes and renovations that, especially in the software world, are constantly happening.
So, which kind of (software) Architect are you or want to become? Sometimes the differences between them are not so easy to understand.
You have probably heard of:
- Enterprise Architect
- Solution Architect
- Technical Architect
Enterprise Architects are more focused on the strategy and have the most comprehensive view of the organization landscape as a whole.
Technical Architects have more of a hands-on approach and are closer to the technical implementation; generally, they specialize in one Technology or technical domain.
Solution Architects are somewhere in the middle, and they bridge the gap between the two. They actively find solutions for the specific business challenges and negotiate the involved parties’ needs. Ultimately, the main difference between them is the scope and the level of detail they look at the problem.
Do we always need all these three figures? Depending on the organization’s size and complexity (or of the specific project), one or more roles can be “merged” and assigned to the same person. Sometimes the scope is considerable and requires, for example, more solution Architects or technical Architects (perhaps one per domain). It really depends.
When coming to Salesforce, the thing seems to get a bit more complicated because they introduced their own names and definitions. Looking at the different Architect certification paths (https://trailhead.salesforce.com/en/credentials/architectoverview/ ) you can find:
- Certified Technical Architect
- Application Architect
- System Architect
- Data Architect
- Integration Architect
Note: Keep in mind that the meaning of this article is not to advise you on how to prepare for a particular Salesforce certification not either on your Salesforce career path to follow. The intent is to help you portray your professional story as a Salesforce Architect and highlight some important things the company might ask during the interviews.
In the very end, also in the Salesforce case, the difference between them is the level of detail in which they look at the problem.
On the other hand, what do these figures have in common? When you are an Enterprise, a Solution, or a Technical Architect (or all of them!), these two things should always be there:
- Love and enthusiasm for Technology, and in this case for Salesforce;
- Excellent communication skills: whether you are a team lead or more an individual contributor, the way you portray and deliver your idea is always crucial;
In this article, we will try to collect the elements that, in our experience, are essential to consider while preparing for an interview as Salesforce Architect, perhaps focusing a bit more on the solution and technical ones.
Create your story.
In which of the Architects do you better identify yourself? Or do you want to address your career?
You can also shape your story based on the dream job you are applying for. In this case, the job description can be a bit misleading. For example, many of them are published as “Salesforce Solution Architect” or “Salesforce Technical Architect”, but it doesn’t mean they are necessarily referring to certified people or a Solution Architect as per Salesforce definition. Maybe it would be more precise to say that they are looking for a software solution Architect, with expertise in Salesforce.
So that’s very important to go through the job description and understand what exactly they are looking for.
techmeout.io can help you with that!
TIP: Use the “Manage Resumes” tool to clone or create a new version of your resume and try to tailor it to the position you are applying for;
TIP: Use the “Job Analyser” tool, link it to the job description page, and check what’s the most used keywords. It can give you great insights!
Start with a nice introduction about yourself, focusing on your last or most relevant experience, bringing examples, facts, and measurable figures to the table when possible.
Here you can find some inspirations on how to create your story focused on what’s in our experience is important to highlight as a Salesforce Architect in your resume or during the interview.
You know the Platform.
Referring to the example of the house, the Foundations are provided by Salesforce, but that doesn’t mean it is not your problem. In fact, Salesforce solves many initial challenges and helps you to get up and running in a very short time, but it comes with limitations and constraints. For example, you cannot perform synchronous web service calls from a trigger context, or the number of records returned by a query is limited. Show your customers that you are aware of these limitations, and that you can design your application around them (for example, using asynchronous patterns or leveraging external ETL tools). Also, try to mention some success stories around Lighting, or migration to Lighting.
(Positive) Critical Thinking.
Most of the time, customers love the fact that the Architect is able to look at the problem from multiple points of view, especially if they are different from the Salesforce Success Team’s recommendations.
Imagine that the project is about integrating Salesforce with an existing enterprise ecosystem. Most of the time, the Salesforce Success Team will come up with a whole design, including several products from the Salesforce catalog (like Marketing Cloud, Mulesoft, Einstein Analytics, etc.). That’s great, and perhaps you want to introduce all of them one day.
But the customers probably don’t want to replace their marketing or DWH solution (or maybe not immediately) and intend to integrate Salesforce with what they have today.
Also, the solutions proposed by Salesforce are not exactly the cheapest ones. Depending on the budget, you might also suggest 3rd party ones. A good Architect should be able to make the solution comply with Salesforce standards and Best Practices, even when integrated with products outside of the Salesforce “catalog”.
Show your customer that you are keen to explore all the options, ask questions, and show that you want to understand the values and the business context before jumping into the solution.
Integration is your thing.
Salesforce offers many out-of-the-box features that can solve many business challenges but sometimes are not enough. So you can decide to customize the platform with custom logic, or you can choose to integrate with a 3rd party service that does it for you. Also, most likely, you will need to integrate Salesforce with your customers’ external systems (and with itself!). Think about a success story like that during your career and highlight which integration patterns (sync or async remote invocations, batch synchronization, data virtualization, etc.) you have used, the challenges you faced, and how you fixed them. Did you leverage any paradigm (like orchestration or choreography, for example)?
It is also very important to consider how the end-users perceive the integrations and how secure they are. Do you have experience with SSO or 2FA?
You respect Data.
Data is always one of the most crucial aspects of software design, also no exception for Salesforce.
As Architect, you should be familiar with the tools that Salesforce offers to manage data (roles, profiles, sharing rules, etc.) and how to visualize it (reports, dashboard, etc.) also leveraging tools (Tableau, Power BI, etc.)
Show your customer that you know how to deal with data Architecture and data governance. For example, can you think about success stories around GDPR or creating a privacy-first data model?
Also, it is essential to make data available where it is needed but also make an effort to keep it in the right system, trying to avoid unnecessary synchronizations and trying to apply modern integration patterns (i.e., Data Virtualization). This would reduce technical complexity, legal concerns and ideally keep costs down!
Customizations, Code, and DevOps
Yes, most of the time Salesforce needs to be customized to meet the business needs. It offers many tools and, as you might know, apex code is one of them. It could be powerful to show that you are familiar with the main Apex patterns and frameworks and that you know how to version and move changes between Sandboxes and Production and keep them under control. Ideally, with some CI/CD tool connected to your PM tool. Not only technically but also following a robust development process (including pull requests review, peer code review, etc.).
These are just examples of how to create a story as a Salesforce Architect trying to focus on the aspect that makes this platform unique and powerful. Can you think of other things that helped you to become the Salesforce Architect you are today? Don’t forget to add them to your resume or mention them during the interview.
TIP: techmeout.io can help you write your career highlights based on your Technology and role. Try it out by selecting “Salesforce Architect”.
Good Luck!
