Skip to content

What advice would you give to aspiring Salesforce Architects when it comes to tech skills?

red and black number 8
Introduction
This question is tricky for several reasons:
  • First of all, the ecosystem is growing so fast that is hard to predict what will be valuable in future.
  • Secondly, I would never bet on a single skill, I’d rather figure out how to become an ‘E-shaped’ individual, to keep my career choices open.
  • Lastly, it is not only technical skills that make a good Architect, more often though it is a combination of tech skills and soft skills that enables you to influence decisions, effectively present trade-offs of and design options.
Setting Pieces Together
So let’s start with the most important Architect Skill. The Skill of setting pieces together.
While there are never enough people who know the Salesforce platform in and out, what I think is very important for Salesforce Architects is to broader their perspective to the Enterprise level instead of focusing solely on the Salesforce Platform.
On a macro level – in order to design an optimal Salesforce solution, you need to understand both the requirements and the vision of the target system as well as or even more importantly the Enterprise Architecture landscape that Salesforce will be part of.
On a micro level – you need to understand Salesforce features (licenses, clouds, add-ons) you will be using as well as the ecosystem of available extensions (AppExchange products, connectors, etc.).
In other words, an Architect is someone who first defines the allocation of business functions to Systems and then defines how to glue them together by defining Enterprise Integration Patterns that are suitable to fulfill end-to-end business processes that span across Systems. A good architect will also advise on areas that should stay as close to out-of-the-box as possible – the areas that are not essential to the uniqueness of the company’s value proposition and the areas that will create the most value and might or likely should be customized.
The next sections will list the main areas (“pieces”) of the solution that architects usually play with, the building blocks required to make the solution complete. As well as some tools and skills on how to sell their ideas to a broader audience including key decision-makers.
Know the ecosystem
Let’s start with some of the main components:
  • IDP – will salesforce manage all your Users and Passwords or do you need to integrate with Active Directory, ADFS, LDAP? If so who is your Identity Provider and are you using Identity Connect or do you need to use any of the common providers (e.g. Okta, Ping Identity, Auth0)
  • Master Data Management (MDM) – is Salesforce the system of records for all your Data? If not how will you ensure the data integrity? Is there an Enterprise Data Strategy already in place or do you need to build one? Consider using accelerators like Mulesfoft or Informatica Cloud MDM – Customer 360 for Salesforce
  • Document Generation – do you need to generate documents out of Salesforce? If yes do you need to use any of the available solutions like DocuSign or Conga. Bonus question how will you design configuration (version) management and testing of your documents? Do you need a full-fledged CLM (Contract Lifecycle Management) solution?
  • Backup and Restore – do you need to offload data from Salesforce and make it available on-demand? Do you have a backup solution in-house or do you need to use any of the pre-integrated solutions like OwnBackup or odaseva. Do you want to bring Salesforce data to Heroku by using Heroku Connect? It might be handy in case you need to build a robust experience layer on top of your data for the End Users (high volume use cases).
  • Integration – what is the Enterprise Integration strategy for both real-time integration and ETL. Are you implementing the API-led connectivity approach moving towards Microservices architecture style or maybe your landscape is ETL heavy with Data Lake or Data Warehouse acting as the integration layer on data level?
Not Only Salesforce

The more programming languages and (Cloud) Tech stacks you know the better. Through learning new technologies, you become more fluent in applying common concepts to your solutions.

You will also start building a point-of-view of what works and what does not. Which combinations are successful and which are problematic.
The main benefit here is that you will start to build a repository of architectural blueprints around:

  • What is the best eCommerce solution to talk to Salesforce?
  • What is the easiest way to build a hybrid mobile app on top of Salesforce?
  • What is the cheapest marketing tool that integrates well with Salesforce?
  • What is the easiest way to replicate Salesforce to AWS (AppFlow vs other integration methods)?

The list goes on and on but I hope you are getting the point.

Release Management and DevOps
Once you defined your solution you need to get it through all the project stages from design to build, test, deploy and hyper-care.
What will be your Release Management strategy, are you in a robust DevOps CI/CD organization with two-week Sprints and production Releases or maybe a Waterfall organization that releases once a year?
How can you decouple Salesforce from legacy systems in order to support a two-speed IT environment with Salesforce releasing new features on-demand while legacy backend systems might be updated in a longer Release cycle?
Do you have existing pipeline and source control in place? Is Salesforce part of the bigger picture or will it release independently?
Do you need tools like Copado to enable your DevOps journey?
What about testing: test automation, regression testing, integration testing, etc.?
Governance, Project Management Change Management
  • Is your Salesforce implementation part of a project, program or maybe a Portfolio?
  • How are you going to ensure successful adoption and business alignment on the solution you are building?
Diagramming Skills
Now once we have lots of blocks to build from, how do you present the information in a clean, digestible way, balancing the complexity with readability?
How are you going to get a directional decision from C-level executives, how will you get your team aligned?
Yes, sometimes it is not possible to escape from PowerPoint slides, and there will always be demand for building good slides.
Story Telling and Presentation Skills
Finally, what is your Story, how is the solution fixing the underlying problem? How can you wrap all your artifacts into a compelling story that can be used to convince your audience (stakeholders) on the way to go?
How will you make sure they understand the big picture as well as understand the trade-offs of key architectural decisions.
Resources
Identity Providers: Decoupling Layer: Backup and Restore: Document Generation:

Loosely inspired by NO KILL SWITCH