This chapter will continue exploring Salesforce-specific knowledge areas required to pass the CTA review board. This time, you will tackle the communication domain. This is the seventh and final knowledge domain a CTA must master. This chapter will give you the knowledge and teach you the soft skills required to pass this domain. Then, you will complete a hands-on exercise using a mini hypothetical scenario.
Communication skills are crucial for a CTA. These skills allow you to explain your vision in a clear and detailed way, ensuring that your audience fully understands how everything is going to work together. This skill incorporates several sub-skills, such as the ability to create a descriptive diagram that can help you explain your solution and how to handle unexpected changes in scope and adjust your solution accordingly.
You have already practiced creating presentation pitches in the last six chapters and used diagrams to describe the end-to-end solution. You learned that your presentation must be engaging and captivating; you should tell a story while walking your audience from one point to the next.
In this chapter, you are going to cover the following main topics:
By the end of this chapter, you will have practiced handling objections and adjusting a solution on the fly and learned some best practices across the broad communication domain. You will start by understanding what is expected from a CTA to master this domain and then move on to the mini hypothetical scenario, where you will put that knowledge into action.
Soft skills are essential for the modern-day architect as market expectations are higher than ever. The architect is expected to possess a solid technical background supported by an excellent ability to communicate a solution’s vision, target, and rationale. On top of that, the architect is expected to be able to walk the audience through the possible solution options, highlighting the pros and cons of each.
Note
According to Salesforce’s online documentation, you should be able to meet a specific set of objectives that can be found at the following link: https://packt.link/DGMnt
Next, you will have a closer look at each of these objectives.
While creating your solution, you will come across several use cases that can be fulfilled in one way or another. You saw this earlier, while developing solutions for the mini hypothetical scenarios in the previous six chapters.
During the review board, you have a limited amount of time and a lot of requirements to solve. When you present a proposed solution, you should focus on the considerations that would make a difference. These considerations should steer you away from one design decision to another.
In the end, you are not expected to list out the available options and take a step back but to come up with a crisp and precise solution for a given requirement. You are supposed to be the most senior Salesforce expert on a project. You should be the one confidently guiding other stakeholders to make decisions.
Note
Remember to provide a crisp, clear, and comprehensive solution. The three CTA judges will be seasoned, experienced architects. They will sense a lack of confidence. Do not bluff or rely on buzzwords. This is not an audience that will be impressed by buzzwords unless you can match them with solid, in-depth practical knowledge.
During the presentation, you have to present an end-to-end solution, just like a story would be told. You have to explain how your solution solves the problem. Take the following requirement as an example:
The sales manager needs to submit a new customer record for a credit check. The manager should be informed about the result as soon as the check is complete and receive an error if the check fails for any reason.
The following statement is an example of a dry, unattractive, and unengaging way of presenting a solution:
I will do the credit check via an APEX callout.
The judges are acting as CXOs representing the scenario’s client company. You are supposed to guide them and avoid dry answers to their questions. To help them, you need to continue with your presentation, point out or mention the requirement first, then explain your proposed solution. For example, you could start with something like the following:
On page three, paragraph two, we have the following requirement.
Then, you can briefly describe the requirement. Once you have done that, you proceed with the solution. Your response should explain the why and how with enough details. For example, the preceding statement could be rephrased like so:
If you are doing a virtual review board, it could be a good idea to arrange the requirements and proposed solution in an Excel sheet or a PowerPoint slide, whichever works best for you.
The key thing to keep in mind is that these are tools that you should use to help you propose your end-to-end solution. You should not simply go through your sheet and read the solution out; you should use diagrams to explain and visualize the solution, which is exactly what the next objective is all about.
The common language for architects is diagrams. Similar to human languages, certain diagrams represent a common language known and understood by peer architects.
In Chapter 1, Starting Your Journey as a CTA, you learned about the diagrams you need to depict an end-to-end solution and the level of detail required in each of these diagrams. There are several additional diagrams that an architect can use to explain a solution, including, but not limited to, the following:
These additional diagrams could be valuable to explain some aspects of your solution. They are rarely used during the CTA review board but are helpful in real life.
What you particularly need to avoid are the top three mistakes in creating architectural diagrams. You will learn about those in the following subsections.
In some cases, the architect might decide to mix multiple diagrams into one. This could be due to one of the following reasons:
The following is an example of a mixed diagram. The architect mixed a flowchart diagram with a landscape architecture diagram:
Figure 11.1: An example of a mixed diagram
Such non-standard diagram mixing will cause confusion at multiple levels, especially with complex processes. It will distract and confuse the reader with unnecessary details. Moreover, it will create a redundant version of information that is likely to exist elsewhere. For example, you will need to maintain the list of integration interfaces across both the landscape architecture diagram and flowcharts. This could lead to outdated information in some diagrams.
The desire to oversimplify a diagram could lead to creating a mixed diagram. In addition, this is one of the most common reasons for information loss in diagrams. As an architect, you are responsible for generating top-quality architectural diagrams. This is not the duty of a junior resource or a job that you can offload to someone else. You are responsible for the overall solution architecture, which makes you accountable for creating, or closely supervising, the creation of all the elements that are required to communicate and document the technical solution.
This is precisely what you are expected to develop and communicate during the CTA review board: the end-to-end technical solution design.
The following diagram is an example of an oversimplified data model:
Figure 11.2: An example of an oversimplified data model
You can quickly tell that this diagram will not help you understand the proposed data sharing and visibility strategy. It will not help you detect LDV (Large data volumes) or sub-optimal relationships. It will also not even help you understand the nature of the relationships between the objects or their cardinality. The arrows might even communicate the wrong message. This could be an example of oversimplification and a lack of standardization (which is the third common mistake that will be covered).
Next time you want to create a diagram, try to google and see whether there is a common standardized version of it. Look for templates and examples provided by purposely built diagramming tools such as Lucidchart, Visio, or Gliffy.
You will likely find a standard diagram that is suitable for your purpose. Do not try to search for something such as a solution architecture diagram because that is not just a single diagram. To describe an end-to-end solution architecture, you need multiple diagrams. You came across these diagrams and learned about their value in Chapter 1, Starting Your Journey as a CTA.
Note
Creating these diagrams should become part of your daily work, not something you do temporarily to pass the CTA review board. You need to continuously demonstrate your knowledge, values, and attitude as a CTA in live projects. Create these diagrams daily. This will help you develop architectural muscle memory and become quicker at creating these diagrams during the review board.
A good architectural diagram can help you organize your thoughts and spot gaps in your solution, answer questions before they are asked, explain your solution much more thoroughly, and handle objections, which is exactly what the next objective is all about.
Throughout this book, you have learned that there is no single correct answer. You can expect some challenges to your solution. Some of these challenges might drive some required solution changes. You need to rationally defend your solution but not be too stubborn about it. If you make a wrong decision, go ahead and admit it. Humans are prone to making mistakes; even the judges on the board and the architects in this business will have committed a fair share of errors in their careers.
The way you handle an objection is a skill that will be assessed. Defending your solution confidently is as important as showing maturity while receiving feedback and accepting it without losing control. A CTA will frequently come across such circumstances. If you make a mistake, admit it and demonstrate your skills by rectifying it on the fly.
The judges will also add or change some scenario requirements during the Q&A to test your ability to quickly and adequately react to the evolving requirements and solution on the fly. When that happens, make sure you understand the requirements first. Do not hesitate to ask for explanations (but do not waste too much time doing so either). Take a few seconds to think it through, then confidently present your solution.
You are now familiar with this domain’s expectations. Next, take a look at a practical example where you will use this knowledge to create an engaging presentation and handle objections.
The following mini scenario describes a challenge with a particular client. This scenario is slightly different from others as it has been tuned to raise tricky challenges that could be subjected to questions from the judges during the Q&A stage. In this scenario, you will not only provide a proposed solution but also defend that solution appropriately during a hypothetical Q&A.
The judges will challenge some of your proposed design decisions. You should expect a different type of challenge from each judge as they might have different personalities, strengths, and weaknesses.
The judges will also attempt to change some requirements during the Q&A. They might even introduce some new requirements. This is not an indication of an error on your end. Usually, the judges use this technique to test the candidate’s ability to solution on the fly. To pass this domain, you need to prepare yourself to handle objections. This is one of the vital soft skills for a CTA.
Moreover, you need to be able to solution on the fly. Some people refer to this as solutioning on your feet. The client might simply throw out a new requirement, and you are expected to understand it, challenge it (if needed), and provide a detailed solution that could fulfill it.
Note
Do not lose your focus or confidence when/if the judges start to ask questions and dig deeper into the requirements. Your lack of confidence will be obvious to the judges and reduce your chances of passing. Do not assume that these questions are being asked because you are not answering correctly or are doing something wrong. The judges could merely be checking whether you have the right soft skills and can handle such difficult situations that you will face in real life.
You need to go through the scenario once to build an initial picture of the required solution. Then, go through the requirements thoroughly and try to solve them yourself, followed by comparing them with the suggested solution. Try to practice explaining the end-to-end solution, as well as answering the Q&A challenges.
Without further ado, proceed to the scenario.
An innovative reseller sells a broad set of software services, including support services and maintenance. They operate across Europe and offer their products directly to their end customers via multiple channels. They have recently started a digital transformation involving Salesforce Marketing Cloud, Salesforce Service Cloud, and e-commerce. They are planning to use Service Cloud as the System of Record (SOR) for customer management.
The company has several requirements around customer matching, merging, and deduplication. This is considered key to the program’s success.
They have multiple back-office applications, including Oracle ERP, a custom-developed order management system, and several other home-grown apps. They are all hosted on-premises.
The company has recently acquired another digital services company that operates in the US only. The acquired company also uses Salesforce as its main CRM. It has been tuned for their specific business processes.
The company shared the following list of requirements:
The company is looking for your help and guidance with all its shared requirements.
You might have noticed that this scenario is a little light on details. This is intentional to allow more focus on the presentation and Q&A activities.
Give yourself time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. Once you have done that, you can go through the scenario step by step and create the solution, similar to what you did in the previous scenarios covered in this book.
The company is using Salesforce Service Cloud as the primary SOR for customer management. Moreover, they have acquired another company that also uses Salesforce as a CRM. However, it is a heavily customized org tailored to meet specific needs. It is having issues with data quality, particularly duplicate management. On top of that, they have several other applications that you need to integrate Salesforce with. The company landscape looks as follows for the time being:
Figure 11.3: Landscape architecture – first draft
Now that you understand the current situation, it’s time to go through the requirements.
You are all set to start tackling the company’s requirements, craft a proposed solution for each, and update the diagrams accordingly to help with the presentation. Start with the first requirement:
All of its enterprise apps need to utilize customers’ golden records.
First, you might consider using Salesforce’s native deduplication capabilities using duplicate rules. This makes sense because the company specified that they are considering Salesforce Service Cloud as the SOR. This is the system that is the authoritative source of truth for specific data (customer records, in this case).
However, the company also shared requirements that indicate they have issues detecting and managing duplicates. This could be because their matching algorithm is complex and probably relies on complex fuzzy logic. They also reported that they have concerns with merging duplicates.
Advanced matching and data merging are not capabilities offered out-of-the-box in Salesforce. This is the territory of Master Data Management (MDM). You learned about various MDM concepts and the three different implementation styles of MDM tools in Chapter 2, Core Architectural Concepts: Data Life Cycle.
Note
As a reminder, the three implementation styles are registry, consolidation, and coexistence. The latter two support the concept of the golden record.
To deliver the required functionality, you need an MDM tool that supports one of the two MDM implementation styles with the golden record concept. As mentioned several times in this book already, you need to familiarize yourself with product names from the Salesforce ecosystem. In this case, you can propose Informatica MDM.
Your proposed solution could be as follows:
This solution looks good and solid. However, the judges may still want to challenge your proposed solution, either to ensure that you really understand the topic (and you have not merely memorized it) or to test your communication skills and the ability to solution on the fly.
A judge might ask you the following:
How do you propose handling the existing duplicate data in the Salesforce Service Cloud org? And what would your strategy be considering the newly acquired Salesforce org?
These questions are normally clear and straightforward but do not expect to be spoon-fed. If you continuously fail to spot the question and answer it correctly, the judges might simply decide not to give you the points. Your answer should be crisp, clear, and to the point. You have limited time during the Q&A, and you should aim to make the most of it. Your answer could be as follows:
Make sure your answers are crisp and sharp. Be confident and consider the Q&A stage as an opportunity to share your ideas and thoughts in a limited time slot.
Update your diagrams, then move on to the next requirement:
The company would like to implement a new sales solution focused on retail execution.
The new solution should be used in all regions, and introduce a high level of standardization along with some room for minor changes.
But what is the right org strategy for the company to start with? The acquired brand has another Salesforce instance, which is heavily customized to meet their needs. The sales solution could be an extension of what they already have. Of course, you can assume that it is a complete replacement for their existing solution, then build your proposal based on that. The scenarios have not specified any details. Different assumptions could lead to entirely different logical answers. In any case, your assumption should be reasonable and not too far from what you would see in reality.
Once you have decided on the proposed org strategy, you need to come up with a solution that allows standardization with room for modification.
Your proposed solution could be as follows:
Your assumption might be sound, but the judges might decide to change or challenge your assumption, either because they find it unsatisfactory or because they want to test your skills further.
A judge might ask you the following:
What will change in your solution if you assume that the customized solution in the US org is all about retail execution?
In this case, the judge is changing the scenario to further check the logic behind your proposed org strategy. In addition, this is a test of your on-the-fly solutioning skills. Your answer could be as follows:
Remember to keep an eye on the stopwatch. The previous answer should not take more than 90 seconds of your Q&A time. Try to read it and rephrase it using your own words and measure the time it takes. You might need to repeat this several times until you feel confident about the results.
You could also be asked about the rationale behind selecting the specific middleware. In this case, they are most likely testing your knowledge of the integration domain. You need to explain the difference between an ETL and an ESB (which is covered in Chapter 3, Core Architectural Concepts: Integration and Cryptography).
They might even ask you how MuleSoft will be able to communicate with an on-premises hosted application. For MuleSoft, this would require setting up a Virtual Private Network (VPN) between MuleSoft CloudHub (assuming it is using CloudHub) and the client’s intranet. This is different from the secure agent mechanism that was covered in Chapter 9, Forging an Integrated Solution, which is used by other ETL tools.
Update your diagrams and move on to the next requirement, which starts with the following line:
The company would like to enable their reps in Europe with mobile apps that support offline functionality.
The critical requirement is to deliver a mobile app with offline capabilities to the agent. The requirement did not specify any additional information, so you will have to make some valid assumptions.
You can assume that the required offline capability is advanced and therefore requires a specific type of mobile application to fulfill it.
Looking back at Chapter 5, Developing a Scalable System Architecture, you learned about four different types of mobile applications that you can develop/use with Salesforce:
Note
You can find out more about the offline capabilities of the Salesforce mobile app at the following link: https://packt.link/r7xTe.
It is worth mentioning that the Salesforce mobile app can be branded using the Salesforce Mobile Publisher functionality.
Based on your assumption, you can propose a native app. Alternatively, you could have assumed that the standard Salesforce mobile capabilities are enough for this use case. However, in my opinion, it is a safer option to go with the former approach as the limitations of the Salesforce mobile app could be easily challenged by complex businesses, such as the company in this scenario.
This will answer half of the requirement. The rest of the requirement indicates a need to surface the data captured via the mobile application into Salesforce and seven other systems. This is another example where you might have more than one potential solution. The approach you choose will determine the challenges you might face during the Q&A stage. The following two possible options explain this:
Proposing this approach could raise several questions, including How can you authenticate to MuleSoft APIs? Is there an alternative approach that avoids caching data in MuleSoft? Besides, the required customizations in MuleSoft to achieve this are substantial, which could raise a few more questions and challenges.
Proposing this approach could raise a different set of questions. The judges might be curious to know why you picked this approach over an API-led approach utilizing MuleSoft, which promises a more reusable interface. They might also change the requirement to include the US instance, which will push you toward the first approach.
The following diagram illustrates both approaches:
Figure 11.4: An illustrative diagram showing two different approaches for the mobile application
It is always favorable to use simple architecture. The simpler the architecture is, the less likely things will go wrong unless the architecture is unable to deliver the desired functionality or produces a sub-optimal variation of it.
Note
The mobile application is going to deal with data coming from Salesforce only. The mobile app is not supposed to retrieve data from other applications or commit data to them directly, so assuming a need for an API that does complex orchestrations could be a overkill.
The requirement to surface the captured data in other systems could be simply interpreted as a need to replicate this data to other systems once it has been committed to Salesforce. Avoid unnecessarily complicating things for yourself in the solution.
Your proposed solution could be as follows:
The batch data synchronization approach is more straightforward than the near real-time fire and forget pattern. When offline users go back online, they will be synchronizing dozens of records. These records should be committed to Salesforce in the right order. However, committing a large number of records would fire several platform events from Salesforce.
Ideally, they should all go into the event queue in the correct order, be sent to MuleSoft (or other subscribers) using the same order, and be delivered with none missing. However, you can see that several things could go wrong with this approach. This will be an unnecessary complexity unless a near real-time data sync is essential.
The choice is yours, as long as you can justify it. Move on to the next requirement, which starts with the following:
The company currently maintains invoices in a custom object.
They have a requirement to share this record with the user specified in a lookup field. This sharing should be maintained even if the record owner is changed, and they should only share the record with the current user specified in the lookup field.
Similar to what you have done several times already, you will start by considering configurable functionalities. You will only move on to a custom-developed solution when you have concluded that the standard functionalities are incapable of delivering the requirements.
This requirement cannot be met with configurable platform functionalities. However, you know that the record owner can share the record manually with the target user. You can also automate this process and create share records using APEX. In this case, the APEX class will create an invoice__share record automatically to share the record with the target user.
Your proposed solution could be as follows:
Good enough? The answer is no.
One of the common challenges observed while coaching over a dozen and a half CTA candidates is the accidental jump over requirements. The candidate is under pressure to deliver the solution on time. In such circumstances, the candidate might miss or jump over requirements and fail to identify them.
In some cases, it might be a simple requirement with low or no impact on the solution. In other cases, it may have a significant impact. This may lead to the domino effect, where one hesitant solution change will cause other elements to fall apart. This is one of the most critical risks a candidate could face in the review board.
The best way to avoid it is by making sure you do not miss any requirements. Such an incomplete solution would definitely draw some questions from the judges, such as the following:
The requirement indicated that sharing should be maintained even if the record owner is changed. How would you achieve this using your solution?
This is a requirement you failed to spot and can backfire. A hesitant answer could be as follows:
The trigger will fire even on the change of the record owner. In this case, the code will continue to run, as described earlier.
A hesitant answer is usually much longer than that and this means that you are losing some valuable Q&A time. However, this answer could make things worse. The judges might now get the impression that you are unaware of the standard behavior associated with the changing of the record owner.
When a record owner is modified, the manual sharing records are automatically deleted. You might know that already, but the provided answer does not reflect this knowledge. Moreover, relying on the trigger to unnecessarily create share records is a sub-optimal solution, especially when there is a standard way to meet the desired requirement.
Some candidates might lose more than five precious minutes due to incorrect or incomplete answers, not counting the side conversations that such answers might spark.
A good answer, which would likely grant you the points associated with the requirement, could be as follows:
It would have been ideal if you included that statement in your original proposed solution. This would have saved the 30 seconds that were lost from your Q&A time.
Note
The Q&A stage is your friend. The judges will ask you questions to fill in any gaps and missed requirements. They will also ask questions that help them determine whether you have the skills and knowledge required to pass the exam. This time is very precious – make sure it is not wasted.
Some CTA candidates dread the Q&A as they consider it the most challenging stage of the review board. It is not. This is time given to you to close any gaps and prove that you have got what it takes to pass the exam.
That was the last shared requirement. Update all the diagrams and see how they look. The following is the landscape architecture diagram:
Figure 11.5: Landscape architecture – final
The following are integration interfaces:
Figure 11.6: Integration interfaces – final
That concludes the scenario and the solution too. You may have noticed that you only had a few diagrams for this scenario. This is because it is a mini scenario with a particular focus on communication. Things will look different in a full scenario.
In this chapter, you have dived into the details of the Salesforce communication domain. You learned what a CTA is expected to cover and the level of detail. You went through some practical examples of ways to present a particular solution and understood the importance of standard diagrams and the common types of diagrams you are likely to encounter.
Then you tackled a mini hypothetical scenario and had a hypothetical Q&A stage to practice handling objections. You also learned about some pitfalls to avoid and how to make the right professional impression during the CTA review board and in real life.
After that, you explored multiple potential ways to handle a particular requirement. You learned how one path can lead you to a completely different set of potential challenges and how to prepare for them. You also learned how to avoid difficult situations by merely striving for a simple solution where fewer things can go wrong.
This concludes the seven knowledge domains you need to master. In the next chapter, you will start your first full hypothetical scenario. You will be introduced to a full-sized scenario that you would need to solve using all the knowledge and techniques you have learned so far. Buckle up and get ready!