Paul Fayle on what it takes to become a Salesforce Certified Technical Architect

In Salesforce experts, Salesforce news by Ben DuncombeLeave a Comment

There are circa 200 people globally who truly understand what it takes to become a Salesforce Certified Technical Architect. Thousands of Salesforce professional have aspirations of one day joining this elite club but the process is lengthy, extremely challenging and the success rate is low. How do you prepare for such a sought-after certification? Why do so many people fail and what are the review board looking for?

 

Talent Hub recently spoke with Paul Fayle, one of a handful of Salesforce Certified Technical Architects in ANZ. Paul provided us with insights into his journey from Siebel to Salesforce, his approach to preparing for and ultimately passing the TA certification and advice for anyone else looking to do the same.

 

You joined Salesforce after 3 years working for Oracle and many years working with Siebel. What attracted you to move into the Salesforce space and how easy did you find the transition?

 

I had always been primarily an Applications Architect. I saw that this was where the future was for Apps, and that Siebel was slowly dying. The good news for me was that many of the skills I had picked up from years in CRM and MDM with Siebel and related technologies had prepared me well for the transition to Salesforce.

However, whilst I found the concepts straightforward, the hardest elements to get used to were related to the technology. Having been used to a considerable amount of direct database manipulation with Siebel – not having access to the underlying tiers was a challenge. Concepts such as governor limits were foreign to me, and all of the approaches and standards were more modern (e.g. in SSO and in integration).

 

 

What were your first few months as a Salesforce professional like and how quickly were you designing solutions?

 

Definitely challenging – it is true what they say: it is like a firehose. There is so much to learn and so much to absorb – and everything moves faster in that environment. I really had to re-adjust to treating the learning experience like I was a graduate again. I won’t pretend that was easy, but it was a lot of fun and really re-ignited my passion for the industry and technology.

I originally worked more as a Solution Architect – so more on the functional and declarative/configuration side – and I was designing my first big solution (with support from some fantastic colleagues of course) around 2 months in. My past experience in architecture and application management helped enable me to do that, but it was daunting nonetheless.

 

You secured your Salesforce Technical Architect certification in May 2014, just over a year after starting your Salesforce career. What enabled you to do that so quickly and how did you prepare for the challenge?

 

My view is that obtaining the Certified Technical Architect accreditation is like raising a child – it takes a village. Salesforce have a fantastic program to ramp people up and prepare them for the board. Colleagues who have obtained their certification give back to the community by participating in judging and coaching candidates in around 10 weeks of hypotheticals based on the structure of the board. Without that assistance and insight, the board would be that much harder.

That having been said, it was one of the hardest challenges I have faced. It is something that you must genuinely earn – and it is something that you can be justifiably proud of as well.

 

How difficult did you find the certification process and thinking back now, would you have changed anything about the way you approached it?

 

Extremely difficult – the board is intimidating, and you need to be rock solid in your knowledge and in your delivery. Looking back, I would say that I probably focussed too much on the depth of my knowledge and too little on refining my approach. That isn’t to say that the content is not important – it is – but unless you know the content then you shouldn’t be attempting the board (most people attempting are really solid architects with fantastic experience – and knowledge is seldom the main reason for failure). Getting your process right – presentation, time management, architectural diagrams, and succinctness of response – is of key importance. In retrospect I would have started going back over each hypothetical 1-2 times again earlier in the process.

 

Over the last few years you have coached a number of people as they prepare for the TA Certification but not everyone is fortunate to have a coach like yourself. What advice do you have for anyone approaching the different stages of the certification?

 

Firstly – the fact that Salesforce have split part 2 into the domains is excellent I think. This allows the candidate to really focus on getting the breadth and depth of their content knowledge refined up-front. The focus then, when they prepare for the board, can be solely on the preparation for the process. I would definitely say – don’t rush it. A good two years of solid Enterprise level project experience is really needed these days, as the breadth of the product increases every couple of months.

Tackling it on your own is hard though – I don’t doubt it can be done, and there are some fantastic individuals out there to whom this comes naturally, but I would certainly suggest trying to find a mentor who has faced/passed the board to help you settle on an approach that will work.

Use some of the fantastic resources out there – Trailhead is a no-brainer (it didn’t exist when I went through) and the following:

 

https://developer.salesforce.com/page/Architect_Core_Resources#Force.com_Security_Design

 

 

The review board sounds particularly daunting. For anyone that doesn’t understand this stage, are you able to provide some insight?

 

Confidence is vital, but there is no doubt it is an intimidating set-up. It does change regularly, but in essence, you are provided a fairly lengthy hypothetical customer scenario on the spot. You must process the requirements in the scenario, and detail out a full end-to-end solution in a very short timeframe. How you do this is mainly up to what works best for you, but it can involve PowerPoint, sketched diagrams (on paper/whiteboard/PowerPoint), or simply notes. You then have a limited presentation time in which to cover the decision – and importantly this involves covering ALL requirements, the solution you are recommending for each and WHY (sometimes briefly referencing the other options where there are options).

There is then a Question and Answers component – and again, this is time-boxed.  The Q&A is actually an opportunity the board examiners are looking at to pass you – if you haven’t covered an area or have not convinced them you genuinely understand something then this is an opportunity to dig into it and for you to cover/explain it. In some cases, when they focus on an area repeatedly, it is a message that you might have got something wrong – and it is an opportunity to perhaps remediate your solution.

 

Why do you think so many people fail the certification?

 

The number one reason I believe people fail is time management – and this comes with repeated practice and refinement of process.

The other reasons people fail often depend on background. In the case of someone coming from a development or technical architect background (the bulk of candidates), the content area most commonly failed historically would be Security and Sharing architecture. The reason for this is that Solution Architects/functional resources have a lot more exposure to this critical and often complex area of Force.com.  Now that Governance is part of the board, I suspect that the ‘soft-skills’ areas related to Project, Risk, Issue, and Change Management will expose people of this background more.

In the case of someone coming from a functional background, the more complex areas of SSO, Integration, Large Data Management, Code (such as standards applicable to Visualforce, Apex and Lightning Component) and even Deployment/Code migration are common areas of exposure.

Overall, it is just hard. It takes a lot to pass: a lot of effort, practice, assistance, and application – even a little bit of luck (i.e. not getting something from left-field that you haven’t practiced for). This is what makes it such a challenge, but also what makes it so valuable.

What did securing the certification mean for you and how much do you feel you learnt/improved as an Architect through the process?

 

Quite frankly, I have seldom experienced such a sense of achievement. I was very proud, humbled, and grateful to those who had given their time to assist me in getting through the process. It is a fantastic feather in the cap from a CV point of view, and it is very well regarded in the IT industry.

Even if you don’t pass, the process is certainly worth it – there is no doubt it makes you a better architect, refines your Salesforce (and ancillary) technical knowledge, and builds your confidence.

 

What do you think differentiates a great Salesforce Architect from a good Architect?

 

Creativity. To my way of thinking, great architecture is part science and part art. Sometimes an architect is faced with a particularly challenging/different scenario, and being able to think differently and get creative about a solution for that problem is what sets apart those who I consider to be great architects. This does not necessarily mean it is always a Salesforce answer by the way – and it applies to all Architects – be they Enterprise, Domain, Application or Specialist in focus.

 

What are you most excited about for the future of the Salesforce platform?

 

What am I not excited about?! Einstein sounds very interesting, but in terms of what is here and now I am really interested to see how far Lightning Components evolve and whether the coding aspects to them progressively take a back seat to modular/declarative capabilities (and to what extent Aura becomes a wider industry standard). I am equally excited about the future of the platform in terms of scalability and use of public cloud infrastructure. Constant innovation is why people work with Force.com – and my answer to this would be likely to change on a week-to-week basis.

Leave a Comment