Tips on Passing the Salesforce Certified Technical Architect Multiple-Choice Exam

tech_arch_partial

 

It’s been on my “to-do” list for some time… and today I’m happy to say I passed the Salesforce Certified Technical Architect Multiple-Choice Exam!  Of course I still have the infamous review board presentation, but I thought I would share my experience thus far.

After working on the platform since 2009 and taking the other 6 exams, this one really wasn’t too bad for me. But just to be safe, I took the process very seriously. After all, it is $500 with a $250 retake fee!

Past Experience is Key

Here’s some of my hands-on experience, which was very relevant to the exam:

  • Past work with integrations.
  • Architecting a wide variety of creative solutions across all the clouds.
  • Years of heads-down development work.
  • Multi-tenant and large data related issues, such as query optimization.

Review

I went through the study guide and marked anything I felt I needed to brush up on:

study guide

To review I watched the salesforce video training available through the partner community help and training on topics like Integration, Multi-Org strategies, Governance, and SSO / OAuth. Any topics I wanted to study and couldn’t find videos for I just searched in the help documentation and found exactly what I wanted.

A couple of bonus tips on items I recommend for study

  1. Make sure you know what all these words mean, and all the ways to use them!
    • inheritance
    • polymorphism
    • interface
    • abstract
    • extends
    • virtual
    • implements
  2. Understand all the relevant types of compliance standards (SAS, ISO, PCI, etc).

Taking the Exam

Don’t be shy about using the scratch paper they give you. You may have to calculate governor limits, sketch a rough ERD or flow chart, or use process of elimination by crossing things out.

I used 100 of the 120 minutes they gave me to complete the 60 questions. I just proceeded at a moderate and steady pace through the whole test without revisiting any of my answers. This strategy worked great this time, but on past exams I skipped questions I was unsure of and revisited them later. Once you have the rhythm of the test figured out, you aren’t as stressed about running out of time, and re-visiting seems unnecessary.

Study Guide is Great

There were some things in the study guide which weren’t on the exam, but if the exam questions are random, then perhaps someone else would those questions the next time.  Overall, I thought the study guide was a perfect tool for directing my study efforts.

Conclusion

If you have a true force.com understanding of 70% on the breadth and 60% of the depth you can probably pass this test with minimal study.  But the more you can study the better!  Cutting it close is stressful, and you never know what random questions you may get or any mistakes you might make.  Learn everything the right way over the years and it will sink in and most of the questions will feel like “freebies”!

Salesforce development struck by Lightning

One of the biggest bombs Benioff dropped (say that 5 time fast!) at Dreamforce 2014 this year was Salesforce1 Lightning:

salesforce1 lightning

 What theblue-lightning-hi is Lightning?

Not unlike the announcement of Salesforce1 at last year’s Dreamforce, Lightning has a lot of marketing hype and ambiguity.  This is due mostly to the fact it includes a suite of products.  However, also like Salesforce1, there is a piece of the offering that stands WAY out as the most important.  When all the dust settled around Salesforce1 it was the mobile experience that proved to be the real offering.  With Lightning it is going to be the new component framework, essentially the next generation of Visualforce, that is the real crown jewel.  The schema builder, process builder, and lightning connect are all awesome, don’t get me wrong, but they have been around in one form or another for awhile, and are just incremental innovation with rebranding.  The lightning app builder is also awesome, but it is just a tool for implementing the component framework in a WYSIWYG fashion.

New component framework?  What about Visualforce?

Well, what about S-Controls?  The one sure thing about technology is it is outdated as soon as it is released.  S-Controls made way for Visualforce.  Visualforce has had a long run in the life of force.com development, but is really starting to show its age.  In recent years ISVs and customers have had to deviate more and more from the strict Visualforce components to meet their requirements.  JavaScript frameworks have been creeping into Visualforce pages to the point where Visualforce tags are becoming a minority of the code in a page in many cases.  Controller extensions, viewstates, page refreshes and synchronous processing are victims of attrition.  They are being turned into museum pieces by more efficient user interfaces using JavaScript remoting, static methods, stateless behaviors, asynchronous processing.  Technically this is still a “Visualforce Page”.  But the composition of that page looks very different today then it did say 3 years ago.

Ok…  So, still why not keep using Visualforce?

Square Peg in a Round Hole_0565

In 2 words:  Mobile and Wearables.  Visualforce was designed for desktop computing with relatively fast, hard-wired network connections, large displays, and a full-fledged human interface devices.  Salesforce1 was a huge leap forward in addressing the needs of mobile computing.  But it left a gaping hole which developers had to attempt to fill as best they could.  Developing Visualforce for Salesfore1 is not an amazing experience.  Sure they threw us some bones like sforce.one.navigateToSObject.  But the architecture and styling just felt like a square peq in a round hole.  It doesn’t have that desktop Visualforce / Apex, Peanut Butter / Jelly meant to go together feeling.  Put another way, the Salesforce1 deficiency was the ability to create Salesforce1 mobile experiences in the same way salesforce created them “out of the box” on the Salesforce1 mobile app.

Salesforce1 Lightning to the rescue!

For sure the Visualforce pages of enterprises across the world will continue to be read and write data from and to the salesforce orgs they live in for years to come.  But no longer will Salesforce1 mobile app development have to feel like desktop shoehorned into mobile.  The beautiful, mobile, standard page layouts of Salesforce1 will flow more gracefully into custom Lightning apps.  <ui:button> will magically be the right button for Salesforce1 without needing to disguise <apex:commandButton> for the job.  Developers won’t be forced to go to other JavaScript frameworks every time they want to do something on the client side.  In a nutshell, Lightning allows us to go back to developing in a more streamlined “Visualforce-esque” manner, while still being able to leverage the latest technologies of the server and perhaps more importantly, the client.

Will the legacy desktop user interface go away?

I don’t know.  But there will definitely be new apps created with Lightning in a responsive fashion to work seamlessly across desktop, mobile, and wearable devices.  This is at least the start of a shift towards one UI to rule them all.  The {!$Browser.formFactor} global variable will let developers slightly customize their apps to work best on different devices.  One app customized for all platforms is much easier to maintain than a Visualforce desktop codebase and a Lightning Mobile / Wearable codebase.  The trick is doing it in a way where the experience isn’t compromised on any device.  This is hopefully where Salesforce will come in and handle the the lightning elements in different fashions depending on whether the Lightning app is run through the Salesforce1 mobile app on a smartphone, or through the desktop.  For example, a data grid that is smart enough to render differently for large vs. small screens without the developer having to handle that.  This also helps developers to “future proof” their code since salesforce provides an abstraction layer which they maintain so your app always works well on the latest devices.

Advice to other Developers

You need to have at least intermediate level JavaScript experience.  If you don’t have it, get it.  Read a book, take an online course, or just google your way through some complex JavaScript projects.  Don’t focus just on standard JavaScript syntax, but frameworks like jQuery, various patterns, CSS and the DOM as well.  JavaScript is going to become a KEY skill for salesforce developers (it already is in many cases).  This will not only improve your ability to crank out hybrid Visualforce pages, but it will also make the move to Lightning less of a shock.  It will also position you well to be create interesting new projects on Lightning vs. being stuck a role maintaining Visualforce…  And we all know building new things is more fun than maintenance.  🙂

Salesforce1 Lightning Resources

Adding Reports to Salesforce1 with jQuery Mobile and the Analytics API

Salesforce1 comes with nice dashboards built in, but no reports!

This is somewhat understandable.  Dashboards are already fairly mobile friendly while reports can be quite unwieldy, even on a desktop experience.  The number of rows and columns and the controls needed to manipulate them are not trivial to implement on a small touch screen.

It is, however, possible to attempt to build this functionality yourself with the Salesforce Analytics API and whatever User Interface you wish.

Arun Varadharajan, Product Manager for Salesforce Analytics has put out a nice, simple example of how to do this:

Check the link in the tweet to see his GitHub repo.

This example is cool because it uses no apex controller.  It is all done in VisualForce and JavaScript.  It renders with the Google Charts API, to make something that looks like this:

11

However the Google Charts API isn’t all that mobile friendly.  And this example provided no method for choosing which report to display.

I decided to look deeper to push this solution further ahead for the salesforce community.

My Contribution… sf1Reports!

sf1Reports uses the latest jQuery mobile framework to create a mobile-friendly report search and render experience.

The search uses JavaScript Remoting and SOSL to return the results as you type. It searches all your reports you have created in your salesforce org:

3

You can choose 2 modes to render the report.  Reflow or Column Toggle.

See these links for more info:
jQuery Mobile 1.3.2 Docs – Table Reflow
jQuery Mobile 1.3.2 Docs – Table Column Toggle

Reflow mode will look like a standard table when the columns fit on the screen, or will collapse the rows down into a block of label/value pairs when they don’t fit on the screen.  Reflow mode is good for looking at the report data one record at a time, but not as good for comparing the records to each other:
4

Column Toggle mode lets you select which columns you want to display, so you can fit the relevant columns onto your mobile screen:
5

Installation Instructions

Grab the files from my GitHub repo: https://github.com/danieljpeter/sf1reports .
Deploy the 2 classes and 1 VisualForce page to your salesforce org. I didn’t package them, but they are easy to deploy with something like the Force.com IDE.

Enable Salesforce1 in your org:
6

Make sure the mobile checkbox is checked on the VisualForce page:
7

Make a VisualForce tab for the page:
8

Add it to the mobile navigation:
9

Navigate to https://<your instance>.salesforce.com/apex/sf1reports by manually entering it in the URL bar.  It will change to your visualforce domain which will look something like this:
https://c.na15.visual.force.com/apex/sf1reports . Copy the visualforce domain portion of the URL as seen below.  You will need to paste it into the next step.

Take your visualforce domain, and add it to remote sites.  this is because we will be calling the rest API:
10

Final Notes

This is just v1.0.  It obviously is just a crude start, but it has potential.  Feel free to contribute to make it better.

It only supports tabular reports currently.  Summary and Matrix could be added with some more work.  I use the JSON Parser to blast through the Analytics API response.  That data is fairly complex, so I chose to iterate over the JSON rather than try to deserialize it.  There would need to be some thought as how to convert the JSON for Summary and Matrix reports to corresponding apex and ultimately HTML elements.

I chose a flat listing of all reports that is searchable by SOSL.  This seemed like a good mobile-first thing to do.  If desired, navigation through the report folders could be added.

It might make sense to make some mobile versions of reports in salesforce with a naming convention which have fewer columns and rows.

I noticed that the iOS Salesforce1 app would crash sometimes.  The Dreamforce 13 app also crashed in a similar manner, so I don’t know if it is a problem with my app or not.  Sf1reports didn’t crash which running it in a browser on my desktop with the /apex/sf1reports URL or the /one/one.app URL.  Hopefully Salesforce1 proves to be a reliable container for our custom VisualForce apps and this isn’t an indicator of a larger problem.

If you need report data on to go, it might just solve your needs!