Introducing the exam – Salesforce Data Architect Theory – Salesforce Certified Data Architect Study Guide

Introducing the exam

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.