5

Developing a Scalable System Architecture

As a Salesforce system architect, you are expected to lead the design of these solutions, utilizing the rich set of Salesforce products and features and third-party products and add-ons 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, you will dive deeper into the different Salesforce-specific knowledge areas required to pass the CTA review board. You will then put that knowledge into action by utilizing a mini hypothetical scenario with a particular focus on system architecture. You will solve that scenario step by step, creating a justified and crisp recommendation at each stage.

Here are the main topics that you are going to cover in this chapter:

• Understanding what you should know and be able to do as a Salesforce system architect
• Introducing the system architecture domain mini hypothetical scenario: Packt United Builder
• Determining the appropriate mix of systems and building your solution and presentation

Understanding What You Should Know and Be Able to Do as a Salesforce System Architect

A system architect is usually a talented technology specialist who defines the right IT strategy and the best tools, software, hardware, and network elements required to achieve enterprise objectives. A Salesforce system architect will obviously spend less time thinking about hardware components and more time solving platform-specific challenges, such as the right Salesforce org strategy, licenses required, mobile strategy, document management solution (DMS), and reporting and analysis strategy.

Note

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://packt.link/o3EDS.

You will now take a closer look at each of these objectives.

Determining the Appropriate Mix of Systems

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

During a real-world Salesforce implementation, you may come across non-technical challenges, such as budget limits. This is not the situation during the review board exam though. As a system architect, you should always aim to design the best solution technically, which can deliver high value to the customer in the shortest possible time using well-justified tools, features, and products.

Specialized solutions that can be configured to fulfill the customer’s needs typically provide a shorter time to market and a higher return on investment. Make yourself familiar with some of the common AppExchange solutions and some other third-party solutions. You must understand their capabilities, as well as when, where, and how to use them.

The CTA review board scenarios will normally include a decent number of requirements that can be fulfilled using native platform capabilities. Every time you suggest a third-party solution (whether this is via AppExchange or a completely different platform), make sure you have a well-justified reason for that. Cost should not be the main driver for your decision, as the client would normally benefit more from a well-designed technical solution and a shorter time to market.

Design Considerations for Reporting and Analytics

You need to know about the standard Salesforce reporting capabilities. The four standard report formats are as follows:

• Tabular
• Summary
• Matrix
• Joined reports

You need to get some hands-on experience with them to understand their capabilities and limitations.

Standard Salesforce reports are an excellent tool for reporting on data hosted on the platform with a limited number of records. However, they are not suitable for reporting on multi-million record objects nor on data that is not hosted on the platform itself. Trending and other reports that span multiple years tend to include many records; these requirements cause you to drift away from Salesforce’s standard reports immediately. Ensure you do your data volume calculations based on the numbers given in the scenario and, if required, on reasonable assumptions. Then, determine your reporting strategy accordingly.

When it comes to reporting requirements on a dataset with millions of records, you can consider options such as CRM Analytics (formerly Tableau CRM), Tableau, and other third-party BI tools, such as Power BI. You do not have to recommend a Salesforce product. The right solution is to recommend what you believe is the right solution, based on your knowledge and experience. Salesforce products are easier to integrate with each other and with the Salesforce Platform.

Org Strategy

This is one of the key decisions you need to guide your customer to make in real life and during the review board. You need to help your client decide whether the solution can be better delivered using a single Salesforce org or multiple orgs. Every time you come across this decision, you need to remember several key pros and cons of both approaches. Now, you will start by learning about single org approach.

Single-org

In this approach, your solution is delivered using a single Salesforce production org. This approach has the following pros:

• Users from multiple departments and business units can work together and collaborate on the same set of records.
• It is typically easier to introduce unified processes using this approach. Think of a unified sales process using the opportunity object across multiple countries.
• All the platform data is on a single instance; therefore, it is easier to build reports that use this data.
• Security configurations, policies, profiles, and permissions are all managed in a single place.
• You already know that data visibility can be controlled using several platform features. However, having the data on the same instance can make it easier to share between different users, business units, and departments if needed.
• Each user would typically consume one Salesforce license and use one set of login credentials.
• Integration interfaces are easier to maintain, considering that you are only dealing with one Salesforce org.
• It is easier to build a 360-degree view of the customer as you have all the platform data in one place.

However, this approach has the following cons:

• You need to keep any regulations that could prevent you from selecting this approach in mind.
• Since you might be accommodating several business units with different processes and requirements, the single org could grow quickly in terms of complexity. This means it might end up becoming very difficult to maintain.
• You have a higher chance of hitting the governor’s limits.
• Due to the org’s complexity and the fact that changes could impact many users and business units, innovations and changes could be slow and limited.
• The advantage you get in terms of maintaining all policies, profiles, and permissions in a single place could also be a disadvantage when these configurations grow too complex to maintain.
• Different teams could be working on conflicting features, which might end up breaking each other. A thorough regression test strategy is key in such an environment. A regression test is a type of software testing that checks and validates whether the recent software changes had adverse effects on any of the existing features.
• It is difficult to administrate locally.

Multi-org

In this approach, your solution is delivered using multiple Salesforce production orgs. They can be completely autonomous or designed to be in a master-child architectural style where a master org pushes or pulls data to/from multiple child orgs or is designed without a central org, where some of the orgs are connected directly to each other to exchange data. This approach has the following pros:

• Fewer chances of hitting the governor’s limits.
• Innovation and time to market are better than the single-org approach since changes that are made to each org do not impact the other orgs.
• Fewer chances of conflicts between different business units as they can work on their own orgs.
• Less complexity in general in each org.
• Easy to administrate locally.
• A better ability to handle different regulatory requirements.
• Higher flexibility with release cycles since each org can have its own.

However, it also has the following cons:

• It is difficult to get a unified process across multiple orgs. Even though you can partially facilitate this using deployment features such as unlocked packages, separate orgs are more difficult to govern and, therefore, are more likely to end up using different processes.
• Limited capability to collaborate with users from multiple orgs. Although some third-party products can partially bridge the gap, a single org will always provide much better capabilities in terms of collaboration.
• It is difficult (and time-/resource-consuming) to maintain the integration interfaces.
• Users who need to access multiple Salesforce instances will consume a Salesforce user license per instance. You may also need to introduce a single sign-on (SSO) capability to provide a better user experience.
• The cost of third parties could increase, depending on their licensing structure.
• Less capability to report on data across multiple Salesforce instances. However, you can use tools such as CRM Analytics or Tableau to bridge the gap.
• There might be a need for multiple release strategies, toolsets, and teams maintaining them.

You need to consider all these points and more while deciding on the most suitable org structure. Sometimes, you may come across a clear requirement that pushes you directly to one option. It is recommended to start by assuming a single-org strategy and update your assumptions while going through the multiple-scenario requirements.

Mobile Solutions and Strategy

There are four main types of mobile applications that you can consider in your solution:

• Salesforce mobile app (which is built and continuously updated by Salesforce). The Salesforce Mobile Publisher is a form of the Salesforce mobile app designed to allow you to easily create and publish a branded/customized mobile app for Salesforce Lightning apps or Experience Cloud sites. It is distributed as a standalone app.
• Native apps (which are apps built for specific platforms, such as iOS, using specific programming languages).
• Hybrid apps (which are apps built using cross-platform frameworks such as Apache Cordova (formerly PhoneGap), JavaScript, HTML5, and other technologies).
• HTML5 apps (which are HTML5-based apps, developed using web technologies such as JavaScript and CSS).

Each of these applications is most suitable for specific use cases. The following table can help you determine the right mobile strategy for your solution:

Figure 5.1 – Capability comparison between different types of mobile apps

You are expected to explain your mobile strategy as part of your solution while considering the scenario’s context and shared requirements. As a CTA, you are expected not only to simply list the different options but also to guide the audience to the right option based on their requirements, logical assumptions, and valid justifications.

Required License Types

You need to specify the required licenses for your solution, including any third-party licenses. For example, if your user uses a third party such as Conga Composer to generate PDF documents, you need to include that license in your solution.

You do not need to go into a granular level of detail during the review board. This will be required in your real-life solutions though (for example, during the review board, you can specify that you need a Conga CLM license, while in real life, you might need to clearly specify how many Conga CLM full user and Conga CLM request/view only user licenses you need). In real life, you have much more time to go through the full list of license types provided by the desired vendor to determine which of them would better fit your requirements. These lists keep changing, and you are not expected to memorize them.

For Salesforce licenses, it is normally enough to identify and use one of the main licenses, such as Sales Cloud, Service Cloud, Salesforce Platform, Salesforce customer community, Salesforce customer community plus, Salesforce Partner Community, CRM Analytics, Marketing Cloud, and Pardot.

Kindly note that as of the Spring’21 release, the Salesforce Community Cloud has been renamed to Salesforce Experience Cloud. However, the licenses are still called Salesforce customer community, Salesforce customer community plus, Salesforce Partner Community, and Salesforce Employee Community.

Note

You can make yourself familiar with the up-to-date list of licenses and their capabilities (particularly the objects and functionalities they are allowed to work with) by going to the following link: https://packt.link/XIy4g.

You can fairly assume the usage of Salesforce Enterprise edition for the review board scenario.

Determining the Right Document Management Solution

You have already learned about the different types of DMSs offered by the Salesforce Platform. You also briefly learned about some of the most common solutions on the market and how to connect them to Salesforce in Chapter 2, Core Architectural Concepts: Data Life Cycle. Make sure you get some hands-on experience with Files Connect (this is a Salesforce product that allows Salesforce users to access, search, and view documents stored in an external system such as Google Drive, Box, or Microsoft SharePoint).

Note

You can check out the full official guide using this link: https://packt.link/iFJXi.

Now, it is time to put all this knowledge into action. In the next section, you will be introduced to a mini hypothetical scenario that focuses on the system architecture domain.

Introducing the System Architecture Domain Mini Hypothetical Scenario: Packt United Builder

The following mini scenario describes a challenge with a particular client. You 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 chapter, go through the suggested solution, 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, proceed to the scenario.

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, building, management, and maintenance. It runs its own property development projects, as well as special bespoke projects for B2B and VIP B2C customers.

PUB has over five million B2C customers and around 100,000 B2B customers, in addition to a wide network of suppliers and contractors in around roughly 50,000 companies.

PUB manages around 100,000 properties worldwide. Each property has an average of 10 smart fire monitoring devices and security devices and sensors. All of them are connected to the internet and send status messages at least every 30 seconds. PUB expects its portfolio of managed properties to grow by 10% every year for the coming five years.

PUB has been struggling with its disconnected systems, leading to poor data quality and additional work for its employees. It has piloted a solution based on Salesforce in Italy and wants to roll that out to other regions. Each region has its own set of property development and management regulations that the business must adhere to.

PUB has also struggled in rolling out a universal mechanism to provision and monitor sensors in its managed properties. Currently, the data flowing from these sensors is gathered in multiple disconnected systems with low capabilities and value to the business.

Internal Stakeholders

The following PUB employees will be using the new system:

• 300 designers and property development specialists, who meet with customers, design bespoke properties and supervise the development process
• 10,000 project managers and engineers, who supervise the building teams and report on project progress
• 5,000 specialists, who look after minor properties and their scheduled maintenance
• 10,000 sales agents, who are responsible for managing the sales cycle of properties, maintenance contracts, and bespoke properties
• 100 regional directors, who need regular reports on property development progress, as well as sales and property management operations
• 50 property supervisors, who deal with cases reported across the managed properties and ensure the customers are served based on their agreed support levels

Next, you will learn more about external stakeholders.

External Stakeholders

PUB has also identified external users who will be using the system:

• Five million B2C customers: These are individuals who purchased or leased one or more PUB properties at a given point in time.
• 100,000 B2B customers: These are companies that purchased or leased one or more PUB properties at a given point in time. PUB believes that most of these records are up to date.
• 50,000 suppliers and contractors: These are companies that provide different services for PUB, depending on different types of agreements.

Now, go ahead and look at the requirements.

Requirements

PUB has shared the following requirements, which describe the current and desired solution. PUB uses several systems to run its business:

• PUB uses a single custom multi-lingual public website that provides company information, office addresses, phone numbers, and inquiry forms to prospective customers. PUB plans to retain the website and update it as needed to accommodate the new system.
• PUB uses seven different disconnected monitoring systems with no business logic built into them. These systems are hosted on-premises with publicly accessible web services that receive signals directly from the different sensors installed in the managed properties.

PUB finds little value in these systems and would like to replace them with the new system, which will act as a unified platform to receive, interpret, and react to the different signals received from the different types and models of used sensors around the world.

• There are four different ERP systems—one in the US, one in Europe, one in the UAE and the Middle East region, and one in Singapore and the Eastern Asia region. Due to regulatory requirements for fire and safety systems, these ERP implementations have different data requirements. For this reason, they have remained separate from each other.
• PUB uses a custom design application, tailored specifically to the designers who use it on their corporate tablets. The application is used by the designer to display and adjust the different design elements when discussing them with the client.

The application creates a PDF file as an output, which should ideally be kept with the set of documents that describe the property, such as the document that explains the location of the installed sensors.

Currently, all these files are stored on different systems in each region. PUB would like to use the new system as a centralized tool to store these documents in a structured and regionally compliant way. PUB has a preference to utilize its newly purchased Microsoft SharePoint Online software for this, as long as it can be fully integrated with the new system.

• PUB has a set of CRMs (not Salesforce, except in Italy) that are used to track the project’s development and sales activities, which are different by nature in each region. PUB would like all these disconnected applications to be replaced with the new system.

Some of these CRMs are integrated with PUB’s regional ERP systems. PUB would like to have the new system fully integrated with the ERP systems so that customer and order data can be replicated to the right ERP system based on the region.

• PUB has a central system that is used for scheduled maintenance operations. The system has had several challenges in the past and is now considered inefficient. PUB would like it to be replaced with a new system.
• All existing systems are connected with the corporate Azure Active Directory (AD) for internal users’ SSO. PUB would like to still have the new system utilizing Azure AD for SSO between the new system and the retained ERPs.
• Germany has rolled out a mobile application that allows employees to access the German CRM from anywhere in the world when they are connected to the internet. PUB would like to have something similar for the new system to be rolled out globally.

In addition to these points, PUB realizes that it also needs the following capabilities delivered as part of the new system to deliver the best customer experience:

• Customers should be able to download a PUB-branded mobile application to view their online account, raise tickets against their properties, and update their profile. The application should provide a modern and bespoke user experience and UI.
• PUB currently communicates little with its customers. PUB would like to be able to send regular marketing material to its customers based on their preferences.
• PUB realizes that the data that is gathered from the sensors in the managed properties could reveal valuable business trends that can help PUB deliver a better and more efficient service. The same is also applicable to the maintenance data. PUB would like to be able to analyze data from the past five years to come up with valuable market trends.

PUB would like to get your assistance in designing a scalable and future-embracing solution based on its shared requirements and vision.

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 you identify the different roles and personas involved and determine the licenses needed for each.

That paragraph on its own can give you a good idea of the type of licenses you will need, though you will need to go through the entire scenario before finalizing it. You can start by drawing the actors diagram. You will add the licenses to it after you have formalized a better idea for the solution. At this stage, the actors diagram looks as follows:

Figure 5.2 – Actors diagram (first draft)

The Requirements section describes the current PUB system landscape and how it sees the future landscape. This section also contains several hints that will help you determine the right org strategy and mobile strategy, in addition to some other requirements.

The structure of the CTA review board scenario could be a bit different, especially considering that full scenarios are much longer than this mini scenario. However, in most cases, there will be a section describing the current landscape, as well as several other sections providing multiple requirements that can help you determine the future landscape and other design decisions related to system architecture.

Diving into the Shared Requirements

Now, read through the requirements one by one and identify the different requirements in them so that you can add more elements to your solution. The first requirement starts with the following statement:

A single custom multi-lingual public website that provides company information, office addresses, phone numbers, and inquiry forms to prospective customers.

Based on this statement, you can start by adding the custom website to the future landscape. You already know that the Salesforce Core Cloud is going to be part of the solution, and you can utilize web-to-lead forms to provide an integrated mechanism for the inquiry forms. You can include all of this on your landscape diagram and integration interfaces. These artifacts will now look as follows:

Figure 5.3 – Landscape architecture and integration interfaces

Now, move on to the next paragraph, which starts with the following statement:

Seven different disconnected monitoring systems with no business logic built into them.

This is where you learn about seven IoT platform systems that PUB is not particularly a fan of. You can add these systems to the landscape diagram and highlight that they are going to be retired. Including the retiring systems in your diagram will help you tell the full story during the presentation.

Reading through the scenario, you understand that PUB is looking for a unified platform that can integrate with all kinds of sensors and provide some sort of intelligence. This is communicated via the statement reacting to the different signals received. The question here is, can you utilize the Salesforce Core Cloud as a platform to receive these messages? You can develop a good decision engine on Salesforce, but there are several platform limitations you should keep in mind.

The scenario mentioned that there are 100,000 properties worldwide, each with an average of 10 sensors, and each sensor sends two messages every minute. This means that every day, there are 100,000 * 10 * 2 * 60 * 24 = 2,880,000,000 messages being received. Even without considering the data storage required to store that number of messages, you can clearly see that this number would hit the governance limit of the number of inbound API calls.

Buying more allowance is not the right decision here, either. This is a very high-cost solution that is not justified, mainly because you are using the platform for something it is not designed for. Alternatively, you should consider an off-platform solution.

You could propose a solution that you are familiar with and know that it fulfills the requirements, or you could simply suggest a custom-built application hosted on top of a PaaS platform such as AWS or Heroku. PaaS platforms are designed to deal with such massive amounts of traffic; some even provide built-in modules to deal with IoT devices.

Selecting Heroku has its advantages as you can utilize Heroku Connect to sync data with Salesforce Core if needed. In real life, several other factors impact this decision. During the review board, you can simply play it safe and pick up Heroku just in case you need to utilize Heroku Connect to fulfill other requirements that you have not identified yet.

Do you need an ESB or an API manager to receive these messages before passing them to Heroku? Currently, there is no requirement that drives this decision. You can easily develop secure custom web services and expose them via Heroku. These web services are publicly accessible because Heroku itself is cloud-based. There is no requirement that justifies including an ESB in the landscape yet. The landscape architecture diagram and the integration interfaces table will now look as follows:

Figure 5.4 – Landscape architecture and integration interfaces (second draft)

Look at the next paragraph, which starts with the following statement:

Four different ERP systems. One in the US, one in Europe, one in the UAE and the Middle East region, and one in Singapore and the Eastern Asia region.

Based on this statement, these ERPs will continue to be part of the landscape, and you also learn new and important information. There are strict regulatory requirements regarding the way data is stored for fire and safety systems in each region. This could help you determine the right org strategy approach.

Remember that you are expected to determine the org strategy as part of your solution. You will find requirements that can help guide you; you can find one of these requirements here. It is recommended to start by assuming that the solution will be delivered using a single org, then go through the requirements one by one and, at each stage, reevaluate and determine whether that assumption is still valid.

In this case, the question that should come to your mind is, Can I meet these regulatory requirements using a single Salesforce org? Clearly, this was not possible with the ERP systems, so it is fair to assume that you would not be able to do that using a single Salesforce instance. Salesforce Shield cannot help you in this situation, and neither would the sharing and visibility settings.

Based on that, you should think of selecting a multi-org strategy. You need to justify your decision during the presentation without spending more time on the topic than you should. For example, you could summarize your decision in the following way:

I am proposing a multi-org strategy due to the regulatory requirement for fire and safety systems data. These regulations cannot be met using a single org. Therefore, I am proposing an org strategy where each region will have its own Salesforce org. Each org will be hosted locally within the region. I am also assuming that the Italian org can be repurposed to become the European org. The scenario did not specify the regulatory requirements exactly, so I am assuming that hosting this data within the same region would be sufficient to stay compliant. The scenario did not mention a need for a unified global process across regions either, so I am assuming that the four regional orgs are completely autonomous.

This statement justifies your rationale and explains the assumptions you used to come up with this decision. In most cases, the scenarios will be designed to allow you some room for assumptions. Be reasonable and logical with your assumptions and communicate them clearly. Reading and presenting the preceding paragraph should not take more than 60-90 seconds. Your presentation time is precious, and you should make the most of it.

Now, move on to the next paragraph/bullet point, which starts with the following line:

A custom design application, designed specifically to be used by the designers on their corporate tablets.

There are two requirements in this statement. The custom-built tablet application must use the new system to store the generated PDFs. Moreover, these PDFs must be stored in an enterprise-level DMS. With a clear preference from PUB to utilize Microsoft SharePoint for that, Files Connect is a strong tool you can use to expose documents stored in SharePoint in Salesforce. However, you need to think about how you will get the documents into SharePoint to begin with.

If you have already used Files Connect and are comfortable with its capabilities, then you can design your solutions based on it. Otherwise, pick a solution that you know works. Do not try to force every single requirement into a Salesforce feature just because you are doing a Salesforce exam. You need to propose a solution that you know works and rationally justify using it.

In this case, you can propose updating the tablet app so that it uses both the Salesforce software development kit (SDK) and SharePoint APIs. Then, it can use these APIs to upload the files directly into SharePoint. Files Connect can be used to expose these files in Salesforce later if needed. There is no such requirement yet. You will need to explain how you are planning to authenticate to SharePoint.

Dedicated mini scenarios for these requirements are provided in Chapter 6, Formulating a Secure Architecture in Salesforce. For the time being, you can explain your proposed solution for this paragraph’s requirements like so:

In order to meet the requirement to store the generated PDF, I am proposing updating the tablet app so that we can use SharePoint APIs to upload the PDF directly into SharePoint. I have assumed that the tablet app can be updated as it is custom developed. I have also assumed that it is a native app to allow the desired UI capabilities. Once the PDFs have been uploaded into SharePoint, they can be exposed to Salesforce using Files Connect. The actual files will continue to be stored in SharePoint, but only while their links are available in Salesforce.

I am also proposing updating the tablet app so that it uses the Salesforce SDK to retrieve information such as customer name and ID, which will be required to upload the PDF to the right location. The tablet app will authenticate to SharePoint and Salesforce using the OpenID Connect user-agent flow. Each PUB designer will have a user created in both SharePoint and Salesforce. I am assuming I can use the employee ID as a federation identifier to map the users across systems.

Please note that at this stage, you have no details about the IDP being used by PUB. However, a few paragraphs ahead, you will notice the following statement:

All existing systems are connected with the corporate Azure AD for internal users’ SSO.

You can now update your landscape architecture diagram and integration interfaces accordingly. Keep doing that on an incremental basis. You might need to change and redraw things at this stage. Therefore, it is recommended to start on scratch paper and then copy the artifacts into their final form so that you can make them look as professional as possible.

Now, move on to the next paragraph, which starts with the following line:

PUB has a set of CRMs (not Salesforce, except in Italy) that are used to track the project development and sales activities, which is different by nature in each region.

This seems aligned with the plan to utilize a multi-org strategy. PUB wants to integrate each of the regional ERPs with the new system, which will be based on Salesforce. Considering that you are proposing a multi-org strategy, it is fair to assume that each of these ERPs will be integrated with its counterpart regional CRM (that is, the regional Salesforce instance).

The next thing that should come to your mind is how to integrate Salesforce with PUB’s ERPs. Going back to the topics you covered in Chapter 3, Core Architectural Concepts: Integration and Cryptography, you know that these systems can be integrated in multiple ways. Considering the pros and cons you covered in that chapter about using middleware and considering the different tools, you should consider the following options:

• Utilize an ESB: Considering that ESBs are capable of handling complex orchestration requirements
• Utilize an ETL tool: Considering that ETL tools are designed for heavy-duty data replication

Note

You are expected to come up with the most suitable solution from a technical perspective. Lean architecture and the ability to scale for an enterprise should always be part of your target; both cannot be achieved with point-to-point integrations.

The scenario did not specify the number of records that are expected to be transferred between the systems. It also did not specify any orchestration requirements. You must make some assumptions here, clearly communicate them, and use them as the base for your proposed solution.

In the review board, you are expected to come up with a clear recommended solution based on the communicated requirements, assumptions, and logic. You can mention the other options, but you must clearly select and communicate the one you recommend.

You can explain your proposed solution for this paragraph’s requirements:

In order to meet the requirement of integrating the regional ERPs with the new system, which is based on Salesforce, I propose using an ESB as a middleware. There has been no communicated requirement describing the amount of daily data being exchanged between these systems.

ETLs are better at handling bulk data replications. Still, I assumed that the number of records is relatively low and therefore it is preferred to use ESB, considering its superior capabilities in handling data orchestration requirements, which is likely to be required by the enterprise. Considering that the new solution will be based on a multi-org strategy, each of the ERPs will be integrated with its regional Salesforce instance.

I have also assumed that the ESB will be cloud-based and regionally hosted to ensure that data never leaves the region. I am proposing MuleSoft as an ESB because it is one of the leading ESBs on the market with built-in Salesforce connectors.

Whenever you are proposing to use a third party, you must name it. You have come across two examples so far: you named the proposed PaaS platform, and now you have named the integration middleware. You do not have to pick Salesforce-owned products. You should pick a product that you are familiar with and that you know for sure will fulfill the requirement. Again, remember that you should cover this requirement without unnecessarily losing time. The preceding paragraph can be presented in 60-90 seconds.

Now, moving on to the next paragraph, which starts with the following line:

PUB has a central system that is used for scheduled maintenance operations.

This is a straightforward requirement. PUB wants to replace its legacy scheduled maintenance system with a new one. You do not need to be an expert in field service solutions, but you should be familiar with some of them and understand the capabilities they offer. In this case, your proposed solution could be as follows:

In order to fulfill this requirement, I propose using Salesforce Field Service. It can be configured to generate scheduled maintenance work orders, which would increase the efficiency of the field service and maintenance team.

Note

Remember to add Salesforce Field Service to your diagram. It is a package that gets installed in your org, so make sure your diagram reflects that. Also, do not forget to include the retiring legacy system. Once this diagram is ready, it will help you present your solution engagingly and attractively.

Now, move on to the next paragraph, which starts with the following line:

All existing systems are connected with the corporate Azure AD for internal users’ SSO.

The scenario is unlikely to clearly mention the system that acts as an identity provider. You should have enough market knowledge to recognize that Azure AD is one of the leading products in this space. Based on the scenario, it must be acting as the identity provider in this landscape. Make sure you include SSO interfaces as part of your landscape diagram and integration interfaces list.

Moving on to the next paragraph, it starts with the following line:

Germany has rolled out a mobile application that allows employees to access the German CRM from anywhere in the world when they are connected to the internet.

Clearly, this is a mobile application requirement. For these requirements, you should be able to select the right mobile strategy. You provided an example of this earlier with the tablet app. This paragraph does not contain enough information to help you select the right mobile strategy, but the next paragraph does. It starts with the following statement:

Customers should be able to download a PUB-branded mobile application to view their online account, raise tickets against their properties, and update their profile.

You can select a mobile strategy based on the Salesforce mobile app, a native app, a hybrid app, or an HTML5-based app. Considering that the application should be PUB-branded, you might think that the Salesforce mobile app is not suitable.

However, Salesforce has recently launched a new service called Mobile Publisher, which allows you to deliver a branded version of its mobile app to end customers. All possible mobile strategies can provide branding, access to an online profile, and integration with Salesforce.

However, the differentiating requirement is the one related to the UI. PUB is looking for a sophisticated and bespoke UI that drives a certain user experience. In this case, your best bet would be a native app. Your proposed solution could be as follows:

Considering the requirement of having a bespoke, modern, and sophisticated mobile UI, I propose developing this mobile application as a native app. Perhaps we can utilize the mobile app developed by Germany and update it to use the Salesforce mobile SDK, or simply build it from scratch. Customers would still utilize a customer community license to authenticate to Salesforce. The mobile app would utilize the OpenID Connect user-agent flow.

You need to explain the solution from end to end. Do not leave any loose ends, for instance, skipping the part explaining how the users would authenticate to Salesforce. Your solutions must be clear and solid. Note that for customers, you are proposing using Salesforce as the identity provider. This should be fine, considering that the scenario mentioned that Azure AD is mainly used for internal users.

Note

Remember to add the customer’s native mobile app and its integration interface to your artifacts.

Moving on to the next paragraph, it is as follows:

PUB currently communicates little with its customers. PUB would like to be able to send regular marketing materials to its customers based on their preferences.

The question that should come to your mind is: What is the most suitable solution in the Salesforce ecosystem for this requirement? You need significant customizations in core clouds to build this capability, and you will still run into different limitations.

An external system is an option, but the most obvious solution and the one that offers the best out-of-the-box integration with the core cloud is Marketing Cloud. Marketing Cloud can be used to segment customers based on their preferences. Your proposed solution could be as follows:

I am proposing using Marketing Cloud to fulfill this requirement. Marketing Cloud can be used to segment customers based on their preferences. Taking into consideration the regulation requirements, there will be a different Marketing Cloud instance per region. The standard Marketing Cloud Connector can be used to integrate the regional core cloud with its equivalent Marketing Cloud instance. The contact ID in the core cloud will be used as a subscriber key in Marketing Cloud.

There is a continuous growth of cross-cloud architectural concepts. As a CTA, you are expected to have a very solid knowledge of the Salesforce Platform (mostly, Force.com, or what is also known as core clouds). However, you still need to have some familiarity with the common tools and technologies from the Salesforce ecosystem and how they interact with each other.

Marketing Cloud is a very common element of today’s Salesforce landscape, and you need to have a basic understanding of its capabilities and how it integrates with the core clouds. It is worth mentioning that the Marketing Cloud Connector utilizes the OAuth 2.0 client credentials flow to authenticate to Marketing Cloud.

Note

You can read more about OAuth 2.0 client credentials flow and the Marketing Cloud Connector’s managed package at the following link: https://packt.link/g5ZJP.

Now, move on to the next paragraph, which starts with the following line:

PUB realizes that the data that is gathered from the sensors in the managed properties could reveal valuable business trends that can help PUB deliver a better and more efficient service.

The sensors’ data is stored in Heroku’s Postgres database, as per your proposed solution. PUB wants to make use of this data now in some BI operations. Earlier, you calculated a rough estimate of receiving 2,880,000,000 messages daily. This number will become even bigger if you are looking to report on data stored in the past five years.

Salesforce CRM Analytics is a solid analytics solution, but it is not designed to handle too much data like Tableau. However, before jumping to the conclusion that Tableau is the right solution, you need to analyze the requirement and think about what value you would get from storing that amount of data.

Most of the time, the sensors will simply send the same status message; except when something happens that impacts their readings. It is fair to assume that you can aggregate these readings using custom code, which would ensure that you are still getting the value of the data but without unnecessarily storing too much of it. You can develop that custom module on Heroku, and then use CRM Analytics on top of it to provide the required BI. Your proposed solution could be as follows:

Considering the amount of data received from the sensors, I propose developing a custom module in Heroku to aggregate the received readings and ensure we only keep data that could represent value to the business. This should reduce the amount of data to report on significantly. We can use a policy to aggregate all the sensors’ data that is more than a year old. We can then utilize CRM Analytics to provide high-value trending reports to the business.

Note

Keep in mind that the solutions you are suggesting here are based on assumptions and valid logic. However, that does not mean that they are the only solutions. There are multiple possible ways to solve these requirements, and they could be accepted by the CTA judges as long as they are based on logical assumptions and rationale.

With that, you have reached the end of the scenario. Congratulations! You have all that you need now to fine-tune your artifacts and deliver a ground-breaking presentation.

Now, revisit the actors’ diagram and try to add the licenses to it. You typically need to understand the business processes and draw the data model before you can determine the exact types of licenses you will need. There are no business process requirements included in this mini scenario. The full mock scenarios in Chapter 12, Practice the Review Board: First Mock, and Chapter 14, Practice the Review Board: Second Mock, will include those. Based on the scenario, you can assume that the sales process will be implemented using the available out-of-the-box opportunity management capabilities, which means that the sales agents would need a Sales Cloud opportunity.

Designers and property development specialists might utilize a set of custom objects to gather customer requirements and deliver the property design. However, they will most likely need access to the sales details, which are stored on the opportunity. Therefore, they would also need a Sales Cloud license. On the other hand, the project manager and engineer would work with custom objects only, which means you can utilize a Salesforce Platform license for them.

Property supervisors and maintenance specialists would need to deal with cases and entitlements. Therefore, they are assigned a Service Cloud license. Additionally, the maintenance specialist would need a Salesforce Field Service license. The regional director needs to report on sales opportunities, so they would also need a Sales Cloud license. Moreover, you can assume that they would be using trending reports from CRM Analytics. The B2C customer and B2B customer agents need access to the Salesforce community. The customer community license should be sufficient for this. In comparison, you can assume that the supplier/contractor would need access to the sold property, as well as any contracts related to it. You can use a Partner Community license for that and develop a specific Partner Community as part of the landscape.

Your actors and licenses diagram now looks much more interesting and can help you tell a story about the personas involved in this solution, what they are expected to do, and what kind of licenses they need:

Figure 5.5 – Actors and licenses diagram (final)

Now, take a look at the landscape architecture diagram:

Figure 5.6 – Landscape architecture (final)

Your integration interfaces table will now look as follows:

Figure 5.7 – Integration interfaces (final)

That concludes the first mini scenario. You can try to re-solve this scenario as many times as needed. It is recommended to attempt solving it with no time restrictions the first time, with the aim of creating the best possible artifacts and presentation pitches.

You can then try to add some time restrictions, such as a 90-minute limit, to create your end-to-end solution.

Summary

In this chapter, you have dived into the details of the system architecture domain. You learned what is expected from a CTA and the level of detail. You then tackled a mini hypothetical scenario that focused on system architecture and created some attention-catching presentation pitches.

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

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

Finally, you tackled some other challenges, such as recommending a DMS solution. You had to deal with the tricky part of determining whether an on-platform or off-platform solution is required to handle a particular requirement, such as mass IoT data consumption.

You are now ready to move on to the next chapter, where you will go through the second domain you need to master, that is, security.

Chapter Review Flashcards

Before you proceed to the next chapter, it is recommended that you go through the flashcards from this chapter first. These flashcards condense all the chapter concepts into smaller and easily manageable chunks that will help you with quick review and retention. By engaging with these flashcards, you will strengthen your understanding of key topics, identify areas that require further study, and build your confidence before moving on to new concepts.

The following image shows an example of the flashcards interface.

Figure 5.8 – CTA flashcards interface

To access the end-of-chapter flashcards from this chapter, follow these steps:

1. Open your web browser and go to https://packt.link/ctach5. You will see the following screen:

Figure 5.9 – Flashcards interface login

You can also scan the following QR code to access the website:

Figure 5.10 – QR code to access Chapter 5 flashcards

2. Log in to your account using your credentials. If you haven’t activated your account yet, refer to Instructions for Unlocking the Online Content in the Preface for detailed instructions.

After a successful login, you will see the following screen:

Figure 5.11 – Chapter summary and end-of-chapter flashcards

3. Click Start on a flashcards stack to begin your review.