1st of June 2014 was a special day. It was the day I switched sides – from being a client to Salesforce, to becoming a Salesforce Consultant at Capgemini Sogeti. The journey has been, is, and looks to be amazing. So far, I’ve observed 3 technical lessons, that I wish had I known, when I was on the client side.
This is perhaps the biggest one. Proper technical documentation. Let’s face it – nobody stays at a company forever. If you’re in one of the newer markets for Salesforce, your administrator will be in even more demand as fewer people have the right skill-set. When he or she leaves, they take a hell of lot of know-how with them. If this isn’t properly documented, you risk spending heaps of time just trying to figure out how things work, becoming afraid of touching stuff as you don’t want to break the installation – after all, how do you know what depends on what?
Coming in as a consultant, this is one of the things I faced. Instead of having a document that tells me what this component does and what it impacts across the installation, I often end up having to investigate it manually, which in the end takes more time than it would have done, had the client had its documentation in place.
I heard one great example once. An admin I know, accidentally changed something which caused their e-commerce solution to be down for 4 hours. The cost? An estimated 1.200 $ per minute. Total cost = 288.000 $. In the long rung, you’ll end up saving money by documenting your solution properly.
Test, test, test – and more testing
Some might consider me biased on this point, as I work for one of the leading Test companies in the world. However, as I still haven’t worked directly with testing, I believe I’m still fairly objective. The stories I’ve heard, have shown the consequences of not doing it properly. At some point in time, you risk that your Salesforce installation reaches a level of complexity where people become scared of touching anything in it, afraid that it’ll break.
As you may know, Salesforce themselves encourage writing test-classes etc., but they don’t pose requirements about the quality of it. It might cost you more in the short-term, but you risk shooting yourself not just in the foot – but shooting both your legs off, forcing you to a stand-still (and potentially a coma). Proper testing is what enables you to stay flexible when using Salesforce. And flexibility, among things, was probably one of the reason you bought it in the first place – right?(remember that there are many ways testing can be sped up, automated etc.)
This is fairly new to me. When I was on the client side, we just did things and never really stopped to analyze what the ramifications are. Not that storage is a deal-breaker in any way – but it is an extra cost you need to account for. Especially for SME’s this can have a greater impact on the budgets, as it can hit you harder than it would hit larger companies. On the other hand, larger companies are at greater risk of facing data issues quicker.
What storage analysis essentially is – in a Salesforce environment – is looking at how many new records, per object, you create weekly or monthly, and then multiplying it up to give you a yearly increase in storage demands. Consequentially, when you create a new integration, a new object or new data inflow, remember to stop and look at what it does to your storage requirements year over year, so you can be proactive about it.
So in summary:
Test, Document and Analyse Impact – those are my first 3 technical lessons as a functional SFDC consultant.
What are your important lessons?