Chapter 5: Developing a Scalable System Architecture

Designing scalable solutions is a challenging task. Scalable solutions include solutions that perform well under huge customer demands or during a particular demand spike, as well as those solutions that can continuously add value to the business and enable it to embrace futuristic market trends without compromising the quality of the service.

As a Salesforce system architect, you are expected to lead the design of such solutions, utilizing the rich set of Salesforce products as well as third-party products and applications from the ecosystem. You must do all this while keeping the desired user experience, the imposed governance limits, and the nature of the client's business model in mind.

In this chapter, we'll start to dive deeper into the different Salesforce-specific knowledge areas required to pass the CTA review board. We will then put that knowledge into action by utilizing a mini hypothetical scenario that...

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

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

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

Determining the appropriate mix of systems

The Salesforce platform is a fantastic tool that can deliver value to customers. However, it is not a solution for every challenge that you can come across. The Force.com platform provides a SaaS solution in a multitenant environment. As someone with good experience with the platform, you should understand that there are several governor limits that you need to keep in mind.

In addition, you should always aim for the best solution technically, which can deliver high value to the customer in the shortest...

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

The following mini scenario describes a challenge with a particular client. We will go through the scenario and then create a solution step by step. To get the most out of this scenario, it is recommended that you read each paragraph, try to solve the problems yourself, and then come back to this book, go through the suggested solution, and compare it to yours and take notes.

Note

Remember that the solutions listed here are not necessarily the only possible solutions. Alternate solutions are acceptable as long as they are technically correct and logically justified.

Without further ado, let's proceed to the scenario.

The scenario

Packt United Builder (PUB) is a global property developer. It has 200 offices across 20 regions, including 15 US states, France, Germany, Italy, UAE, and Singapore. PUB provides services that include property design, build management, and...

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

You would typically start by quickly skimming through the scenario to understand the big picture and build some initial thoughts about the solution. Then, you should go through the scenario again, section by section, and incrementally build your solution.

Understanding the current situation

Starting with the first part of the scenario, the sections starting with the statements The following PUB employees will be using the new system and PUB has identified external users who will also be using the system can help us identify the different roles and personas involved and determine the licenses needed for each.

However, that paragraph on its own can give us a good idea of the type of licenses we will need, though we will need to cover the entire scenario before we can finalize it. We can start by drawing the actors diagram. We will add the licenses to it once we have formalized a better idea...

Summary

In this chapter, we dived into the details of the system architecture domain. We learned what is expected from a CTA to cover and at what level of detail. We then tackled a mini hypothetical scenario that focused on system architecture, and we solv it together and created some effective presentation pitches.

We had to make several design decisions during the solution, all while making some assumptions and a lot of justifications. In real-life projects, you need to document all of these design decisions to avoid losing any valuable information in the future.

We then came across the challenge of determining the right org strategy, and we provided a clear, justified recommendation based on the shared requirements. We also tacked the challenge of coming up with a mobile strategy. We provided a clear list of required licenses and explained why we believe they are the most suitable ones for each group of users.

Finally, we tackled some other challenges, such as recommending...