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:
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:
Now that we know what the CTA profile is, let's get to know the review board.
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:
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:
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:
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.
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:
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.
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:
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.
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:
Actors and licenses
Data model diagram
System landscape architecture diagram
Role hierarchy
Development life cycle diagram
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
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:
Now, let's discover each of these artifacts in detail.
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:
For this diagram, you need to consider the following:
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:
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 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:
This diagram should include the following:
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:
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.
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:
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):
The following table describes the 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.
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:
Now, let's take a look at an example. The following diagram shows a company hierarchy based on the USA:
Additionally, you can also include a list of sharing roles and other sharing mechanisms that you are planning to use, likely as an annexed table.
The business process flow diagram will help you illustrate and communicate the targeted user experience for a given process. This is a good to have diagram during the review board in terms of the value it adds, but also in terms of the time it takes to create. Practice creating these types of diagrams and decide if you will include them as part of your generated artifacts or not. Again, remember that we create these diagrams to help us explain the end-to-end solution, not just for the sake of creating diagrams. In real life, diagrams that explain each business process is a must-have. It is also strongly recommended that it's in standard BPMN 2.0 format as this creates a common language between team members and avoids you losing the required details and precision.
This diagram should include the following:
Now, let's take a look at an example. The following business process diagram describes a partner onboarding process. You can add as much detail as you wish for the given hypothetical scenario. In real life, this diagram is likely to be much more detailed:
Subprocesses help create reusable elements. It is recommended that you use subprocesses whenever applicable. However, this is perhaps more suitable for real-life scenarios rather than the review board.
Governance is another key knowledge area that you have to cover as part of your end-to-end solution. Part of it is your environment strategy; that is, what kind of environments you are planning to use and for what. If you don't create this diagram as part of your presentation, then you are likely going to be asked to draw it during the Q&A session. This diagram is a must-have in real life and can also drive some budget-related discussions.
This diagram should include the following:
We'll cover examples and more details related to this diagram in the chapters to come.
I recommend that you combine this with your source code branching diagram, assuming you have enough time to do so.
Most scenarios you get will have SSO requirements. This diagram (you might need more than one, depending on the used SSO standards) will help you walk your audience through the details of the target user experience without missing any points. If you didn't create this diagram as part of your presentation, then you are likely going to be asked to draw it during the Q&A session. A standard sequence diagram is highly recommended. This is one of the diagrams I personally find more suitable to be drawn in an interactive way (for instance, using a whiteboard).
For this diagram, take the following into consideration:
SAML IDP initiated
SAML SP initiated with deep linking
OAuth 2.0/OpenID Connect web server/Auth code
OAuth 2.0/OpenID Connect User-Agent
OAuth 2.0/OpenID Connect refresh token
OAuth 2.0/OpenID Connect JWT flow
OAuth 2.0 Asset token flow
We'll cover examples and more details related to this diagram in the chapters to come.
It is recommended that you include information regarding the data that's exchanged at each step of the sequence diagram.
In this chapter, you managed to get a better understanding of the typical CTA profile. You learned how this book is structured and how you can make the most of it, as well as how to utilize your day-to-day activities in order to train for the CTA review board. You now have a better understanding of the nature of the exam and some of its key considerations to keep in mind. We also took a deep dive into some of the key tools and artifacts that can help you create a secure and scalable end-to-end solution and communicate it to your audience.
In the next chapter, we will dive deeper into some key architectural skills and knowledge areas. These skills are common for enterprise and software architects, and we are going to understand how are they applicable to the Salesforce Platform.
Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.
If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.
Please Note: Packt eBooks are non-returnable and non-refundable.
Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:
If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:
Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.
You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.
Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.
When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.
For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.