Becoming a Salesforce Certified Technical Architect E-Book

Tameem Bahri

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 799

Veröffentlichungsjahr: 2021

Beschreibung

Salesforce Certified Technical Architect (CTA) is the ultimate certification to validate your knowledge and skills when it comes to designing and building high-performance technical solutions on the Salesforce platform. The CTA certificate is granted after successfully passing the CTA review board exam, which tests your platform expertise and soft skills for communicating your solutions and vision.
You’ll start with the core concepts that every architect should master, including data lifecycle, integration, and security, and build your aptitude for creating high-level technical solutions. Using real-world examples, you’ll explore essential topics such as selecting systems or components for your solutions, designing scalable and secure Salesforce architecture, and planning the development lifecycle and deployments. Finally, you'll work on two full mock scenarios that simulate the review board exam, helping you learn how to identify requirements, create a draft solution, and combine all the elements together to create an engaging story to present in front of the board or to a client in real life.
By the end of this Salesforce book, you’ll have gained the knowledge and skills required to pass the review board exam and implement architectural best practices and strategies in your day-to-day work.

Leseprobe

Becoming a Salesforce Certified Technical Architect

Prepare for the review board by practicing example-led architectural strategies and best practices

Tameem Bahri

BIRMINGHAM—MUMBAI

Becoming a Salesforce Certified Technical Architect

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Publishing Product Manager: Alok Dhuri

Senior Editor: Nitee Shetty

Content Development Editor: Ruvika Rao

Technical Editor: Pradeep Sahu

Copy Editor: Safis Editing

Project Coordinator: Francy Puthiry

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Roshan Kawale

First published: February 2021

Production reference: 2120822

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80056-875-4

www.packt.com

To my mother, Raefa Arwani, my first teacher, and the most brilliant person I have ever known. To my wife, Lana, and my son, Ameer, for their love, support, and inspiration.

Contributors

About the author

Tameem Bahri is the European Salesforce CTO at Capgemini and a Salesforce CTA with a demonstrated work history in the information technology and business consultation industry, with over 17 years of experience across business transformation, digital services, innovation, process design and redesign, enterprise system security, identity and access management (IAM), and enterprise solution architecture. He has worked across several industries, such as manufacturing, Clinical Practice Research Datalink (CPRD), travel and transportation, energy and utilities, property management, and software development. He has led dozens of Salesforce implementations worldwide and currently heads Capgemini's program to develop the next generation of CTAs.

I'd like to thank the following people at Packt who made this book possible: Alok Dhuri, who was the first to express faith in me, and Nitee Shetty, Ruvika Rao, Francy Puthiry, and Prajakta Naik, who worked tirelessly with me to improve my drafts. I'd also like to thank the reviewer, Ali Najefi, an admirable CTA himself, for his helpful advice and support.

About the reviewer

Ali Najefi is an enterprise architect with 18 years' experience of which 13 years has been in Salesforce. He is a Salesforce CTA with a track record of delivering complex digital transformation projects on the Salesforce platform.

He has led the Salesforce architecture and design authority team, responsible for ensuring all Salesforce delivery teams adhere to Salesforce's best architecture and design principles. He has a significant interest in cybersecurity, IAM, digital data management, MDM, analytics, and AI. He has worked on several enterprise clients directing both architectural domain and delivering solutions that have proven to be secure and scalable for millions of end customers and thousands of enterprise users.

Table of Contents

Becoming a Salesforce Certified Technical Architect

Contributors

About the author

About the reviewer

Preface

Who this book is for?

What this book covers?

To get the most out of this book

Journey Towards Becoming a Salesforce CTA – Book Club

Download the color images

Conventions used

Get in touch

Reviews

Learn more on Discord

Section 1: Your Journey to Becoming a CTA

Chapter 1: Starting Your Journey as a CTA

Understanding the profile of a Salesforce Certified Technical Architect

The CTA review board's structure and format

From exam to real life – how to train to become a CTA

The nature of the exam – a point collection exercise

What kind of artifacts you need to generate and why

The actors and licenses diagram

The data model diagram

The system landscape diagram

The role hierarchy diagram

The business process flow diagram

The environment diagram

The contextual SSO flow diagram

Summary

Chapter 2: Core Architectural Concepts – Data

Differences between classic RDBMS and Salesforce

Understanding data governance

Understanding data security

Data encryption

Data restoration

Data masking

Data erasure

Data regulatory compliance

Exploring data categories

Transactional data

Master data and master data management

Reference data

Reporting data

Metadata

Big data

Unstructured data

The nature of data warehouses and data lakes

Choosing the right document management system

Understanding data architecture concepts

Conceptual-level data architecture design

Logical-level data architecture design

Physical-level data architecture design

Designing and documenting your data model

Normalization versus denormalization

Normal forms

Using database relationships

Summary

Chapter 3: Core Architectural Concepts – Integration and Cryptography

Integration in the enterprise – understanding the landscape

Integration architecture design principles

Introducing the common integration styles

File transfer

Unified datastore

Remote procedure invocation

Messaging

Discussing the different integration tools

Point-to-point integration

Extract, transform, and load (ETL)

Enterprise Service Bus

Reverse proxies

API gateways

Stream-processing platforms

Exploring the modern integration approaches

Service-oriented architecture

Microservices

API-led architecture

Event-driven architecture

Cryptography – understanding the general concepts

Cryptographic algorithm types and use cases

Symmetric cryptography algorithms

Asymmetric cryptography algorithms

Cryptography use cases

Putting both integration and cryptography together

Summary

Chapter 4: Core Architectural Concepts – Identity and Access Management

Understanding the general concepts of IAM

Becoming familiar with the IAM terms and definitions

Becoming familiar with the common IAM standards

Understanding the common IAM standards

Getting to know the different types of tokens

Understanding the key authentication flows

Becoming familiar with the SAML 2.0 flows

Becoming familiar with the OAuth 2.0/OpenID Connect flows

Summary

Section 2: Knowledge Domains Deep Dive

Chapter 5: Developing a Scalable System Architecture

Understanding what you should know and be able to do as a Salesforce system architect

Determining the appropriate mix of systems

Design considerations for reporting and analytics

Org strategy

Mobile solutions and strategy

Required license types

Determining the right document management solution

Introducing the system architecture domain mini hypothetical scenario – Packt United Builder

The scenario

Internal stakeholders

External stakeholders

Requirements

Determining the appropriate mix of systems, and building your solution and presentation

Understanding the current situation

Diving into the shared requirements

Summary

Chapter 6: Formulating a Secure Architecture in Salesforce

Understanding what you should be able to do as a security architect

Utilizing the appropriate platform security mechanisms

Designing a secure portal architecture

Controlling record-level security using declarative and/or programmatic features

Using the platform security features to control object and field access permissions

Designing an end-to-end identity management solution

Introducing the security architecture domain – Packt Innovative Retailers

The scenario

Utilizing the appropriate security mechanisms and building your solution and presentation

Understanding the current situation

Diving into the shared requirements

Summary

Chapter 7: Designing a Scalable Salesforce Data Architecture

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

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

Explaining data modeling concepts and their impact on the database's design

Determining the data migration approach, tools, and strategy

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

The scenario

Building your solution and presentation

Understanding the current situation

Diving into the shared requirements

Summary

Chapter 8: Creating a Lean Solution Architecture

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

Selecting the right combination of declarative and programmatic functionalities

Augmenting your solution with the right external applications

Introducing the solution architecture domain mini hypothetical scenario – Packt visiting angels

The scenario

Selecting the appropriate functionalities to build your solution and presentation

Understanding the current situation

Diving into the shared requirements

Summary

Chapter 9: Forging an Integrated Solution

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

Recommending the right integration landscape

Determining the right enterprise integration architecture technology

Designing your integration interface using the right integration pattern

Selecting and justifying the right platform-specific integration capabilities

The scenario

Designing the enterprise integration interfaces to build your connected solution

Understanding the current situation

Diving into the shared requirements

Summary

Chapter 10: Development Life Cycle and Deployment Planning

What you should do as a Salesforce development life cycle and deployment architect

Identifying project risks and developing mitigation strategies

Identifying the impact development methodologies have on workstreams

Recommend test strategies to mitigate project risks

Recommending the right project governance to support technical decision-making

Crafting the right environment management strategy while considering the platform's capabilities and limitations

Describing the value of continuous integration (CI) tools and source control in release management

Introducing the mini-hypothetical scenario – Packt Modern Furniture

The scenario

Designing the project environment and release strategy

Understanding the current situation

Diving into the shared requirements

Summary

Chapter 11: Communicating and Socializing Your Solution

Understanding what you should be able to do while communicating your solution

Communicating design decisions and considerations

Demonstrating your visualization skills to articulate the solution

Handling objection and unexpected roadblocks

Practicing communicating a mini-hypothetical scenario – Packt Digital

The scenario

Articulating your solution and managing objections

Understanding the current situation

Diving into the shared requirements

Summary

Section 3: Putting It All Together

Chapter 12: Practice the Review Board – First Mock

Introducing the full mock scenario – Packt Pioneer Auto

Project overview

Current landscape

Business process requirements

Data migration requirements

Accessibility and security requirements

Reporting requirements

Project development requirements

Other requirements

Analyze the requirements and creating a draft end-to-end solution

Understanding the current situation

Analyzing the business process requirements

Summary

Chapter 13: Present and Defend – First Mock

Continuing to analyze requirements and creating an end-to-end solution

Analyzing the data migration requirements

Reviewing identified LDVs and developing a mitigation strategy

Analyzing the accessibility and security requirements

Analyzing the reporting requirements

Analyzing the project development requirements

Analyzing the other requirements

Presenting and justifying your solution

Understanding the presentation structure

Introducing the overall solution and artifacts

Presenting the business processes' end-to-end solution

Presenting the LDV mitigation strategy

Presenting the data migration strategy

Going through the scenario and catching all remaining requirements

Justifying and defending your solution

Summary

Chapter 14: Practice the Review Board – Second Mock

Introducing the full mock scenario – Packt Lightning Utilities

Project overview

Current landscape

Business process requirements

Data migration requirements

Accessibility and security requirements

Reporting requirements

Project development requirements

Other requirements

Analyzing the requirements and creating a draft end-to-end solution

Understanding the current situation

Analyzing the business process requirements

Summary

Chapter 15: Present and Defend – Second Mock

Continuing with analyzing the requirements and creating an end-to-end solution

Analyzing the data migration requirements

Reviewing identified LDVs and developing a mitigation strategy

Analyzing the accessibility and security requirements

Analyzing the reporting requirements

Analyzing the project development requirements

Analyzing the other requirements

Presenting and justifying your solution

Introducing the overall solution and artifacts

Presenting the business processes' end-to-end solution

Going through the scenario and catching all the remaining requirements

Justifying and defending your solution

Summary

Appendix

Tips and Tricks, and the Way Forward

The anatomy of a review board scenario

General solving tips

Go through the scenario and annotate first

Provide a solution, not a set of options

You have a limited set of tools to solve a problem

Act like an architect, use the common architects' language

Managing the board

Help them to keep up with you

Tie your solution back to the requirement

Watch and observe their reaction if possible

Seed some questions

Show your professional attitude

Time management

Plan ahead and stick to your plan

Rehearse and perfect your timing

Practice the 2-minute pitch

Balance where you spend your time

Your presentation – make or break

Show confidence

Control the tempo

Own the stage

Use your artifacts

Enjoy it

Your exam, your way

Next steps

Practice and practice more

Plan some time off before the exam

Get in touch with the community and study groups

Stay connected and share your experience

The community and available training

Salesforce training and study groups

Stories and lessons learned

Blogs and training providers

Journey Towards Becoming a Salesforce CTA – Book Club

Why subscribe?

Other Books You May Enjoy

Packt is searching for authors like you

Leave a review - let other readers know what you think

Preface

As the Salesforce economy continues to grow rapidly, there's never been a better time to build a Salesforce-based career. Architects and architect-related skills are in higher demand than ever.

The Salesforce Certified Technical Architect (CTA) credential is ranked as one of the top enterprise architect certifications in the industry. Just run a quick search on the web for job postings, and you'll have no doubt about the value of this prestigious certificate. The very limited number of CTAs around the world gives an even more satisfying feeling of joining the club of newly certified CTAs.

This book will start by explaining a set of core concepts that every architect should master, including the data life cycle, integration, and cryptography, and build your aptitude for creating high-level technical solutions. Understanding these concepts is vital to understanding the rationale behind some of the best practices suggested in Salesforce solutions. Moreover, having that in-depth knowledge will help you significantly when it comes to explaining how your end-to-end solution works.

You will then explore specific knowledge domains that are tested in the review board. With the help of real-world examples, this book provides insights into essential topics, such as selecting systems or components for your solutions, designing scalable and secure Salesforce architecture, and planning the development life cycle and deployments. Finally, you'll work on two full mock scenarios that simulate the review board exam, helping you learn how to identify requirements, create a draft solution, and combine all elements to create an engaging story to present to the board or a client in real life.

By the end of this book, you'll have gained the knowledge and skills required to pass the review board exam and implement architectural best practices and strategies in your day-to-day work.

Who this book is for?

This book is intended for Salesforce professionals who have a solid understanding of the Salesforce platform and who have racked up several years of experience as architects. These architects would ideally like to boost their careers further by targeting the Salesforce CTA credential. The book is also intended for architects who want to add more skills to their arsenal by learning how to design secure, high-performance technical solutions on the Salesforce Platform, along with how to communicate technical solutions and design trade-offs effectively to business stakeholders and how to adopt a delivery framework that ensures quality and success.

With the current rapid growth of the Salesforce ecosystem, the borders between traditional roles in some workplaces are blurring. And with that, the value of having people with exceptional talent to link the different teams becomes vital. Future CTAs are not afraid to dig deep into business challenges and ask tough questions to reveal the real business value behind a particular requirement. They like to get to the bottom of things and roll up their sleeves when necessary to try things out in order to select the right solution approach that serves current and future potential requirements. And they do not hesitate to jump into conversations with the development teams to give guidance and best practices and then work with the project management team to prepare that cutting-edge presentation for the stakeholders.

What this book covers?

Chapter 1, Starting Your Journey as a CTA, provides general information about the book and the certificate. We will cover what the profile of a typical CTA is, how that is related to the day-to-day activities of a Salesforce architect, and why understanding the way CTAs think is essential even for senior architects who are not necessarily targeting the CTA certificate. This chapter also provides details about the review board exam setup, whether physical or virtual.

Chapter 2, Core Architectural Concepts – Data, explores the core architectural skills related to data that an architect needs to master. Part of that knowledge is platform-agnostic, although other parts are particularly important for Salesforce architects. These skills will be used intensively in later parts of this book and, of course, during the review board itself.

Chapter 3, Core Architectural Concepts – Integration and Cryptography, explores the core architectural skills related to both integration and cryptography that an architect needs to master. Part of that knowledge is platform-agnostic, although other parts are particularly important for Salesforce architects. These skills will be used intensively in later parts of this book and, of course, during the review board itself.

Chapter 4, Core Architectural Concepts – Identity and Access Management, explores the core architectural skills related to Identity and Access Management (IAM) that an architect needs to master. Part of that knowledge is platform-agnostic, although other parts are particularly important for Salesforce architects. These skills will be used intensively in later parts of this book and, of course, during the review board itself.

Chapter 5, Developing a Scalable System Architecture, provides an in-depth review of some of the most tricky system architecture areas, such as determining the right selection of systems that forms the overall solution, including both on- and off-platform components, taking into consideration the platform's capabilities, constraints, and limits. This knowledge will be enhanced further using a mini hypothetical scenario.

Chapter 6, Formulating a Secure Architecture in Salesforce, provides an in-depth review of some of the most tricky areas in security, such as understanding the declarative platform security features and how they can be used to meet record-level visibility and security requirements. This knowledge will be enhanced further using a mini hypothetical scenario.

Chapter 7, Designing a Scalable Salesforce Data Architecture, provides an in-depth review of some of the most tricky areas in data, such as designing the right data migration strategy and tools, along with the different considerations the architect needs to keep in mind. This knowledge will be enhanced further using a mini hypothetical scenario.

Chapter 8, Creating a Lean Solution Architecture, provides an in-depth review of some of the most tricky areas in solution architecture, such as selecting the appropriate combination of declarative and programmatic functionality to fulfill a particular requirement. This knowledge will be enhanced further using a mini hypothetical scenario.

Chapter 9, Forging an Integrated Solution, provides an in-depth review of some of the most tricky areas in integration, such as rationally selecting the appropriate technology used to integrate with external systems, considering the platform's capabilities and limitations. This knowledge will be enhanced further using a mini hypothetical scenario.

Chapter 10, Development Life Cycle and Deployment Planning, provides an in-depth review of some of the most tricky areas in development life cycle and deployment planning, such as the ability to recommend a suitable comprehensive test strategy and mitigate the different project risks. This knowledge will be enhanced further using a mini hypothetical scenario.

Chapter 11, Communicating and Socializing Your Solution, provides an in-depth review of some of the most tricky communication areas. This includes explaining a crucial set of soft skills that an architect needs to master in order to present an end-to-end solution to the review board judges or, in real life, to internal or external clients, such as the ability to articulate the benefits, limitations, considerations, and design choices behind a proposed solution architecture in a justified and rational manner and being prepared to handle objections and adjust on the fly. This knowledge will be enhanced further using a mini hypothetical scenario.

Chapter 12, Practice the Review Board – First Mock, puts all the knowledge and skills covered in the previous chapters into action. You will be introduced to your first full hypothetical scenario. We will solve it step by step, beginning with identifying the requirement, creating a draft solution, and combining all the elements to create an engaging story to tell the judges or, in real life, internal or external clients.

Chapter 13, Present and Defend – First Mock, puts all the knowledge and skills covered in the previous chapters into action. We continue with the previous chapter's hypothetical scenario and use the draft solution to create a refined end-to-end solution and presentation. You will get hands-on experience by following a step-by-step guide where the solution is reviewed, adjusted if needed, and the artifacts' final versions are created. You will then use all of that to deliver an engaging story to tell the judges or, in real life, internal or external clients.

Chapter 14, Practice the Review Board – Second Mock, puts all the knowledge and skills covered in the previous chapters into action. You will be introduced to your second full hypothetical scenario. We will solve it step by step, beginning with identifying the requirement, creating a draft solution, and combining all the elements to create an engaging story to tell the judges or, in real life, internal or external clients.

Chapter 15, Present and Defend – Second Mock, puts all the knowledge and skills covered in the previous chapters into action. We continue with the previous chapter's hypothetical scenario and use the draft solution to create a refined end-to-end solution and presentation. You will get hands-on experience by following a step-by-step guide where the solution is reviewed, adjusted if needed, and the artifacts' final versions are created. You will then use all of that to deliver an engaging story to tell the judges or, in real life, internal or external clients.

Appendix, Tips and Tricks, and the Way Forward, provides a collection of tips and tricks to help the candidate on the day of the review, starting with best practices to follow during the presentation, followed by tips regarding time management. We then highlight different strategies used by other CTAs to pass the review board exam, and provide a set of suggested activities that a candidate who is targeting the review board should consider, including how to prepare for the last mile, what resources and groups are available in terms of getting support, and how to get into the right mindset on the day of the review board exam.

To get the most out of this book

This book is designed to help you gain the required knowledge and skills to pass the CTA exam using hands-on examples. We will be covering the seven knowledge domains that a CTA needs to master in order to pass the exam. We will tackle a mini hypothetical scenario for each domain. We will be developing the solution progressively, creating and then recreating solution artifacts as we discover and weigh different design decisions. This is precisely what many architects do in their daily lives. They dig deeper into details and, at every stage, they build a clearer picture of the solution and the correct elements required to make it. They revisit previous decisions and adjust or change them if needed.

You are strongly advised to practice recreating the solution, reconsider other alternatives, and weigh the pros and cons of each. Build your familiarity with the artifacts and diagrams needed to explain your solution. You will find that you become quicker and more efficient in creating them. Moreover, the quality of your outcome will also improve.

Diagrams will be provided at every stage and will progressively evolve; you will notice that these artifacts might end up very different from what we started with. The ability to evolve your solution and flexibly change its elements while still maintaining the end-to-end solution picture is a crucial skill that a CTA must master. You will learn much of that throughout the book.

The Salesforce Developer Edition org is recommended to try out certain functionalities. You can sign up for a free org using the following link: https://developer.salesforce.com/signup.

You can use any diagramming tool, free or paid, or even draw the diagrams on paper or a flipchart. To practice the virtual Salesforce CTA review board, you need to become familiar with tools such as Microsoft PowerPoint and Excel or Google Slides and Sheets (the latter is preferred).

Journey Towards Becoming a Salesforce CTA – Book Club

We have created an exclusive book club for you on our Packt Community page, to share knowledge and have insightful discussions around the topics covered in this book. This book club is for all the readers, existing architects, and anyone who aims to achieve the Salesforce CTA certification.

You are welcome to discuss the book, share your own experiences, views, and best practices on designing modern, practical, and robust architectures on the Salesforce platform, and help us grow the number of Salesforce CTAs globally.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781800568754_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "The logged-in, existing community user creates a Community_Invitation__c record and sets the required values, such as an email address."

A block of code is set as follows:

{

  "alg": "HS256",

  "typ": "JWT",

  "kid": "228",

}

Bold: Indicates a new term, an important word, or words that you see on screen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "A data warehouse (DW or DWH) is a central repository of current and historical data integrated from one or more disparate sources."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com.

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases, please visit http://packt.link/sfdserver.

Section 1: Your Journey to Becoming a CTA

This section will focus on foundational architectural skills that every Salesforce Certified Technical Architect (CTA) should master.

First, we'll start by introducing some general information about the Salesforce CTA credential, why it is so prestigious, and how it is related to a Salesforce architect's day-to-day activities. We'll learn why learning to think as a CTA is essential even for senior architects who do not target the CTA credential.

Then, we'll focus on the data life cycle architectural concepts. We'll start with a historical view to understand the principles behind today's modern technology and governance. Then, we'll tackle a set of data-related concepts such as data governance, security, and compliance. We'll also learn how these concepts are relevant to the enterprise. We will explore other key components of today's modern organizations, such as data warehouses and databases.

After that, we'll move on to explore two other crucial architectural domains: integration and cryptography. We'll start by understanding the nature of modern enterprises and why both domains are critical for success. We'll then explore a set of integration styles, tools, and approaches that form the heart of today's modern integration technologies. We'll then take a turn to learn more about cryptography and its importance to secure the digital world.

Finally, we'll tackle the crucial architectural domain of Identity and Access Management (IAM). We'll learn vital general concepts that any modern architect should be familiar with. Then, we'll explore common IAM standards and understand why they are essential for architects, particularly in the cloud era. We'll then explore the main authentication flows in detail and understand exactly what is happening behind the scenes.

This section has the following topics:

Chapter 1, Starting Your Journey as a CTAChapter 2, Core Architectural Concepts – DataChapter 3, Core Architectural Concepts – Integration and CryptographyChapter 4, Core Architectural Concepts – Identity and Access Management

Chapter 1: Starting Your Journey as a CTA

This chapter will get you started by providing general information about this book and the Salesforce Certified Technical Architect (CTA) credential. This chapter will help you get some answers to questions such as what the typical profile of a CTA looks like, how the exam is related to the day-to-day activities of a Salesforce Architect, and why understanding the way CTAs think is important even for senior architects who are not necessarily targeting the CTA credential. This chapter also provides general details about the review board exam's structure and setup (whether that is physical or virtual) and the main artifacts needed to document an end-to-end solution.

In this chapter, we're going to cover the following main topics:

Understanding the profile of a Salesforce Certified Technical ArchitectThe CTA review board's structure and formatFrom exam to real life – how to train to become a CTAThe nature of the exam – a point collection exerciseWhat kind of artifacts you need to generate and whyLet's get started!

Understanding the profile of a Salesforce Certified Technical Architect

As the Salesforce economy continues to grow rapidly, there's never been a better time to build a Salesforce-based career. Architects and architect-related skills are in higher demand than ever.

The Salesforce Certified Technical Architect credential is ranked as one of the Top Enterprise Architect Certifications in the industry. Just run a quick search on the web for job postings and you'll have no doubt about the value of this prestigious certificate. The very limited number of CTAs around the world gives an even more satisfying feeling of joining the club to the newly certified CTAs.

With such rapid growth of the Salesforce ecosystem, the borders between traditional roles in some workplaces are blurring. And with that, the value of having people with that special talent to link between the different teams becomes vital. Technical architects are not afraid to dig deep into business challenges, asking tough questions to reveal the real business value behind a particular requirement. They like to get to the bottom of things, and roll up their sleeves when necessary to try things out in order to select the right solution approach that serves the current and future potential requirements. They do not hesitate to jump into conversations with the development teams to give guidance and best practices, and then work with the project management team to prepare that cutting-edge presentation for the stakeholders.

As a CTA, you are expected to rely on your broad knowledge across multiple technologies and your deep expertise of the Salesforce Platform to design secure, high-performance systems that maximize the potential of the Salesforce Platform. You must then combine this with an excellent set of soft skills to help you socialize and defend the proposed solution.

The candidate should be able to demonstrate deep knowledge and experience in the following areas:

5+ years of implementation experience, including development, across the full software development life cycle. Although having hands-on development skills is not mandatory, those who had the chance to code would normally develop a sense of what would normally work for a software solution, which can help with logically selecting and justifying a particular solution.3+ years of experience in an architect role, which includes experience across the entire spectrum of architecture activities. This includes, but is not limited to, designing data models, integration interfaces, and end-to-end solutions; communicating and socializing a solution; and having deep hands-on experience with the platform's capabilities and potential solution trade-offs.2+ years of experience on the Lightning Platform, with at least one of those in a lead architect role, implementing Salesforce applications and technologies.Has held a technical architect role on multiple complex deployments, or has gained equivalent knowledge through participation and exposure to these types of projects.Experience guiding a development team on the appropriate use of platform technology.The ability to identify and mitigate technical risks across the architecture, which normally comes with experience.Exposure to globalization considerations on a project. Projects with globalization requirements come with a particular set of challenges. Having a practical understanding of the platform's capabilities is key.Experience with object-oriented design patterns. Although a CTA is not necessarily expected to write code, understanding object-oriented design patterns and principles creates a more rounded architect who is more capable of explaining how a particular module would work.Awareness of platform-specific design patterns and limits. In order to pass the CTA review board, it is strongly recommended that they have hands-on experience with the different platform functionalities.Experience developing code on the Force.com platform, as well as an understanding of limitations and associated challenges, even if they're not necessarily doing hands-on coding.Ability to identify development-related risks, considerations, and limits for the platform.Experience with multiple development languages (for example, .NET, Java, or Ruby) and design frameworks. This would largely help when designing an integrated solution. Understanding what is possible and what is likely not is the key.Experience with common integration patterns; experience with integration on the Salesforce Platform. Any hands-on experience here is a massive plus.An understanding of and the ability to architect a solution to address security complexities, mechanisms, and capabilities on the Lightning Platform as part of a functional security model.An understanding of and the ability to design an identity and access management strategy as part of an end-to-end solution.An understanding of data migration considerations, design trade-offs, and common ETL tools.Awareness of large data volume (LDV) considerations, risks, and mitigation strategies.Awareness of general mobile solutions and architectures and an understanding of on-platform mobile solutions and considerations.Experience with project and development life cycle methodologies.

Now that we know what the CTA profile is, let's get to know the review board.

The CTA review board's structure and format

This section is mainly meant for those who are targeting the CTA exam. In order to pass the exam, you would need to set a review board with three CTA judges. You will receive a hypothetical scenario and have a limited amount of time to solve it and craft an end-to-end presentation, explaining the different elements of your solution and how you would solve the identified requirements in your scenario. The judges will then ask questions about your solution and challenge it. You are expected to justify, defend, and – if needed – change your solution accordingly.

The following are some more details about the exam:

Exam prerequisites: The Salesforce Certified Application Architect credential and Salesforce Certified System Architect credential.Format: The candidate will review and solve a hypothetical scenario and then present this to a panel of three CTA judges. The presentation is followed by a question and answer session with the judges.Time allotted to complete the exam:

180 minutes for scenario review and solution preparation

45 minutes for scenario presentation

40 minutes for scenario Q&A session

An exam facilitator and proctor will be onsite during the exam (or will join virtually if the exam is being executed virtually).

The following materials are provided to the candidate at the review board (onsite). No other materials are allowed. If the exam is onsite, you will need the following:

A computer with PowerPoint, Word, and Excel (or Keynote, Pages, and Numbers for Mac)Flipchart paperBlank paper – for candidate notes onlyPens, highlighters, and markersA timer

If the exam is virtual, you will need the following: A computer with PowerPoint, Word, and Excel (or Keynote, Pages, and Numbers for Mac) that the candidate can access via remote desktop.

You can deliver your artifacts/diagrams using one or more of the following tools:

PowerPoint presentationsFlipchartsWhiteboard (This is not transportable. Remember that you will normally create the solution and artifact in one room and then present it in another.)A combination of these

There is no right tool. You need to build your own habits and plans and use whatever works best for you.

Now that you have learned the review board exam's structure, let's find out how it's related to the day-to-day life of a Salesforce Architect.

From exam to real life – how to train to become a CTA

In addition to the significant career boost, there are several other reasons to learn how to design secure, high-performance technical solutions on the Salesforce Platform in the same way it's expected from a CTA. During the review board exam, you are expected to perform certain activities and think in a particular way. This should not be thought of as activities required to pass the exam but more of best practices that an architect is expected to follow in order to produce a solution that delivers value and has fewer implementation risks.

Regardless of whether you are targeting the CTA credential or not, as an architect, you will find that you can apply the knowledge in this book to your day-to-day activities. Actually, the best way to get hands-on experience with all the required domain knowledge is by following these simple steps:

Apply the methodology explained in this book – or your own variation of it – to your day-to-day activities. Put it in action, and you will notice that it becomes second nature after some time. This makes it easier to set and pass the review board exam. Let's put it this way: if you are practicing this day in and day out, you will be actually preparing for the review board exam during your normal working hours.Set up playground environments to try things out by hand. As an architect, it is crucial to have practical experience with the different elements and technologies that form your solution. This is particularly true while working with the Salesforce Platform, considering all the flexibility it has and how it lets you easily sign up for a virtually unlimited number of developer environments. Nothing beats hands-on experience. So, the next time you are investigating how a particular Single Sign-On (SSO) flow works, don't just read about it: set up a playground environment and closely observe how the systems are interacting with each other. Make this one of your day-to-day activities while assessing different potential solutions for a given business challenge.Make yourself familiar with the activity of documenting design decisions. While working on a Salesforce implementation project, you will come across endless cases where there is more than one potential solution. Make yourself familiar with the structured way of documenting the details of each option, as well as its pros and cons. This activity has several benefits in that it helps you organize your thoughts by putting them on paper and sharing them with others. This increases the potential of selecting the right solution/approach. Moreover, it helps you clearly communicate the different options that are available to the project's architecture board and stakeholders. And on top of that, it helps you document your solution – something that your project sponsor will love you for. This is another example of a daily activity that can significantly help you prepare for the review board. Although you might not document the different solutions and tradeoffs in the same thorough way you do in real life, the principle of identifying different approaches, trade-offs, compromises, risks, and rationally justifying a particular solution is exactly what you are expected to do during the review board.

These are not skills that you should learn and master just for the sake of passing the review board; these are valuable skills and practices that you should make part of your daily routine. And when you do so, you will find out that you are getting closer and closer to becoming ready for the review board exam. The CTA certificate will simply become the cherry on top of the cake, an assertion that you possess all the required skills and that you know how to put them all into action.

The nature of the exam – a point collection exercise

Understanding the nature of the review board exam will help you prepare for it, and will prove to be particularly valuable during the presentation stage:

You will be requested to create an end-to-end solution and communicate it back to the judges. To do so, you will need to create a set of artifacts that will help you tell the solution as an engaging story. Your presentation should be executed in a way that will catch your audience's attention. Once you start the presentation, try to forget that you are in an exam room in front of judges; imagine yourself setting in front of a group of execs and CXOs from the company mentioned in the scenario. Forget for a moment that these judges work for Salesforce; put yourself in the right mood and mindset to present your solution to these client execs, who have solid technical knowledge about the platform and want to understand how you are planning to use it in order to solve their problems.The exam itself is a point collection exercise. You get points for identifying any solution requirements in the scenario. Every point counts. Some requirements are easy to spot and solve. For example, you might come across a security requirement that you can simply solve using field-level security settings. Don't overlook that or drop it from the solution story that you are going to tell. You might simply lose an easy point. However, during the Q&A stage, the judges will try to question you about the requirements that you didn't cover during the presentation. This will give you a second chance to cover them. Keep in mind that you have a limited time during the Q&A, and if you have many unidentified or non-solutioned requirements, then you could run out of time before you can cover all of them. This means losing valuable points that could be the difference between passing and failing.I have met many CTA candidates who dreaded the Q&A stage and I've always tried to explain that this stage should be considered as their friend, their opportunity to close some gaps caused by leaving things out, and an opportunity to express their knowledge, skills, and experience to some of the finest technical architects in the world. It is a time that the candidate should be looking forward to rather than fearing. It is true that you will be challenged and your knowledge will be put to the test, but this is exactly the moment where you can show the judges that you belong to the club – that you have got what it takes to join the very exclusive club of CTAs. You have to stay focused and be precise with your answers, and avoid wasting unnecessary time in describing things over and over again. Remember that the Q&A stage is your friend; you should try to make the most out of the available time. It is surprisingly similar to real-life presentations; the presenter will feel relieved when the audience starts to ask questions and the conversation becomes two-way instead of one-way.During the presentation, the judges might decide to change one of the requirements to check your ability to adjust quickly and get to the solution on the fly. Don't get nervous because of that, or automatically assume that they are doing so because you made a mistake somewhere. It is a part of the test.During the presentation (or the Q&A), you may figure out that you have made a mistake and decide to adjust. This is not a disaster. Don't lose your focus; the judges will also appreciate how you handle such difficult situations professionally and how you recover and get back on track. If you make a mistake, admit it professionally, explain the reason behind your early decision, and correct it. Also, explain in short how you would have handled such a requirement in a real-life project. However, keep in mind that if you make multiple mistakes, the likelihood of you passing will reduce.The judges are there to ensure that you have what it takes to create secure, scalable solutions based on the Salesforce Platform. It is good to let them know what you are thinking about and how you are making your decisions. This will help them understand your logic and therefore better understand the reasons behind making a decision that creates a sub-optimal solution. If you have valid reasoning and sound logic, then this will normally be taken into consideration. Most, if not all, of the scenarios you will be presented with can be solved in multiple ways. There is no one solution. The key thing to keep in mind is that your solution must be based on the right considerations and logic. This is a major skill that a CTA must have: the ability to think of the holistic solution, identify potential solutions, and rationally select a suitable one.Your proposed solution should be the best one you can think of from a technical perspective. You should not assume there are challenges that have not been mentioned directly or indirectly in the scenario. As an example, don't select a sub-optimal solution because you are worried about budgeting challenges that the client might have - only do this if that was mentioned in the scenario itself.Finally, always keep in mind that your given solutions must be presented based on the given requirements. Don't simply give a dry solution as if you are answering an exam on paper. Remember that you are supposed to be presenting to the CXOs of the client company and tie your solution to a requirement. This will attract the audience and make the overall picture much clearer. We will come across several examples of this during later chapters in this book.

Now that you understand the nature of the review board exam, let's move on and explore the artifacts you need to create in order to get solutions for the hypothetical scenario.

What kind of artifacts you need to generate and why

A Salesforce Architect is always aiming to create a secure and scalable solution that meets all required functionalities, and document them in a way that allows them to communicate them effectively with the stakeholders. This is applicable during the review board and while tackling a real-life implementation project. An architecture diagram is a graphical representation of a set of concepts that are part of an architecture. They are heavily used in software architecture and, when used effectively, can become a common language for documenting and communicating your solution.

Based on my experience, there are normally several discrepancies with projects in the way architectural diagrams are created. I have seen a lot of inconsistencies, a lack of detail, a lack of discipline, and fragmentation. In several cases, this can be traced back to the misuse of an architectural description language (for example, UML), or in some cases, the lack of using any standard at all. Sometimes, this is due to misunderstanding the value of the diagrams and relying on improper or inconsistent guidelines – and in some cases, a lack of architectural education.

In order to describe your Salesforce Technical Solution Architecture, you need the following artifacts:

Must-haves:

Actors and licenses

Data model diagram

System landscape architecture diagram

Role hierarchy

Development life cycle diagram

Good to have:

Process flows (in real-life projects, this is considered a must-have)

Environment diagram (in real-life projects, this is considered a must-have)

Contextual SSO flow

Other diagrams, such as a data flow diagram, mind maps, and so on

Remember

You can deliver your artifacts/diagrams using one or more of the following tools:

PowerPoint presentations

Flipcharts

Whiteboard (this is not transportable)

A combination of these

There is no right tool. You need to build your own habits and plans and use whatever works best for you.

There are a few things to keep in mind regarding these diagrams:

Quality: During the review board exam, you have a very limited amount of time to craft your solution and create your artifacts. The quality of your diagrams is not expected to be top-notch, but they can't be scribbled scratches. Keep this golden rule in your mind while creating your artifacts and diagrams: they have to be pretty and must be worthy of being presented to a CXO. In the real world, these diagrams must look perfect. During the review board exam, however, they can look less perfect, but they still have to be readable, understandable, communicate the right message, and show your professional attention to detail.Use the tool that best suits your skillset: Some architects are sharper when it comes to using PowerPoint, while others are better with hand-drawn diagrams. Don't feel restricted – choose the tool that works best for you and that you feel more comfortable working with.Horses for courses: Some tools work better for specific diagrams. Some diagrams are explained in a better way if they're drawn in an interactive environment – for instance, where the audience can see the diagram being created in front of them and relate it to a story that you are telling. A good example of this is an SSO sequence diagram. However, other diagrams are better shown pre-drawn due to the amount of time needed to create them. The data model diagram is a good example of this. Here, you need to choose the right tool for the right diagram (you must also consider the way you are planning to set your review board; in-person or virtual). For an in-person review board, I find the whiteboard more suitable for interactively drawn diagrams, while flipcharts and PowerPoints and better suited for pre-drawn diagrams and artifacts.

Now, let's discover each of these artifacts in detail.

The actors and licenses diagram

The importance of this diagram is derived from the need to clearly communicate the required Salesforce, feature, and third-party licenses with your stakeholders based on concrete use cases expected from each set of users. This diagram will help you do the following:

Identify the key use cases for each actor. These will help you determine the right license to use.Clearly communicate the role of each actor within your solution. In the real world, this should also help you calculate the number of required licenses, feature licenses, or third-party licenses. Moreover, documenting the scope of each role will help you answer the common What are these users expected to be doing? question, which tends to become more difficult to answer with time.

For this diagram, you need to consider the following:

Include all the actors mentioned in the scenario.Include all the required licenses, including feature and third-party licenses. Pay extra attention to community licenses. You need to understand the capabilities and limitations of each Salesforce license.Go for the best justified technical solution (license-wise). Don't think of non-standard approaches to cut down the cost. Avoid any pattern that could breach Salesforce terms and conditions.This doesn't have to be a diagram, but the standard actors and use cases diagram is a great fit for the purpose mentioned here. I personally find it particularly useful when it's drawn on a flipchart or a paper, but a bit difficult to create using PowerPoint, given the time restrictions. In this case, a bullet point list for the actors and licenses, along with a sub-list for activities/use cases, should do the trick.

What if I made the wrong decision and selected a license type that is not sufficient to cover the requirement?

Don't panic – accept the fact that you picked the wrong license, rectify that on the fly, and explain your rationale behind selecting the original license to the judges. We all make mistakes; it is how we handle the situation that matters most.

Now, let's take a look at an example. The following simplified actors and licenses diagram illustrates the activities/use cases related to three different personas, and the license(s) required by each:

Figure 1.1 – Actors and licenses diagram example

If there was an unclear reason for picking one license over the other, add the additional rationale behind your decision to the diagram/documentation. This will help the judges – or in real life, the stakeholders – further understand your vision and the drivers behind your decision.

The data model diagram

The data model diagram is one of the most crucial diagrams that you need to create. Without it, you can't explain your solution properly, neither during the exam nor in real life. This diagram will help you with the following:

Identify the custom objects versus standard objects used in your solution. Remember that standard objects come with pre-built functionalities and limitations, while custom objects have a different set of considerations (for example, some licenses have a limit on the number of custom objects that it can access). This diagram will help you identify and communicate your data model and the planned use of every object.Identify LDV objects. Although identifying LDVs requires more than the data model (it requires performing calculations based on the given scenario), having a well-documented data model can help you identify where things are likely to go wrong and where the data is likely going to grow more rapidly (for example, junction objects), which can help you craft a mitigation strategy.This diagram is also crucial for your sharing and visibility requirements. The type of relationships between objects has a direct impact on the records' visibility. This is something you cannot easily identify without a diagram that you can digest by taking a quick look at it.Your data model has a direct impact on your reporting strategy. By looking at this diagram, you should be able to tell where the data that's required for a particular report should be coming from.You can't create a solid integration strategy without understanding your underlying data model.

This diagram should include the following:

Relation types (master-detail versus lookup).Cardinality (one to many, many to many, and so on).Object type (standard versus custom versus external objects).Org-Wide Defaults (OWD) for each object.Must highlight LDV objects, though you must do the math for this (it is a good practice to include these somewhere on this diagram).The logical data model level should be fine for the review board exam (showing the key fields for each object). In real life, you have to create a physical-level data model (showing all fields).

Now, let's take a look at an example. The following simplified data model shows the relationships between a set of standard and custom objects:

Figure 1.2 – Data model diagram example

Highlighting the owner of the records of each object type will help you illustrate part of your sharing and visibility strategy. A legend to explain your diagram would also be a nice professional touch.

The system landscape diagram

This system landscape diagram will help you illustrate the systems included within your solution and the relationships between them. This is extremely important because it's likely that you are going to end up creating an integrated solution that spans multiple systems. The diagram will also help you identify and document high-level information about your integration interfaces. This will be the main diagram for describing how the data will be moving across the systems (unless you decide to create a data flow diagram).

Remember

You are creating all these artifacts to help you explain the end-to-end solution to your audience. It is important to understand why you need each diagram and how to use it. There is no point in creating the diagram if you don't know how to use it.

For this diagram, you will need to do the following:

Show all systems involved in the landscape architecture (including third parties, such as AppExchange products or external systems). In real life, you may also want to extend the landscape architecture so that it includes the key functionalities that are delivered by each system. During the review board, this might take more time than what you can allocate.Include the systems that you are planning to retire. Find a way to differentiate them from the other systems that you want to add or keep. Color coding is a good idea, but you can simply add a symbol next to the system to indicate its status. In real life, you are probably going to create multiple copies of this diagram, with each representing a snapshot in time.Show the proposed integration interfaces. You also need to include information such as the integration pattern, how you are planning to secure your channel, and the authentication standard used. You might find that adding all of that directly to the diagram makes it a bit too busy. Alternatively, you can use an interface reference/code on the diagram and create a supporting table with full details. Then, you can use both during the review board to explain your integration strategy.Remember to include SSO interfaces.Also, include any mobile devices that are part of your landscape. Add the type of the mobile app right next to that (Salesforce Mobile, Native Custom App, Hybrid App, or HTML5-based).

Now, let's take a look at an example. The following diagram shows the systems involved in a landscape where Salesforce is replacing a legacy CRM. You will also notice that it is integrated with external systems through an integration middleware (MuleSoft):

Figure 1.3 – System landscape diagram example

The following table describes the proposed integration interfaces:

Figure 1.4 – Proposed integration interfaces

Typically, you don't include data migration interfaces in a landscape architecture diagram. However, this could be beneficial, particularly during the review board, to explain what tools you are planning to use and what your proposed migration strategy is. Ensure you clearly differentiate that from the integration interfaces. Mixing data migration and data integration concepts is a common mistake.

The role hierarchy diagram

Data security and visibility is a key topic for a Salesforce architecture. The wrong data sharing and visibility architecture can significantly impact the performance of the solution and can create a major risk to compliance and security. There are several elements that form your overall data sharing and visibility architecture, including your data model, role hierarchy, territory structure, and the capabilities and limitations of some Salesforce licenses. The role hierarchy diagram is a common sharing mechanism, and that is why creating this diagram will help you explain your overall data sharing and visibility strategy. In real life, you might even want to include full documentation of your sharing rules.

This diagram should include the following:

A review board, where you must create a full role hierarchy for at least one branch. You don't need to create all the branches if they are simply copied variations of the illustrated branch. For example, if you are going to create a role hierarchy that includes the head of sales for each state in USA, there is no need to create branches for all the states, as long as you can show one or two full branches for some states and indicate that a similar approach will be followed for other states. In real life, you will have enough time to create documentation for the full hierarchy.Roles for partner community and customer community licenses as well.Any license type limitations. The actors and licenses diagram will be handy at this stage.

Now, let's take a look at an example. The following diagram shows a company hierarchy based on the USA:

Figure 1.5 – Role hierarchy diagram example