Chapter 8: Creating a Lean Solution Architecture

In this chapter, we will continue with other Salesforce-specific knowledge areas that are required to pass the CTA review board. This is the fourth domain out of seven. We will go through the necessary knowledge and preparations for each domain and then complete a hands-on exercise using a mini hypothetical scenario.

In the digital world, the term solution architecture refers to the process of analyzing client needs, understanding the core of their problems, and determining the appropriate solution in order to provide measurable benefits to the business.

The solution architect is likely the most business-aware type of architect on a project. In order to pass the CTA review board, you have to possess both the technical skills and the ability to interpret the business needs and craft an end-to-end solution architecture. Your solution has to consider the capabilities and limitations of the platform. This domain is the glue that holds...

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

According to the Salesforce online documentation, the CTA candidate should meet a specific set of objectives that 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.

Selecting the right combination of declarative and programmatic functionalities

It might sound simple, but you need to keep in mind that every suggestion you come up with as a part of your CTA review board solution should be clear and justified. The Salesforce core cloud comes with plenty of different capabilities and out-of-the-box functionalities.

While designing your solution, you should start considering configurable functionalities first. Then, transition to programmatic solutions only when the configurations fall short of meeting the desired functionality...

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

The following mini scenario describes a challenge with a particular client. The scenario is tuned up to focus on challenges related to solution architecture specifically. But as you would expect, there are also requirements related to other domains, such as data and security.

As we did in the three previous chapters, we will go through the scenario and create a solution step by step. You are also advised to try the suggested solutions yourself unless you are already familiar with the described feature. You are also encouraged to try different solutions that could fulfill the requirements.

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 visiting angels...

Selecting the appropriate functionalities to build your solution and presentation

Give yourself time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. Then, let's go through it again, section by section, and incrementally build the solution.

Understanding the current situation

The first paragraph has some general information about PVA's business model. It also tells us important information about the different personas that are going to use the system. We now know that they have a marketing team, a sales operations team, and nurses. Each is doing a specific set of activities. Based on that, we can start creating a draft of our actors and licenses diagram. Your diagram could look as follows:

Figure 8.1 – Actors and licenses – first draft

I have included an assumed Nurse manager role in anticipation of needing someone to create and manage the nurses' schedule...

Summary

In this chapter, we dived into the details of the Salesforce solution architecture domain. We learned what is expected from a CTA to cover and at what level of detail. We discovered the process of selecting the right combination of configurable and programmable features to deliver a requirement, and we discussed some guiding principles in selecting third-party solutions to deliver value in a short time.

We then tackled a mini hypothetical scenario that focuses on solution architecture, and we solved it together and created some catching presentation pitches. We practiced the process of selecting the right feature to deliver functionality, and we learned that it is not enough to simply mention the name of the used feature, but you have to clearly and crisply explain how it is going to be used, end to end, with no gaps and no ambiguity. If it isn't clear for you, then it won't be clear to your client, and then you can't expect your team to be able to deliver...