The Salesforce Certified Data Architect credential is one of several introduced by Salesforce to initially address three main challenges:

• As Salesforce implementations increase in size and complexity, there is an increasing need for good data management, including best practices in data architecture and management in Salesforce. Data is the life-blood for many businesses, and the architecture of Salesforce as the platform to hold that data is important.
• There was a huge gap in the knowledge required between the Certified Technical Architect credential and the other credentials available. The only prerequisite for CTA in the past was that you had to hold the Salesforce Certified Administrator certification and answer a multiple-choice pre-exam!
• Not everyone wants to necessarily be a full-blown Salesforce Certified Technical Architect. Instead, they may want to focus on one or more specific technical domains or aspects of the Salesforce platform.

Simply put, this credential puts the focus on the data architecture aspects of the Salesforce platform. Candidates who pass this credential will have had to learn about the wide range of theory, techniques, and considerations that constitute the credential syllabus, which is based on the real-world knowledge that's required of a Data Architect on the Salesforce Customer 360 platform. By learning everything that's required to pass the Salesforce Certified Data Architect credential, candidates will have a toolkit of knowledge and understanding to draw from, improving their ability to deliver solutions while considering the data aspects of the Salesforce platform.

The exam format consists of 60 multiple-choice questions, and candidates are given 105 minutes to complete the exam. The passing score that's required at the time of writing is 58%, and there are no written prerequisites for the exam (although, as you will discover quite quickly, it is extremely challenging to dive straight into this exam without the required learning and foundational knowledge of the Salesforce platform). Those unfamiliar with the Salesforce platform will struggle with many of the concepts introduced in this book, so it would be more practical to have experience in the platform at a sufficient capacity to understand how the data model works, what standard objects are available, and so on. This would typically equate to a few years of working with the platform, but this is subjective based on previous experience.

Breaking down the question count, testing time, and passing score required, we can deduce the following:

• We have 1 minute and 45 seconds to answer each question.
• We require 35 correct answers to pass the exam.

The exam is taken virtually, either at a test center or online, both using Webassessor. The mechanics of this will be covered toward the end of this book.

Preparing for Success

As you most likely already know, resources are available online such as Trailhead (https://trailhead.salesforce.com) – specifically, the Data Architect and Management Trailmix (https://trailhead.salesforce.com/en/users/strailhead/trailmixes/architect-data-architecture-and-management) – and blogs that cover the theory around a specific topic. To bolster your learning journey, I'd like to introduce some habits that you can employ to boost your potential for success.

Playground environments

Salesforce provides free Developer Edition orgs (sometimes referred to as DE orgs) that have many of the paid-for features of the core Salesforce platform (so this won't include Marketing Cloud or Tableau, for example). These allow candidates to try out many of the concepts explained in this book in a real Salesforce environment to explore what the real implications of a particular concept or feature are. For example, it is entirely possible to create an external object that interacts with an external data source so that we can see what the usability and other limitations are when interacting with off-platform data in this way. I would fully encourage you to have at least one DE org in your learning toolkit. You can sign up for a DE org at https://developer.salesforce.com/signup.

Documenting designs and design decisions

Another habit to aid in the learning process and beyond is to start documenting the following:

• Artifacts
• Design decisions

While it may not be an end goal for everyone, the Certified Technical Architect (CTA) review board exam requires candidates to produce several artifacts. These include a data model, system integration landscape, actors/licenses, role hierarchy, and so on.

One of the most crucial artifacts to produce is the data model because it conveys how information is linked together, where objects are used, the expected data volumes, data owners, org-wide default sharing, and where Large Data Volumes (LDVs) may be a concern, which means that mitigations will need to be planned for. You should become comfortable with producing this artifact as you assess your requirements and produce solutions. Having the correct data model will ensure that you have a solid sharing and visibility strategy, reporting strategy, and integration strategy. It's little wonder that this is considered a core artifact of the CTA review board, given how crucial it is to effectively design a technical solution on the Salesforce Customer 360 platform.

Let's look at an example data model diagram. As we can quickly ascertain from this relatively simplistic example, a lot of information can be explained quite easily that you can understand using the key provided (which any good diagram will contain):

Figure 1.1 – Data model example

Design decisions are an important factor in any Salesforce solution. Salesforce comes with its own unique set of features and limitations that need to be considered and worked with, so getting into the habit of documenting such decisions and linking those back to individual requirements will prove very useful when you're answering questions on the implications of, say, a specific feature's requirements and its impacts on a solution. There's no prescribed format for this as such – I've seen examples of in-line annotations for a requirements document (which is the preferred method for some CTA candidates when they're taking the review board exam), and I've also seen Excel spreadsheets with line items for each requirement with functional considerations and technical considerations columns where such items are documented.

Other Salesforce credentials in the Application Architect domain

As you'll know, there are several Salesforce certifications for each of the CTA domains. Looking at the Application Architect domain specifically, the following credentials comprise it:

Figure 1.2 – The Application Architect domain

You may already have some or all the other credentials in the Application Architect domain. For those of you who may not, I strongly encourage you to gain your Platform App Builder and Platform Developer 1 credentials as you go through your journey as a Salesforce Data Architect. Both of these exams contain foundational questions related to data on the platform and can act as another enabler for success with the Salesforce Certified Data Architect credential.

The Sharing and Visibility Designer credential will have some overlap with the Data Architect credential as data and sharing on the Salesforce platform are relatively intertwined. When you complete this credential, I suggest moving on to the Sharing and Visibility Designer credential because some of the concepts that will be introduced in this book are pertinent to that credential. You can see how the Application Architect credentials relate and why it is useful to gain the foundational learning that's introduced in the Platform Developer 1 and Platform App Builder credentials if you have not already done so (although these are not strict prerequisites to taking the Data Architect exam). The Application Architect domain credential is automatically awarded upon completing the constituent exams, as per the preceding diagram.

Now that we know about the credential and what the exam looks like (including some tips and habits to help bolster learning), let's break down the Salesforce Data Architect job profile.

According to the Salesforce Certified Data Architect Exam Guide (located at https://trailhead.salesforce.com/help?article=Salesforce-Certified-Data-Architecture-and-Management-Designer-Exam-Guide), a Salesforce Data Architect is someone who does the following:

… assesses the architecture environment and requirements and designs sound, scalable, and performant solutions on the Customer 360 Platform as it pertains to enterprise data management. The candidate is knowledgeable about information architecture frameworks covering major building blocks, such as data sourcing, integration/movement, persistence, master data management, metadata management and semantic reconciliation, data governance, security, and delivery. 

The candidate also has experience assessing customers requirements in regards to data quality needs and creating solutions to ensure high-quality data (for example, no duplicates, correct data) and can also recommend organizational changes to ensure proper data stewardship. The candidate has experience communicating solutions and design trade-offs to business stakeholders.

Let's break this definition down a little.

The first paragraph of that definition contained a lot of terms, but ultimately, it describes someone who can understand the requirements and applies data architecture principles and experience when formulating a solution or design. To me, this is part-and-parcel of our day job: understanding requirements and designing solutions. There is also mention of performance, data management, security, scalability, and governance. The second paragraph focuses on data quality and stewardship. All these aspects are covered in this book.

When we turn our attention to what the profile of a Data Architect is, a lot of parallels can be drawn to the humble Salesforce administrator, consultant, or architect – we listen to what our stakeholders want and design solutions that address those requirements, all while being mindful of the considerations and trade-offs that may present themselves along the way.

A Data Architect applies their knowledge of the data architecture of the Salesforce Customer 360 platform, including its features and their impact on the system when producing designs or solutions, such as the following:

• Sharing and security impacts based on the relationship choice between objects
• Large data volume considerations and mitigations
• Knowing what type of object to use where (standard, custom, big, or external)
• Indexing
• Performance
• Data stewardship and governance
• Loading and extracting data from the platform, and the methods available to affect the performance of these

With the definition of the profile of a Salesforce Data Architect broken down a little, we can turn our attention to the learning journey that will be outlined in this book.

Throughout this book, the certification learning journey will be broken down into the theory and the designer parts of the exam. The theory will align closely with the curriculum that's described in the exam guide, with the designer section dedicated to learning about the practical concepts referenced in the theory – for example, learning about Person Accounts and how they affect the data model and sharing thereof.

The learning journey starts with the theoretical concepts behind the exam:

• Data Modeling and Database Design:
  • Understanding how the Salesforce data model is architected, the design decisions behind that, and how the model affects sharing and security.
  • Understanding the different types of objects and how these fit into the data model design strategy.
  • Understanding data skew, which will provide you with an understanding of this concept in Salesforce.
• Master Data Management:
  • Understanding how to effectively design and implement a Master Data Management (MDM) strategy on the Salesforce platform.
  • Being able to articulate the concept of a golden record, preserve data traceability across multiple data sources, and understand how this affects the context that business rules run in.
• Salesforce Data Management:
  • How Salesforce license types affect the data model and the sharing options available to work with. Understanding these, as well as how to govern the data on the platform, is crucial to designing scalable, performant solutions that combine data from one or more Salesforce instances.
• Data Governance:
  • Being able to safeguard data on the Salesforce platform is a key part of the Salesforce Data Architect's role. This chapter covers the concepts behind building compliant solutions and how the Salesforce platform can underpin an enterprise data governance strategy.
• Large Data Volumes:
  • Whilst the Salesforce platform can cope with large amounts of data, some considerations apply to larger/massive amounts of data (referred to as large data volumes) and how the performance on the platform is affected.
  • This chapter covers LDV considerations and mitigations, as well as scalable data model design and data archiving strategies.
• Data Migration:
  • How do you get good quality data into the Salesforce platform?
  • How do you ensure loading large amounts of data is smooth, reliable, repeatable, and timely?
  • How do you effectively export data from the Salesforce platform?

Next, we'll look at the designer concepts that apply practical knowledge and practices to hone the theory:

• Accounts and Contacts:
  • We will cover the Account/Contact model, including Person Accounts and Contacts to Multiple Accounts, account skew, and the implications this has on the performance of queries and reports.
• Data APIs and Apex:
  • We will understand the various Lightning Platform APIs and Apex operations (including database, batch, and asynchronous), and how to deploy them effectively when designing data operations on the Salesforce Customer 360 Platform.
• Tuning Performance:
  • We will learn about the various methods that are available for tuning performance when designing Salesforce applications on the Salesforce Customer 360 Platform.
• Backup and Restore:
  • We will understand the methods that are available for getting data out of and back into the Salesforce platform while focusing on data backup and restore. This is useful when you're designing ETL and other solutions as part of an overall Salesforce IT estate.
• Territory Management:
  • We will understand territory management and how it pertains to the data model and its usage design on the Salesforce Lightning Platform.

Lastly, there is a section of this book that's dedicated to exam success that focuses on the following:

• Practice questions and answers
• Cheatsheets
• Introduction to further reading on some of the concepts and topics mentioned in this book
• An overview of Webassessor, including how to sign up for and take the exam

In this chapter, we learned about why the Salesforce Certified Data Architect credential exists, the exam format, and the profile of a Salesforce Data Architect to truly understand why the concepts behind this exam are useful in your day job. Lastly, we covered this book's learning journey to set the tone for the rest of this book.

In Chapter 2, Data Modeling and Database Design, we will begin our learning journey by revisiting the Salesforce data model, how different objects affect it, as well as touching on concepts such as data skew and ownership skew. We'll cover how to effectively describe the Salesforce data model while considering sharing, record counts, and performance as appropriate.

Answer the following question to test your knowledge of this chapter:

1. What is the Salesforce Certified Data Architect credential?
2. Why does the credential exist?
3. What is the typical profile of a Salesforce Data Architect?

Read the official Salesforce exam guide: https://trailhead.salesforce.com/help?article=Salesforce-Certified-Data-Architecture-and-Management-Designer-Exam-Guide.