Chapter 11: Communicating and Socializing Your Solution
In this chapter, we will continue with another Salesforce-specific knowledge area that is required to pass the CTA review board: communication. This is the seventh and final domain. We will go through the needed knowledge and preparations for this domain and then 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 of scope and adjust your solution accordingly.
We have already practiced creating presentation pitches in the past six chapters. Each time, we ensured we utilized our diagrams to describe the end-to-end solution. We learned that the presentation has to be engaging and captivating; you should be telling a story while walking your audience from one point to the next.
In this chapter, we're going to cover the following main topics:
- Understanding what you should be able to do while communicating your solution
- Practicing communicating a mini-hypothetical scenario – Packt Digital
- Articulating your solution and managing objections
By the end of this chapter, we will also have practiced handling objections and adjusting a solution on the fly. You will learn some best practices across the broad domain of communication. We will start by understanding what is expected from a CTA to master in this domain and then move on to our mini-hypothetical scenario, where we will put that knowledge into action.
Understanding what you should be able to do while communicating your solution
According to Salesforce's online documentation, the CTA candidate should be able to 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.
Communicating design decisions and considerations
Communication is one of the most critical soft skills needed in a CTA's arsenal. While creating your solution, you will come across several use cases that can be fulfilled in one way or the other. We saw this earlier while developing solutions for the mini-hypothetical scenarios in previous chapters.
During the review board, you have a very limited amount of time and a lot of land to cover. 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 the other.
In the end, you are expected to come up with a crisp and precise solution for a given requirement, not to list out the available options and take a step back. 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.
Provide a crisp, clear, and comprehensive solution
The three CTA judges are very seasoned and experienced architects. They can sense and smell a lack of confidence. Don't bluff or use extensive 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 give an end-to-end solution. Think of it as a story to tell. You have to explain how your solution is solving the problem. Take the following requirement as an example:
The following statement is an example of a dry, unattractive, and unengaging way of presenting a solution:
The judges are supposed to be CXOs representing the scenario's client company. You are supposed to guide them, not throw back dry answers to their questions. To help them keep up with your presentation, you can point out or mention the requirement first, then explain your proposed solution. For example, you could start with something like the following:
Then, you can briefly describe the requirement.
Once you've 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 artifacts are tools that you should use to tell your end-to-end solution. You can't simply go through your sheet and read the solution out; you have to use your diagrams to explain and visualize the solution, which is exactly what the next required objective is all about.
Demonstrating your visualization skills to articulate the solution
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, we listed the types of diagrams you need to describe an end-to-end solution. We also discussed 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:
- Flowcharts: This is a very common way to represent an algorithm. It describes the steps required to solve a particular task. Swimlane can be used to provide a better visual representation of the chart, especially complex processes.
- Data flow diagrams: This diagram provides a representation of the flow of data through systems or processes. Do not mix these with ERD diagrams or object diagrams.
- Wireframes: This type of diagram represents a visual skeletal framework of the solution's UI.
These additional diagrams could be valuable to explain some aspects of your solution. They are rarely used during the CTA review board but are very valuable in real life.
What you particularly need to avoid are the top three mistakes in creating architectural diagrams. We'll learn about those in the following subsections.
Mixed diagrams
In some cases, the architect might decide to mix multiple diagrams into one. This could be due to one of the following reasons:
- Underestimating the value of standard diagrams: The standard diagrams took years to reach the stage they are at. They are known by many architects and represent a common architectural language. Attempting to create a new language simply means that you will be the only one to speak it. Moreover, a newly created type of diagram would likely lack the desired maturity level.
- Lack of knowledge: The architect might be unaware of a standard way to create a specific diagram. This could also be due to the confusion created by a lack of standardization.
- The wrong impression that standard diagrams are too complicated: Sometimes, the desire to create something simple could mean miscommunicating valuable information. Moreover, the architectural diagrams are not only communication tools; they are frameworks to help the architect shape and refine thoughts. We touched base on some of this in Chapter 1, Starting Your Journey as a CTA. In short, as an architect, you should use your diagrams to create, validate, and communicate your solution. You don't create the diagrams as an after-thought of some already-delivered job.
The following diagram 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 is a likely cause of outdated information in some diagrams.
Oversimplified diagrams
We mentioned this earlier as a potential reason for mixing diagrams. This is also one of the most common reasons for information loss in diagrams. As an architect, you are responsible for generating architectural diagrams. This is not the duty of a junior resource or a job that you can offload on 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 won't help you detect LDVs or sub-optimal relationships. It won't 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 and next common mistake we will be covering).
Lack of standardization
The 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's suitable for your purpose. Don't try to search for something such as a solution architecture diagram because that is not just a single diagram. We have mentioned this many times throughout this book. To describe an end-to-end solution architecture, you need multiple diagrams. We listed and explained the value of each in Chapter 1, Starting Your Journey as a CTA.
Note
The practice of creating these diagrams should become part of your daily activities, not something you do temporarily to pass the CTA review board. You need to continuously demonstrate your knowledge, values, and attitude of a CTA day in, day out in real projects. Try to embed the activity of creating these diagrams in your daily work routine. This will help you develop an architectural muscle memory. Drawing these diagrams will become easier and quicker 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, and help you explain your solution in a much more thorough way, as well as handle objection, which is exactly what the next objective is all about.
Handling objection and unexpected roadblocks
We've mentioned several times in this book that there is no single correct answer. You need to expect some challenges to your solution. Some of these challenges might drive some solution changes, but you need to defend your solution and not be too stubborn about it. When you figure out that you made the wrong decision, admit it. Don't worry; we all make mistakes. The judges themselves made many mistakes in their careers, just like I did and just like any other architect in this business.
The way you handle an objection is a skill that will be assessed. Showing confidence in defending your solution is as important as showing maturity in receiving feedback and accepting it without losing control. A CTA will come across such circumstances daily. If you made a mistake, show courage in admitting 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 solve on the fly. When that happens, make sure you understand the requirement first. Don't be shy about asking for explanations (but don't lose much time doing so as well). Take a few seconds to think it through, then confidently present your solution. Trust yourself; if others have managed to do it, then surely you can too.
Now that you are familiar with this domain's expectations, let's take a look at a practical example where we will use this knowledge to create an engaging presentation and handle objections.
Practicing communicating a mini-hypothetical scenario – Packt Digital
The following mini-scenario describes a challenge with a particular client. This scenario is slightly different from the 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, we will not only provide a proposed solution, but we will 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. After all, we are human, and we all 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 doesn't mean that you did or are doing something wrong. This is all part of the test. To pass this particular domain, you need to be able to handle the objection. This is one of the vital soft skills for a CTA.
Moreover, you need to be able to solve on the fly. Some people refer to this as solving 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.
Remember
Don't lose your focus or confidence when/if the judges start to ask questions and dig deeper into requirements. This will be obvious to the judges and will reduce your chances of passing. Don't 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, which, for sure, you will face in real life.
Similar to the other scenarios, you are also advised to go through the scenario once to build an initial picture of the required solution. Then, you should go through the requirements one by one and try to solve them yourself, then compare them with the suggested solution. Try to practice presenting the end-to-end solution, as well as answering the Q&A challenges.
Without further ado, let's proceed to the scenario.
The scenario
Packt Digital (PD) is an innovative software reseller. They sell a broad set of software services, including support services and maintenance. They operate across Europe, and they 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 eCommerce. They are planning to use Service Cloud as the system of record for customer management.
Current situation
PD has several requirements around customer match, merge, 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.
PD has recently acquired another digital services company that operates in the USA only. The acquired company also uses Salesforce as its main CRM. It has been tuned for their specific business processes.
Requirements
PD shared the following list of requirements:
- All of PD's enterprise apps need to utilize the customers' golden records. They also need to be able to enrich some of the values periodically. PD is looking for your guidance to provide recommendations around the tools and strategies to implement this requirement best, as well as ensure it scales up as more brands are brought into the system.
- PD would like to implement a new sales solution focused on retail execution. The solution should serve all regions using a standardized business process wherever possible, with room for minor localization. The solution should also be integrated with the rest of the enterprise apps, such as the order management system. PD is looking for your help to determine the right org strategy for their plans.
- PD would like to equip their reps in Europe with mobile apps that support offline functionality. This should help the reps operate in all locations and regions. The data that's captured via the mobile application needs to be surfaced in Salesforce and seven other different applications. They are looking for your guidance to determine the right mobile strategy, as well as their integration strategy.
- PD currently maintains invoices in a custom object. They need 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 should share the record only with the current user specified in the lookup field.
PD is looking for your help and guidance with all of their shared requirements.
Articulating your solution and managing objections
You might have noticed that this scenario is a little bit light on the details. This is because we want to focus more on the presentation and Q&A activities and handle them in the best way possible.
Give yourself time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. Once we've done that, we can go through the scenario step by step and create our solution, similar to what we did in the previous scenarios we covered in this book.
Understanding the current situation
PD is using Salesforce Service Cloud as the primary system of record 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. PD is having issues with data quality, particularly duplicate management. On top of that, they have several other applications that we need to integrate Salesforce with. The PD landscape looks as follows for the time being:
Figure 11.3 – Landscape architecture – first draft
Now that we understand the current situation, let's go through the requirements.
Diving into the shared requirements
We are all set to start tackling PD's requirements, craft a proposed solution for each, and update our diagrams accordingly to help us with the presentation. Let's start with the first requirement.
All of PD's enterprise apps need to utilize the customers' golden records
First, you might consider using Salesforce's native deduplication capabilities using duplicate rules. This makes sense because PD specified that they are considering Salesforce Service Cloud as the system of record (SOR). By definition, this is the system that is the authoritative source of truth for specific data (customer records, in this case).
However, PD 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 land of MDM. We covered various MDM concepts and the three different implementation styles for MDM tools in Chapter 2, Core Architectural Concepts – Data.
Tip
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 PD functionality, we need an MDM tool that supports one of the two MDM implementation styles with the golden record concept. As I've mentioned several times already, you need to familiarize yourself with product names from the Salesforce ecosystem. In this case, we can propose Informatica MDM.
Your proposed solution could be as follows:
This 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 haven't merely memorized it) or to test your communication skills and the ability to solve on the fly.
A judge might ask you the following:
These questions are normally clear and straightforward, but don't expect to be spoon-fed. If you are continuously failing to spot the question and answer it correctly, they might simply decide not to give you the points. Your answer should be crisp, clear, and to the point. You have very limited time during the Q&A, and you should aim to make the most of it. Your answer could be as follows:
Remember, crisp and sharp answers. Don't be nervous. A real CTA enjoys bouncing ideas off others. Consider the Q&A stage as an opportunity to share your thoughts in a limited time slot.
Update your diagrams, and then move on to the next requirement.
PD would like to implement a new sales solution focused on retail execution
The new solution should be used in all regions, and it should introduce a high level of standardization but with some room for minor changes.
But what is the right org strategy for PD 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 of their existing solution, then build your proposal based on that. The scenarios haven't 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've 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 it, either because they find it unsatisfactory or because they want to test your skills further.
A judge might ask you the following:
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 for your on-the-fly solving skills. Your answer could be as follows:
Remember to keep an eye on the stopwatch. The previous answer should take no 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 to do so. 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 likely testing your integration domain knowledge. You need to explain the difference between an ETL and an ESB (we covered this earlier 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 we explained 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.
PD would like to equip their reps in Europe with mobile apps that support offline functionality
The critical requirement here is to deliver a mobile app with offline capabilities to the agent. The requirement didn't specify any additional information, so you 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, we came to know four different types of mobile applications that we can develop/use with Salesforce:
- Salesforce mobile app: The standard app that's developed and maintained by Salesforce. It provides a rich set of configurable functionalities and a modern UI. However, it has limited offline capabilities. You can find out more about the offline capabilities of the Salesforce mobile app at the following link: https://help.salesforce.com/articleView?id=salesforce_app_offline.htm&type=5.
It's worth mentioning that the Salesforce mobile app can be branded using the Salesforce Mobile Publisher functionality.
- Hybrid apps: Custom-developed cross-platform mobile applications. They typically have limited offline capability.
- HTML5 apps: Cross-platform mobile apps developed using HTML5. They have a very limited offline capability by nature.
- Native apps: Custom-developed mobile apps, targeted at specific platforms such as iOS and Android using specific programming languages. You can develop native mobile applications with advanced offline capabilities. This includes the ability to cache a considerable number of records, store them safely in encrypted storage, and sync them back to Salesforce whenever the connection to the internet is restored.
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 PD.
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:
- The mobile application can communicate directly with an API layer exposed by MuleSoft. This, in turn, would communicate with Salesforce and the seven other systems. This could happen in a parallel or sequential manner, where the changes are pushed to the other seven systems only after being accepted and committed in Salesforce.
Proposing this approach could raise several questions, including How can we 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.
- The mobile application can communicate directly with Salesforce. Once the data has been committed to Salesforce, it can be replicated to the other applications in many different ways, such as batch sync using MuleSoft, asynchronous platform events, or CDC.
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 USA 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
I am always in favor of a simple architecture. The simpler the architecture is, the less likely things could 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 exaggerated.
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.
Your proposed solution could be as follows:
The batch data synchronization approach is more straightforward than the near-real-time fire-and-forget pattern. Think about it: when offline users go back online, they would 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 right order, sent to MuleSoft (or other subscribers) in the correct order, and should all be delivered with nothing missing. However, you can see that several areas could go wrong in this approach. Unless a near-real-time data sync is essential, this will be an unnecessary complexity.
The choice is yours, as long as you can justify it. Now, let's move on to the next requirement, which starts with the following.
PD 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 we've done several times already, we will start by considering configurable functionalities. We will only move on to a custom developed solution when we have concluded that the standard functionalities are incapable of delivering the requirements.
This requirement cannot be met with configurable platform functionalities. However, we know that the record owner can share the record manually with the target user. We 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 I 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 in 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. In my opinion, 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 don't miss any requirements. Let's continue with our proposed solution. Such an incomplete solution would definitely draw some questions from the judges, such as the following:
This is a requirement we failed to spot. It came back to bite us. A hesitant answer could be as follows:
A hesitant answer is usually much longer than that, I am afraid, and this means that you are losing some valuable Q&A time. However, this answer made things worse. The judges might now get the impression that you are unaware of the standard behavior associated with the record owner's change.
When a record owner is modified, the manual sharing records are automatically deleted. You might know that already, but the provided answer doesn't reflect this knowledge. Moreover, relying on the trigger to unnecessarily create share records is a suboptimal solution, especially when there is a standard way to meet the desired requirement.
I am not going to proceed further with the different conversations that incorrect or incomplete answers might spark. However, I have seen candidates losing more than 5 precious minutes in such cases.
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 you 30+ seconds lost from your precious Q&A time.
Remember, please!
I've mentioned this several times already and will repeat it here again. The Q&A stage is your friend. The judges will try to ask you questions to fill in any gaps and missed requirements. They will also ask questions that help them determine whether you have what it takes to pass the exam. This time is very precious, so don't waste it.
Some of my mentees were dreading the Q&A. They considered it the most challenging stage of the review board and looked at it as a tough time to survive. It actually isn't. This is a time given to you to close any gaps and prove that you've got what it takes to pass the exam.
That was the last shared PD requirement. Let's update all the diagrams and see what they look like. The following is the landscape architecture diagram:
Figure 11.5 – Landscape architecture – final
The following are the integration interfaces:
Figure 11.6 – Integration interfaces – final
That concludes this scenario. You may have noticed that we only had a few diagrams for this scenario. This is only because it is a mini-scenario with a particular focus on communication. Things will look different for a full scenario.
Summary
In this chapter, we dived into the details of the Salesforce communication domain. We learned what is expected for a CTA to cover and at what level of detail. We went through some practical examples of ways to present a particular solution, and we also understood the importance of standard diagrams and the common types of diagrams you are likely to encounter.
We then tackled a mini-hypothetical scenario, and we included a hypothetical Q&A stage to practice handling objections. We solved the scenario together, handled specific challenges, and asked questions. We also learned about some pitfalls to avoid and how to leave the right professional impression during the CTA review board, as well as in real life.
After that, we explored multiple potential ways to handle a particular requirement. We learned how one path can lead you to a completely different set of potential challenges and how to prepare for them. We 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, we will start with our first full hypothetical scenario. You will be introduced to a full-size scenario that we need to solve using all the knowledge and techniques we've learned so far. Buckle up and get ready!