A Certified Technical Architect (CTA) is the pinnacle credential anyone can hold in Salesforce ecosystem. You can say, they are rare to find in Salesforce ecosystem like unicorns.
What is a Salesforce Technical Architect?
A Salesforce Solution Architect is someone who has been certified for demonstrating the capabilities to build and design solutions across Salesforce platforms.
Below are list of top 10 tips for the Salesforce Certified Technical Architect (CTA) exam by Mitesh Mistry.
Confident and Self assured
Tips 1: A good architect is always confident and self assured, but remains honest to their knowledge. Present your solution confidently in the review boards, but also be honest on where you may have a knowledge gap. ‘I’ll get back to you on that’, is always better than a white lie :-). And secondly, confidence in delivery of your presentation is half the battle so make sure you deliver your solution with faith, conviction and confidence.
Large Data Volumes Management
Tips 2: This one relates to large data volumes and LDV management. It will sound common sense but a lot of people still architect this incorrectly. Typically speaking objects with a volume > 1M records can be considered an LDV object. As a CTA, it’s really important to know and be able to articulate what performance implications an LDV scenario can cause on the Salesforce platform. It’s a good sentence to add to justify you know the situation, but the importance of the LDV situation as well in terms of performance impact in Salesforce, specifically mentioning what areas of Salesforce can get slowed down.
Governance and deployment
Tips 3: Today’s tip is around governance and deployment. When looking at the deployment strategy for a project as a whole, once should consider all aspects of the deployment, and not just the Salesforce environments. If you are building a native or hybrid app for example that will leverage the Salesforce Mobile SDK, then you must consider the environments for that application build as well and what matching environments / builds you’d spin up for that app and how you will promote the code base for the mobile application as well. Consider this also as part of your sandbox deployment strategy for a more complete view on your overall deployment / environment management / code promotion approach.
Tips 4: is about oAuth flows, security and Single Sign On. The standard diagrams that we have seen describe single type oAuth Flows ie: User Agent, Web Server etc. Have you ever thought of drawing a flow within a flow. A typical example can be the following: I have built a custom mobile app to interact with Salesforce using the Salesforce Mobile SDK, but in our Salesforce org we have implemented SSO for all users using an IDP such as Ping Federate and we have external users who are going to be authenticating using a custom built mobile authentication.
How will you draw this authentication and authorization journey? Another such example is Social Sign On using a custom mobile app for a Community Cloud user? It’s a flow within a flow – practice drawing these for the board as these are the real kind of scenarios that can appear. It is not good enough just to memories the oAuth and SSO flows, you need to understand them and know how to apply them.
Tips 5: folks is around Data Migration. Simply saying the buzzwords: extract, cleanse, transform and load is not good enough. You must be mindful of what steps you would take within these. Lets get specific. If you are going to load data into Salesforce as the last stage of a data migration, what things would you turn off / enable? Or, in what state would you get your data to before loading it into Salesforce? Give these things a think and have a more detailed plan in your back pocket as a CTA!
Tips 6: is around Integration. Salesforce has their buzzwords (RPI-Request-Reply, RPI-Fire&Forget, Batch Data Sync) which are obviously great to know and good to put down in your answer. But, behind this you really need to have a solid and practical understanding of how an integration flow would work. Lets take an example. If you are going to synchronize a change to an Account record from Salesforce to SAP, how exactly would you do it? How would you notify middle ware of the change? What would you do in the event of an error occurring? Would you block edits to the record whilst a sync is in progress? Think about these things and have a solid flow and approach in your CTA toolkit before appearing for the board.
A very important point, which I cannot stress enough is make every effort to ensure your data model is right in the review board. Relationship choices, record owners, role hierarchy and OWDs can make a material impact to the strength and validity of your data model and overall solution. If there is any one tip that I would mark as #1 it would be this. Be a modelling champ, your solution rests on it.
Sharing. Probably one of the most important areas of the CTA is how you fulfill the data visibility and sharing requirements. Each rule makes you re-evaluate your data model to see if it supports the requirements and allows the sharing rules to be implemented in a declarative manner. Also consider the situations where you may need to use some ‘special’ approaches such as Apex Sharing and Lightning components leveraging ‘Apex without sharing’ in the Apex class. Trust me on this one, this is an area that can make or break your solution, so give it the importance it deserves.
Tips 9: I come back to the topic of Mobile. It’s great to know the difference between Native, Hybrid and HTML5 based mobile applications. You must be very clear on which approach is preferred in your solution, and be able to very clearly justify why you picked a certain approach. Consider things like: build time, build cost, roll-out time, use of Salesforce Mobile SDK, cross platform comparability, availability of skilled resources to build the applications, impact on delivery schedule and offline capability. Most importantly, your choice justification should be based on specific points which you gathered from the scenario and not just a blanket recommendation.
CTA Pro Tip 10
So final tip in the 10 tip series are a couple of less technical pointers for the review board:
- Fill the judges with the confidence that if they were not able to continue on a project and you had to replace them, then you’d do a smashing job.
- Be slick, professional and knowledgeable in your presentation. Use the 3-4 months before to board to have a solid presentation approach nailed. Know your 10-11 slides, and know exactly what you are going to say in each word. Don’t just know the buzzwords but understand them as well.
- Don’t get flustered. It is easy sometimes when we see a challenge that looks difficult to get flustered and convince our minds that we cannot solve it. Be calm, thinking calm and solution calm – you will land upon an answer.
- Sometimes there isn’t a right or wrong answer in a key area, but make sure you can justify your solution choice. This is particularly important when making a single or multi org decision in your solution as the rest of your solution will no doubt hang on it (Role Hierarchy, Sharing especially). So choose a route wisely, and frame your justification and solution around it. Try not to do any last minute major changes in your solution’s as that will eat up your time and your mental sanity.
- Balance PPT vs Hand drawing. I discovered that I was really quick at creating PPT slides with tables and text, but quicker at drawing data models on paper – so consider what balance works for you.
The CTA is not about the badge of honor, but about the learning and knowledge journey that you undertake. What makes a great architect is one that continues to learn, grow and solution wisely for the customers
Salesforce CTA (Certified Technical Architect) & BBC / Netflix Family Cooking Showdown Winner 2018