Certified Salesforce Technical Architect

Tweet

This week I received an email from Salesforce Certification informing me that I'd passed the review board and obtained the Salesforce Technical Architect certification.  This post details my experience and hopefully provides some guidance for those that are considering attempting this certification.

Please don't ask for or post any exam questions/answers, as this is contravenes the test taker agreement that we all sign up to at the beginning of the exam and devalues the certification.

I participated in the beta of this exam for the first two stages, so things may have moved on a little.

There are three parts to the certification:

1. Self Assessment

This is a questionnaire in which you rate your experience with various technologies, both on and off Salesforce platform.  Some of the items I rated myself on didn't feature again (e.g. JQuery).  The most important thing here is to be honest about your abilities.  The second and third parts of the exam are tough, so if you claim experience that you don't have, you are likely to be quickly found out.

2. Multiple Choice

After clearing the self-assessment, next up is the multiple choice.  This is 60 questions over 2 hours, which gives a clue as to the level of detail in the questions and answers - the beta had 139 questions over 4 hours, so it could be worse.  Like the cloud consultant exams, many questions had answers that were all correct, but you had to pick the best practice, and there were only a handful of questions where I felt that the answer was obvious if you had worked in that area.

Unfortunately for me, the study guide wasn't released at the time that I took the exam, so I only had the description of the exam to work from when deciding what to revise.  The thing that really surprised me about this exam was how little actual Salesforce knowledge was tested - a lot of the questions were around how Salesforce could integrate with other systems.

3. The Review Board

The next step is the review board. This requires a significant investment - $6,000 - which increases the pressure to pass!  While it sounds like a lot of money, there are 8-9 people involved in the review board for the best part of half a day, so its easy to see how the costs mount up.

Prior to the actual event, you have to produce a case study of a real-life customer implementation that you have architected.  The study guide recommends at last 10 hours, but I'd say I spent easily twice that, mainly because I kept changing my mind about what needed to be in there.

The certification packet you get sent when you book the review board indicates the areas that you need to cover, but only at a very high level so choosing which details to leave in or out takes some thought.

Something to bear in mind for this is that you will have 30 minutes to present it to the review board.  While that sounds like a lot, once you get into your stride and start talking around the points in the presentation it quickly gets eaten up, and the most useful piece of advice I can give you here is to dry run the presentation a few times to check your timings and learn your lines.  I really struggled to keep to 30 minutes, and in my first couple of attempts ended up hurtling through the final 10 slides or so and having to speak at an incredibly fast rate.  I'd suggest that 30 slides is the maximum that you can use if you are intending to have a reasonable amount of information on each.  The next key piece of advice is that if you put something into this presentation, you had better be prepared to drill into it in great detail.

The review board was being run out of San Francisco, but unfortunately I couldn't swing a trip out there so I had to take part remotely via a web session.  Handily enough we do quite a lot of webinars with our customers so this was quite a familiar environment for me.  The review board is made up of subject matter experts and technical architects from Salesforce and the wider community.

The review board is a 4 hour session, broken down into 5 parts:

1. First you are given a hypothetical scenario with a current architecture landscape and set of business requirements, and you have to architect/design a solution and produce a presentation  in 75 minutes.  At first glance, 75 minutes sounds like a lot of time, but the time flew by.  The   scenario was a lot more complex than I had anticipated and it was quite a struggle to cover everything.
2. You then have 30 minutes uninterrupted to present your solution to the review board.  If you don't utilise the full 30 minutes this gets added to the next section.  I only used 22 minutes and learned a valuable lesson the hard way!
3. Next the review board has 30 minutes (plus any time you didn't utilise from the previous section) to question you on your solution in an interview format. This is the toughest part by far - you are already likely to be rattled from trying to produce the solution design in quite a short amount of
   time, and you'll no doubt have started questioning yourself while presenting it.  Once the experts start drilling down into the detail it can become a real test of character.  Apparently there have been candidates that have been very nervous during their presentation and have then been too nervous to answer questions - I'd imagine this applies to candidates who weren't really ready from an experience perspective and had relied on memorising information.
   
   Its not a hostile or unpleasant environment, but you will be expected to speak to quite a level of detail across a number of technological aspects, and if you don't give enough detail the questions will keep coming!  This 38 minutes seemed to last an awful long time.
4. After a short break, you then have another uninterrupted 30 minutes to present your case study that you have prepared in advance.  The difficulty here is to lift yourself after the previous session and not to dwell on any mistakes you feel you've made earlier.  This is where the rehearsal can stand you in good stead, as you should know this material like the back of your hand.  Learning from part iii I took 29 minutes and 52 seconds by my stopwatch, thus only giving the board an additional 8 seconds to quiz me!
   
   
5. Finally, another Q and A session on your case study.  This covers a lot of the wider aspects of the Technical Architect role, so you'll need to be prepared to talk about things like the development methodology, testing strategies, project governance, interaction with project stakeholders and the wider business users.  My preparation really paid off here and as far as I recall I was able to answer pretty much all of the questions to quite a level of detail.  This final section flew by and I was quite surprised when the board indicated they had no further questions.

I really had no idea how I'd done at the review board - its quite intense and reactive, so its difficult to judge your own performance.  Another key piece of advice here is to ensure some of your colleagues are waiting to buy you a beer straight afterwards!  

 

I realise I'm making this sound like a really tough experience and that is because it was.  I don't feel I could have been much more prepared but it was still a real challenge, so if you are going in underprepared or lacking experience you really aren't going to find it much fun.  This is as it should be of course - this is the highest level of certification so it shouldn't be easy.

 

After the review board its a wait of up to 4 weeks to hear the results - I received my results in just under 2 weeks and I was rather pleased to pass to say the least.

 

Areas that you need to know are:

• Integration - the various APIs that Salesforce has and when it is appropriate to use each one
• Clicks versus code - the pros and cons of each and which is appropriate to use for a given scenario
• Identity management - the various types of single sign-on that can be utilised with Salesforce, user provisioning and if there are any caveats around sites/portal access
• Multiple org versus single org - again, pros and cons, which to use for a give scenario and also elements that may push you towards multi org having started out in a single org
• Large data volumes - techniques for handling large volumes of data from a migration, integration and analytics perspective
• Mobile and desktop access
• Agile versus waterfall development methodologies
• Design patterns
• Project governance
• Stakeholder management
• Testing strategies
• Deployment strategies
• Change management
• Portal options - customer, partner, Force.com sites, Siteforce and Heroku.  Again, the pros and cons, which is the better fit, license restrictions and cost
• Security and privacy - from a number of perspectives, e.g. technical configuration details, benefits of certifications, physical versus logical, firewalls, DMZs, proxies and reverse proxies
• Performance and scalability
• General architecture concepts - a lot of the time Salesforce will be one component in an architecture, so you'll need to know what is a good fit for Salesforce and what needs to be in an external system

Q & A

 

Q. Can you please share links for the preparation of exam specially relating to integration and SSO topics.
A. The best resource for SSO I've found is the Developerforce Consultant Resource Center page at: http://wiki.developerforce.com/page/CRC:SSO (This link is now defunct).
The Developerforce Technical Library is a good starting point. Here are some links to this:

• How to Implement SSO with Force.com
• Single Sign On With SAML on Force.com
• Implementing Single Sign On across Multiple Organisations
• Digging Deeper into OAuth 2.0 on Force.com
• Using OAuth to Authorize External Applications

Q. When your results came back to you, did the review board give you any feedback?
A. Yes, you do get feedback.  There are around 12 areas and you get told what you were strong on and what you need to work on.

If you have any questions on this, please post them into the comments section below and I'll add them to this section.  

 

Follow @bob_buzzard