Table of Contents
Introduction
Every architect or aspiring architect knows that they must have the technical skills and Salesforce knowledge to design elegant declarative and code-based solutions for the organizations or business units that they are working with. It is often taken for granted, however, that one must also have the requisite “domain knowledge”: information about the industry in which you are architecting solutions. If you don’t understand the problems that someone is trying to solve with a piece of technology, you’ll never be able to design a truly great solution.
Sometimes organizations (or even architects themselves!) fall into the trap of assuming that individuals are interchangeable and that an architect is an architect is an architect. This couldn’t be further from the truth. Each of us brings a unique set of skills, experience and knowledge to the table, and a Financial Cloud architect is going to be tackling very different problems than a Marketing Cloud Architect – even if the deliverables and artifacts look similar.
As an architect, you may find yourself thrust into an area that you’re not familiar with. Maybe you’re a consultant starting a new project in an industry you’ve never tackled before. Maybe you’re an inhouse architect and your company has acquired a subsidiary in a different industry, or maybe you’re just looking to expand your skillset and take on a new challenge.
Whatever the reason you are working outside your usual domain, you need to be a quick study. Architects are the first and last lines of defense: the problem solvers, builders and designers who can evaluate multiple approaches and choose the best one to meet client needs under pressure and with strict timelines. While your stakeholders and end users are the experts of their own needs, the more information you have going in the better off you’ll be. This article will help ensure you have the maximum level of knowledge before you ever get to that first kick-off or Steering Committee meeting.
In the rest of this article, we’ll look at ways of building domain knowledge across disparate industries and how to validate that you’ve understood the needs of your clients.
Strategies to Build Domain Knowledge
Strategy 1: Look at existing Salesforce products that cover the industry
Whenever I need to do some work in an area that I’m less familiar with, my first stop is to learn whichever Salesforce Cloud or product covers that vertical. It’s okay if the client or project won’t actually have access to that cloud or those products. If your client is on Service Cloud but they’re a healthcare organization, there is plenty to learn from the Entity Relationship Diagram (ERD) of Health Cloud, along with how its various features and functionality work together, like Care Plans, Health Timeline and EHR integration.
Fig 1. A partial view of the Entity-Relationship Diagram for Salesforce Health Cloud
In addition to detailed documentation and architectural diagrams, Salesforce also produces case studies about many of its clouds and how they’ve been used successfully. Because of their high level nature, they have much insight to offer an architect who is considering taking on a project in this same industry. Once you know what’s offered in a product, you can begin reading about why that’s necessary. What problems has this cloud solved for? What’s the last-generation technology that you’ll be replacing? Why does it work and what have people never liked about it?
Because there are now cloud offerings in virtually every industry from automotive to education to life sciences to nonprofit, there are likely architectural blueprints you can learn from. Beyond standard design patterns, understanding how others have accomplished these same tasks (and why they were worth solving in the first place) can help ensure you haven’t overlooked anything as you begin to see how all the pieces fit together.
Strategy 2: Read a book about the industry (or watch a video!)
Sometimes reading books can feel old-fashioned. This is especially true in tech where many books are outdated as soon as they’re published! However, if you want to get a good understanding of the problems confronting the industry you’re about to architect a solution for, books are one of the best ways to get a deep dive.
For virtually every industry there are books that will help you get a better understanding of the moving parts: who are the major players? What are the pain points for people who work in that industry? What could be done differently? These can be academic titles like The Future of the Automotive Industry or Information Technology for Healthcare Managers, or they can be general interest books like Investment Banking for Dummies.
Before you read, ensure you’ve prepared yourself for understanding the project that you’re about to embark on by reviewing any pre-sales decks or content you have access to, any contracts or Scopes of Work, or any meeting recordings available to you. This will give you the guidance you need to get the most out of the project you’re about to start.
For example, if you know that outcomes measurement will be a key part of the healthcare project you’re about to start, pay attention to what KPIs are mentioned in your healthcare reading. Even if the healthcare project doesn’t specifically involve any of the KPIs that you’ve read up on, by having an understanding of the important ones you’ll be better prepared to recognize when they don’t apply, and build trust with your stakeholders by being able to speak their language.
If you’re someone who prefers video to the written word, YouTube is your friend! Doing a YouTube search for “<industry> explained“ will often be all you need to find short and long-form videos on the industry at hand and what problems people are dealing with.
For more complex implementations, using the search term ”mock CTA“ brings up numerous videos of real Certified Technical Architects walking through solutions to case studies in industries like education, energy and commerce. These scenarios usually come with a vignette describing the industry, the organization and their major pain points which is a useful source for this high-level information.
Strategy 3: Network in the ecosystem
You’re already here, so you know the Salesforce Architect Blog is valuable. One way to increase its value is to read articles specifically focused on the industry you are learning about. This can be assisted by a bit of Google-fu.
For example, if you are interested in learning more about the insurance industry, you can do a Google search for “insurance” site:https://medium.com/salesforce-architects. That site operator on the end ensures that your search is filtered to only cover Architect Blog articles. Among the returned results, I may start with the “Deep Dive: Salesforce Industries for Insurance” article, or “Introducing Salesforce Industries and OmniStudio for Architects” if I’m short on time.
Outside of reading the Salesforce Architect blog, there are Salesforce User Groups, LinkedIn pages, blogs and websites, as well as Dreamforce and TrailblazerDX brimming with sessions across industries. As of this writing, TrailblazerDX is offering sessions in Energy and Utilities, Financial Services, Healthcare and Life Sciences, and Public Sector – all super useful for people looking to architect in those areas.
Networking doesn’t have to be anything super formalized. Sometimes it’s as simple as keeping track of where former colleagues have moved in the Salesforce ecosystem and what kind of products they are working on, so that when you need a pointer to a resource in that area, you know someone, or know someone who knows someone.
Strategy 4: Review your firm’s previous work
Sometimes, you have access to work product from previous architects that can be inspiring. This is most useful if your organization has worked on similar problems, projects or industries but shouldn’t be discounted as a rich source of material for comparison and inspiration.
Leveraging institutional knowledge is one of the most valuable ways of cutting through the noise and getting to the important information. This can be as formal as a knowledge session or facilitated training by someone with knowledge in the area you are learning about, and as informal as grabbing a coffee with a coworker who used to work in finance and asking them about what client management looked like for them.
If your organization isn’t currently organizing past solutions, artifacts and knowledge transfer sessions, consider leading the effort to do this. It will pay dividends for others who find themselves working on similar problems as you, and it may help you when you go to design something and have an easy reference for how you’ve done it in the past.
Validating Domain Knowledge
If you’ve made it this far, you may be brimming with ideas for how you can jump into your newest project and begin developing that all-important domain knowledge that will help inform your solutioning. You may be wondering, how do you know whether you’ve captured what you really need to know?
This is where you and your Business Analyst (if you have one!) get to validate your knowledge with the client. Throughout the discovery and design process, ensure you are talking about what you’ve learned and asking your stakeholders and meeting attendees to provide feedback. They are the experts of their industry, but even getting things wrong gives you the opportunity to learn by being corrected – and you’re more likely to remember next time.
As a stakeholder, knowing that their architect understands the basic pain points of the industry and speaks a common language goes a long way to building trust and allows you to get working together quickly.
As your knowledge level increases, you may find yourself assisting those coming behind you with knowledge transfer, architectural references and other supports. Over time, you’ll increase the mental “scaffolding” you have to rely on as you relate new projects to previous ones, and pretty soon this new industry will be another feather in your cap.
Conclusion
Before your next project in a new industry, consider these approaches to help you build domain knowledge and to validate what you’ve learned. Don’t forget that there are ways of learning that work for every person’s style, and lots of stakeholders to learn from. Good luck!