On the 8th May 2017 I attended the Salesforce Certified Technical Architect Review Board examination at Salesforce Tower in London. It lived up to it’s fearsome reputation and was an educational experience in itself.
The Result
I had been preparing myself for all possible outcomes since walking out of the final session of the exam with my head spinning and questioning whether I was even fit to tie my own shoelaces. Talking with CTAs I met in the weeks that followed confirmed that many people feel the same way, so I had no clue as to what my result would be. So I just had to wait.
Three weeks later the early morning email from certification@salesforce.com arrived. There was a brief moment of excitement as I waited for the message to load. Then “We regret to inform you…unsuccessful, Result: FAIL“.
I was disappointed of course, and then all the other emotions took their turn as I read through the detailed feedback included in the email. I made notes as I went, thinking back to questions the judges had asked me, assumptions and choices which I’d made in my design. I kicked myself for the easy things which I’d omitted from my presentation and got confirmation that I’d made a couple of fundamental mistakes with respect to security and large data volumes which sealed my fate.
It wasn’t a total disaster, there was positive feedback:
- Good identification of on / off platform components and relationships
- Logical presentation of requirements – easy to follow
- Data model – identified most of the standard objects to use
- Correct programmatic features vs declarative
- Good sandbox discussion / integration
- Good variety of best practices and strategies
- Diagrams fair – a bit compact especially landscape diagram
- Good engagement / presentation style
This confirmed that my preparation had been worth the effort but that I had not mastered all the knowledge areas.
Examination Day
Everyone I met did their best to make me comfortable and ensure that I had all the things that I needed during the 5 or so hours that the review process takes. But it wasn’t possible for me to be relaxed of course.
I stuck to my plan for the 2 hours given to read the scenario and prepare the solution. I found it challenging to extract every requirement from the 6 dense pages, but went line by line piecing together my ideas on A4 note paper as I went. With 30 minutes remaining I transferred my draft sketches to the large flip-chart pages with markers. There were still some gaps in my thinking (bad sign, see lessons below) but I was running out of time. So I added some final details and validated my choices as best as I could. Time up and I had 15 minutes to refresh and collect my thoughts for the presentation while the judges took a first look at the pages as they were taped to the presentation room wall.
This is the list of flip chart pages that I prepared:
- Architecture Landscape Diagram
- List of internal & external actors (users) & licenses needed
- Data model diagram
- Role hierarchy diagram
- Deployment & testing pipeline, inc. sandbox types
- Project governance structure
- List of assumptions
For the presentation stage I treated the introduction as I would for real clients. I started with a welcome and stated the purpose. I went on to summarise the pain points that Company X had and the business objectives they were looking to meet using the new Salesforce solution. I then moved to use the diagrams and introduce the systems, the actors and the key aspects of Salesforce which would be implemented (I was not comprehensive, see lessons below). I was then ready to detail the solution and my recommendations. I went line by line from the scenario and for each requirement described the Salesforce features or customisations which would be used, I made use of the diagrams as to illustrate to the judges the relevant details . With time running short I was going faster and faster in order to cover the full list of requirements. Time up, and a short break for me while the judges compared notes and prepared their questions.
I was then invited back into the presentation room for the 40 minute Q&A section. I enjoy debating solution options with clients and colleagues in the real world, but here the judges are permitted to only ask questions so that the candidate is restricted to their own knowledge and experience. The majority of questions I was comfortable with but I also had a few instances of “erms…” and missteps where I got half way through my answer and then revised it. It’s clear to me now that these were my weak knowledge areas and, true to form, the judges sniffed them out.
What I learned
After reviewing the feedback I have identified the knowledge areas that I need to strengthen. Under pressure in the exam I didn’t have immediate recall of some features that were important to my solution because I had not practiced them enough in real-life or during revision. For example, I didn’t remember that a registration handler Apex class is needed to set up users signing on via Facebook. I will use more hands on study to reinforce my knowledge in the areas identified.
I have also reviewed the way that I approached preparing and delivering the presentation for the judges. Whilst my first attempt followed the plan that I had, the experience has given me 3 key lessons which I think will help me in the future.
Lesson 1 : Add details to the diagrams as they are identified
I feel that this was my biggest preparation shortcoming. There is only enough time to go through the scenario pages one time, so when a requirement is identified it’s vital to know how it needs to be detailed in the solution. Synthesising requirements from the scenario onto the solution diagrams needs to be automatic and I made the mistake of trying to hold several requirements in my head in order to consider different options. Whilst this may work during a day long workshop it’s no use in a 2 hour preparation stage of the exam. In my situation I didn’t build up the role hierarchy and data model diagram as I went and this resulted in a lack of detail in my own understanding and consequently in the level of detail that I presented.
Lesson 2 : Diagrams need to be detailed and clear
A CTA colleague who is mentoring me uses the term “CIO ready” as the objective for the review board diagrams. The data model and role hierarchy are crucial elements in any solution and I didn’t devote enough time to these diagrams to include all the details needed to help me explain my solution to the judges. In part, the lack of clarity was a consequence of my failure to build up the diagrams as I went (lesson 1).
Here is my current list of the details that I ideally want to include on the major diagrams:
Data model
- Standard objects should include their name & any alias from the scenario
- Colour code standard and custom objects
- Label each object with its organisation wide default sharing setting (public read-write, public read-only, private)
- Label each object with the record owner(s) role as used in the role hierarchy
- Indicate use of external identifier field if required for integration
- Label object with estimated data volume
- Highlight objects with large data volume (LDV) requirements
- Include all relationships between objects (even if not directly relevant to solution)
- Label relationship types between objects (master-detail, lookup)
Role hierarchy
- Colour code internal & external roles (Partner & Community Plus license types)
Landscape
- Create diagram representing “to-be” architectural state
- Include “as-is” systems to be retired (mark with a big X)
- Colour code systems by location (Salesforce, 3rd Party, on-premise)
- Label system integrations with their type (fire-forget, pub-sub, sync, async)
- Label system integrations with security needs (2-way SSL)
- Label SSO connections with their type (SAML, OAUTH, DA)
Deployment
- Draw sequence of all environments needed to develop, test and operate the solution
- Label each environment with the Salesforce sandbox type to be used
- Label each environment with types of tests to be performed (integration, regression, functional, end-to-end, user acceptance, …)
- Include additional systems required to manage deployments (source control, continuous integration)
Lesson 3 : Fully describe each part of the solution
I have two examples from my own feedback which taught me this lesson.
- When describing how SAML would be used for single sign-on by internal users I didn’t include details of my recommendation for the user provisioning and de-provisioning process. I should have detailed this on my diagram to remind me (lesson 2)
- When presenting my data model diagram I skipped over stating the organisation wide defaults and record owners for the objects. I wasn’t clear and my diagrams were not clear (lessons 1 & 2) so I didn’t communicate crucial information
Some requirements in the scenario tested that I understood the dependancies between the feature needed for an explicitly stated requirement (e.g., SSO) and supporting requirements which are implicit when using the feature (e.g., user provisioning process).
The CTA study guide also sets out the judging criteria relating to SSO requirements as; “…design and justify an end-to-end identity management solution.” a reminder that requirements and solutions don’t exist in isolation from other parts of the scenario. I plan to review the study guide again and check that my breadth of knowledge as well as my plans for diagrams and structure of the presentation to help me hit all of the objectives in each area.
The Future
I will be going back to the Review Board soon. First I need to be confident that I have strengthened my knowledge areas and practiced some more mock scenarios to test my performance under pressure.
The standards of the CTA qualification are high and it really is a breed apart from the other Salesforce certifications. My experience in studying the SalesforceU architect track and sitting the Review Board for the first time is that my knowledge of how to design and describe the architecture of Salesforce based solutions has increased more than I would have thought possible.
I have a little more work to do, but I keep in mind the words of a long time CTA colleague; “Stay the course my friend!”.
technology flows 