Posted on February 3, 2021 in Career, Architects  

Guide to 5 Types of Salesforce Architects

Salesforce Architects are some of the most in-demand professionals in the Salesforce ecosystem. Using their expertise, they map the structure and function of your Salesforce solution – ensuring it remains functional, safe, and economical, as well as suitable for the specific needs of the business.

An Architect will create the overall shape, but the design of a system is about more than structure. It must be designed for the specific needs of the people who use it.

There are 5 possible types of Architects, which aren’t defined by job titles, but by responsibilities within a project. We could refer to them as “flavors” – as sets of responsibilities. A certified Architect will take up one of these remits, per project, but will be capable enough to be assigned to any role.

We spoke to someone with the answers: Gemma Blezard, Solution Architect and Founder @ The Architech Club and Ladies Be Architects. Let’s find out what she had to say.

“The point of this guide was to inspire conversation – a level of debate about where we, as Architects, fit into projects, how we add value, and what the career path looks like”

– Gemma Blezard.

Types of Salesforce Architects

If you’re not familiar with what Salesforce Architects do, you probably don’t know the differences between each type. Here’s an overview before we dive into each type individually:

• Solution Architect: Responsible for everything inside Salesforce.
• Technical Architect: Responsible for the data going into, and out from Salesforce and integrated systems.
• Data Architect: Responsible for defining and designing the data architecture in such a way that it is scalable.
• Enterprise Architect: Has oversight of all involved Architects. An all-encompassing role that includes the business.
• Transformation Architect: Responsible for defining the target operating model, skill sets, managing resources, governance and stakeholders.

You likely have more questions now, than when you started reading. What does a Technical Architect do differently to a Solution Architect? How do Enterprise Architects fit into the picture? Are all Architects necessary to work on a single project? We’ll be demystifying these questions, and more.

Solution Architect – a.k.a The Party Planner

Responsible for everything inside Salesforce. That means designing quality, scalable and performant solutions inside Salesforce, making sure it all fits together into a coherent and attractive solution.

They also prepare data for sending to other systems, and process data when it’s received from other systems.

They will oversee:

• Data modelling
• Data migration
• Data sharing
• Multi-component solutions*
• Salesforce configuration (and the consultants working on the configuration)
• Connected apps
• Declarative automation
• User experience (UX)
• Handoff to other systems
• Environment management
• Deployments
• Leading a team of consultants and / or administrators

*Multi-component solutions: we’ll see this term appear throughout this guide. In a Salesforce context, we define a multi-component solution as one that solves a business problem using several methods, with handoffs between them. Examples could include Sales Cloud → FinancialForce PSA, or an integration with Mulesoft → other integrated systems that give Mulesoft acknowledgement.

Technical Architect a.k.a. The Door Person

Responsible for data going into and out from Salesforce (both from and to integrated systems). That means they design how the system will act as the wider, single source of truth.

Like the Solution Architect, they will design multi-component solutions and prepare data for sending to other systems and process data when it’s received; unlike Solution Architects they have a particular focus on the security of data at rest and in transit. So they make sure the right data is on the right guestlist to keep your Salesforce solution safe.

They will oversee:

• Data modelling
• Data migration
• Multi-component solutions*
• Code inside Salesforce (including Apex, Visualforce, LWC)
• AppExchange Apps
• Designing APIs
• Secure messaging
• Guaranteed delivery of data
• Managing large data volumes (LDVs)
• Handoff from other systems to Salesforce
• Integration patterns
• DevOps strategy
• Leading a team of developers
• CI/CD
• Environment management
• Deployments

Salesforce Solution Architect vs. Technical Architect

Now that we have covered two Architect remits, let’s pause and reflect on the differences between Solution Architects and Technical Architects.

The two roles work closely together because they have common interests. Below you’ll find the main differences highlighted, in terms of where they focus with Salesforce (the multi-component solutions inside Salesforce), data going between systems, and user experience.

	Solution Architects	Technical Architects
Focus with Salesforce multi-component solutions.	Designing your ideal Salesforce concept (the configuration, code, sharing, data, identity, connected apps etc.)	Selecting the most appropriate technical components for your Salesforce (including coding quality, DevOps etc.)
Data between systems	Concerned with preparing and processing data to enter or leave Salesforce	Concerned with how data will flow between all integrated systems, not just Salesforce TAs have additional concerns with the security of data at rest and in transit
User experience	Focus on UX	Focus on how UX affects the flow of data, integrations and any bulk Apex jobs

Salesforce Data Architect – The DJ

Responsible for defining and designing the data architecture in such a way that it is scalable. If data were music then the Salesforce Data Architect would be the DJ selecting the right tunes to create the right atmosphere and build the momentum of the night.

Where a Data Architect is involved, they will own the data model, data migration, data quality, governance and backup strategy. They are concerned with the availability, reliability, integrity, security, structure and storage of data in complex environments. Digital transformations often involve pulling data from a variety of external sources and these databases may integrate with Salesforce directly, be managed via Apex jobs, or involve middleware, such as Mulesoft. While the TA concerns themselves with how data flows in and out of systems, the DA is interested in optimising the data as a whole, and how people interact with it.

As well as coming up with the strategies, activities, and sequences for their various accountabilities, the Data Architect will be relatively hands-on and usually executes this work themselves, often leading others.

They will oversee:

• Data modelling
• Data migration: activities, sequences, risks, transformations and dependencies
• Data quality, by identifying risks and strategising Extract-Transform-Load (ETL) activities
• Designing APIs
• Defining transformation rules
• Calling out risks and issues associated with large data volumes (LDVs)
• Managing data between external systems and middleware (eg. Mulesoft, where applicable)
• Backup strategy
• Leading a team of data analysts

A Salesforce Data Architect usually works closely with the Technical Architect. In some programs the TA will lead the Data Architect by:

• Directing the strategy of the data architecture
• Collaborating on optimising the system back-end to handle large volumes of data (LDVs).

The TA will also work with the Solution Architect as a close-knit design team – the Party Planner and DJ discussing and coordinating their designs.

Salesforce Enterprise Architect – The Club Manager

Responsible for having oversight of all the architects involved, an all-encompassing role that includes both the business and the client-side IT team. The Enterprise Architect oversees the whole design project, making sure that it is functional, safe, economical and suits the specific needs of the people who use it.

This means that the Enterprise Architect takes a comprehensive approach at all times when carrying out analysis, design, planning, and implementation to make sure everyone is in agreement and moving in the same direction.

They oversee:

• The target operating model (TOM)
• Change management
• Creating and refining the roadmap
• Strategic planning for Salesforce programs
• Managing the project backlog
• Support the business planning
• Assisting with resourcing
• Governance
• C-level engagement

In fact, the change management aspect is often first to get chopped off the statement of work when people want to get their project quotes down.

Gemma shared that the first person who shared their thoughts on the article, when it was originally published, was her previous boss and mentor (who’s a CTA). “I like that you’ve done the flavors. The transformation piece is interesting, where did that come from?”, he said. Gemma was quick to point out that, at The Architech Club, they see this aspect as fundamental, and want to give it a name because it often gets bundled away into ‘learning and people stuff’.

Transformation Architect a.k.a The Nightclub Owner

Responsible for executing the vision. The Transformation Architect controls the target operating model, roadmap, workstream planning, resources, skill sets, project governance and stakeholders.

Whilst the Enterprise Architect has a focus on the day to day functions of the project at hand, the Transformation Architect will look beyond the project to help you develop measures for its impact. They will help you maintain a focus on how you can best service your customers throughout your Salesforce project and keep the project aligned with your businesses longer term goals.

Which Architects Do You Need?

Ideally, all of them! The more Architects you have onboard, the more aspects of solution design are covered, and so, the better the project outcomes will be.

Realistically, you may not be able to afford all these Architects. Which Architects you need for a project will depend on what you’re implementing, for example, is it multi-cloud, multi-platform? Is there any innovation, are you building your own app that is perhaps going to be on top of the Salesforce platform? Whether it’s sold externally, or not?

“These are all big considerations that need certain skill sets to make sure those decisions are informed and optimized. For example, if you approached a Technical Architect and said, “what’s the best way for me to communicate this change to all of my salespeople?”, you might be met with a blank look because it is a different focus and a different skill set.”

– Gemma Blezard.

When you have more than one Architect they’ll collaborate as a team, often challenging each other to evolve their ideas. This means you get a solution design that has every aspect covered by an expert, working with their expert peers, and the outcome will be a fantastic party!

While you don’t need all five types of Architects, it’s also not necessarily limited to only five types. For example, Gemma has been assigned to projects as both a Solution Architect, briefly as a Data Architect, and also as a Change Management expert.

“These five types are our way of saying to the ecosystem – absolutely there is a career path for you, regardless of what your schtick is. For example, if you like building solutions and coordinating across Pardot and Salesforce, maybe solution Architect is your thing. If you like to advise and design how data is flying between multiple systems, in what sequence, and what transformations need to be done, then maybe integration is your thing.”

– Gemma Blezard.

Ultimately, responsibilities need to be bundled into these types because organizations, when they invest in consultancy services or are hiring talent in-house, want to know which ‘buckets’ put resources into. Not only where they fit into the organization, but also to enable them to budget accordingly.

While there are generalists who won’t like the sound of this (coming to the conclusion that they’re being ‘pigeonholed’), it’s necessary to transact business in the Salesforce ecosystem for those reasons above.

Evolution of the Salesforce Architect Role – a Turning Point?

Was it always the case that these were the five types of Architect roles, or was there a turning point in how the Architect role has expanded or bucketed into these definitions?

• Salesforce’s investment into their Architect program laid the foundation for a strong definition of Salesforce Architects.
• Gemma has witnessed the evolution of how the definition of the Salesforce Architect role went from IT-focused specialists, to roles for people who want to achieve seniority without going into the management team or becoming a project delivery manager.
• It’s okay to have specializations, you don’t have to know everything. The ‘5 types of Architects’ is designed to be a way to show you what’s available once you get into the Architect arena.

Gemma Blezard:

I think there has been a turning point.

Investment from Salesforce in their Architect program is significant – they’ve made amazing steps forward in defining what value an Architect brings, and how they are different from a Salesforce admin, a Sales Cloud consultant etc. In terms of growth in the Architect cohort, the main benchmark that Salesforce has to go on is certifications – as in, the more certified professionals year-on-year means the role is growing in popularity.
I think that role has always been there – it just wasn’t always as clearly defined

For me, when I first started in 2008 Architects were IT-focused specialist roles, who were usually brought in when things got tough, when there were multiple facets and in more complex projects. In other sectors such as Oracle or IBM, I would argue that their Architect roles were defined earlier than in Salesforce.

Fast forward to now, and the Salesforce Architect role has really come into being. Since the certification programs launched, people have continually aspired to reach the top level of expertise. By putting credentials behind themselves, Architects are winning more work, gaining more experience, and as a result, delivering value.

I think people started to consider what the career path looks like for someone who doesn’t want to go into management, who has been delivering Salesforce projects, and still wants to achieve some seniority. There is a clear path as to how these aspiring Architects can reach the next step – promotion from a technical discipline rather than a management discipline.

They want their expertise and experience to be seen and valued for what it really is. Everyone wants to become a leader or an authority in some way when they’ve got some experience. I feel that moving into an architectural role, whether you’re looking at it from business or Salesforce or integration, programming, etc. It’s okay to have specializations, you don’t have to know everything. The ‘5 types of Architects’ is designed to show you what’s available once you arrive there.”

Summary

The guide has outlined the differences in the Architect roles typically present in Salesforce projects. Five teams can touch one process, and all of those teams need to make individual decisions that will roll up into one big strategic decision.

We’ve given the spotlight to other aspects that sometimes get neglected (business transformation, change management, people). These are architectural considerations but are sometimes left to other project roles (eg. Business Analysts).

Salesforce is working to define how these roles match credentials through their certification and enablement programs.

Moving into an architectural role, whether you’re looking at it from business or Salesforce or integration, programming, etc. It’s okay to have specialisms, you don’t have to know everything. The ‘5 types of Architects’ is designed to show you what’s available once you arrive there.