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.

Types of Salesforce Architects

There are five 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 at The Architech Club, and Ladies Be Architects. Let’s find out what she has to say.

If you’re not familiar with what Salesforce Architects do, you probably don’t know the differences between each type. Before we dive into the specifics, let’s have a look at the general overview of the architect types:

• Solution Architect: Responsible for everything inside Salesforce.
• Technical Architect: Responsible for the data going in and out of Salesforce and integrated systems.
• Data Architect: Responsible for defining and designing the data architecture, making it 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.

After reading this, it’s likely that you now have more questions than before. What does a Technical Architect do differently from a Solution Architect? How do Enterprise Architects fit into the picture? Are all Architects necessary to work on a single project? Rest assured, we will explore these questions ultimately demystifying the subject.

Solution Architect, a.k.a. the Party Planner

They’re 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 modeling
• 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: 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 acknowledgment.

Technical Architect, a.k.a. the Door Person

Responsible for data going in and out of 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, 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 modeling
• Data migration
• Multi-component solutions*
• Code inside Salesforce (including Apex, Visualforce, and 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.

These two roles work closely as they share common interests. Below, you’ll find the main differences 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, a.k.a. the DJ

Responsible for defining and designing the data architecture, making it scalable. If data were music, 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 data storage in complex environments.

Digital transformations often involve pulling data from various external sources. These databases may integrate with Salesforce directly, be managed via Apex jobs, or involve middleware – like Mulesoft. While the TA concerns themselves with how data flows in and out of systems, the DA is interested in optimizing 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 execute this work themselves, often leading others.

They will oversee:

• Data modeling
• Data migration: activities, sequences, risks, transformations, and dependencies
• Data quality, by identifying risks and strategizing 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 (e.g. 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 optimizing 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, a.k.a. the Club Manager

They’re 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 agrees and moves 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 the first to get chopped off the statement of work when people want to get their project quotes down.

Gemma reveals that her former boss and mentor (who’s a CTA) was the first person to share their thoughts on the article when it was originally published. He said, “I like that you’ve done the flavors. The transformation piece is interesting. Where did that come from?” Gemma quickly pointed 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

They’re 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 focuses 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 business’s 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 will, perhaps, be on top of the Salesforce platform? Whether it’s sold externally, or not?

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.

Ultimately, responsibilities need to be bundled into these types. It is because organizations, when they invest in consultancy services or hire talent in-house, want to know which ‘buckets’ they 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 (concluding 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?)

Has it always been the case that these were the five types of architect roles? Or was there a turning point when the architect role expanded, or bucketed into these specific definitions?

• Salesforce’s investment in 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 absolutely fine to have specializations – you don’t have to know everything. The ‘five types of architects’ concept is designed 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, but 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 ‘five 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.