Chapter 7: Designing a Scalable Salesforce Data Architecture

In this chapter, we will continue looking at other Salesforce-specific knowledge areas that you must know about if you wish to pass the CTA review board. This is the third domain out of the seven mentioned earlier. We will go through the necessary knowledge and preparations for each domain and then complete a hands-on exercise using a mini hypothetical scenario.

The data domain is a broad domain with a lot of interdependencies. It impacts several other domains, and it is impacted, in turn, by several domains. We have come across several design decisions related to data in the previous two chapters already and will continue to come across more of them in the chapters to come.

This is because the data domain is at the center of any Salesforce solution. It involves understanding the key principles of designing your Salesforce data model, which is at the heart of your solution. There are hardly any successful enterprise...

Understanding what you should be able to do as a Salesforce data architect

According to Salesforce's online documentation, the CTA candidate should meet a specific set of objectives, all of which can be found at the following link: https://trailhead.salesforce.com/en/help?article=Salesforce-Certified-Technical-Architect-Exam-Guide&search=release+exam+schedule.

Let's have a closer look at each of these objectives.

Describing platform considerations, their impact, and optimization methods while working with LDV objects

First, you need to be able to identify an LDV. I use a simple mathematical method to identify LDVs, where an object has to meet at least one of the following conditions:

• Has more than 5 million records
• Has a growth rate that would lead to creating 5 million new records per year

In addition, some other indicators can point to an LDV use case, such as the following:

• Having an org with thousands of active users who can access...

Introducing the data architecture domain mini hypothetical scenario – Packt Online Wizz

The following mini scenario describes a challenge with a particular client. The scenario has been tuned up to focus on challenges related to data architecture specifically. However, this domain is tightly related to the security domain – sharing and visibility in particular. Therefore, you will still notice a considerable amount of sharing and visibility requirements. There will be other scenarios in later chapters that also have dependencies on the data architecture domain.

We will go through the scenario and create a solution step by step. To make the most out of this scenario, it is recommended that you read each paragraph, try to solve the situations yourself, then come back to this book, go through the suggested solution, and compare and take notes.

Remember that the solutions listed here are not necessarily the only possible solutions. Alternate solutions are acceptable...

Building your solution and presentation

Give yourself time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. Once you've done this, you're ready to go through it again, section by section, and incrementally build the solution.

Understanding the current situation

The first paragraph of the preceding scenario contains some general information about POZ's business model. It also contains some interesting figures, such as 5 million daily visitors and 150k orders per day, with an average of five items in each order. Take some notes about these figures. In some scenarios, there are figures that are not necessarily going to impact the solution from a technical perspective. However, they could be mixed up with other figures that you should be very careful writing about.

For example, at first glance, you will notice the huge number of daily visitors, which could impact the governor's limits in...

Summary

In this chapter, we dived into the details of the Salesforce data architecture domain. We learned what a CTA must cover and at what level of detail. We then discovered some interesting principles that a Salesforce data architect needs to master and had an under-the-hood look at the causes, impacts, and mitigation strategies for LDV objects.

We then tackled a mini hypothetical scenario that focused on a data architecture, and we solutioned it together and created some catching presentation pitches. We identified several LDV objects and prepared a comprehensive mitigation strategy based on the business's nature and shared requirements.

If you are now part of a Salesforce implementation project, or you are administrating a running instance, you can practice the process of identifying LDVs. Start by analyzing the data model diagram (or create it if you still don't have one!), and use the tools and techniques we covered in this chapter to identify LDVs. Do your calculations...