Salesforce Technical Architect Matijn Schwärzer discusses his experience with the platform, including Lightning adoption and the benefits of Salesforce DX.
With this article, learn about the experiences and insights of a Salesforce Technical Architect regarding the Salesforce platform, Einstein, Lightning, Salesforce DX, and CI/DevOps.
Here are our 5 Key Takeaways:
1. The Salesforce platform's cloud-based environment offers faster development, deployment, and integration capabilities compared to on-premise systems.
2. Lightning adoption is taking off, especially among new customers, but transitioning from Classic can be challenging for companies with established implementations.
3. Salesforce DX is a promising game changer for development and app quality, especially for ISVs, and can improve speed, code quality, and time to market.
4. CI/DevOps is becoming more common among companies with ongoing Salesforce implementations and roadmaps that stretch for years.
5. An agile sandbox strategy that starts small and grows with the project or code base is advisable, and creating new sandboxes from a staging environment can be helpful.
Matijn Schwärzer also known as @DrSmuggler was the first Salesforce MVP in the Netherlands . He is a Salesforce Technical Architect at Beethree.nl , a Salesforce consultancy in the Netherlands. He dropped by the blog to talk about Einstein, Lightning and Salesforce DX.
How long have you been a Salesforce developer? How did you get into the platform? I am a Salesforce developer for almost seven years now. I come from a background with on-premise systems. One of my directors told me to take a look at Salesforce because maybe there’s something there for us. I looked into the possibilities of the platform and discovered all the possibilities and basically never looked back.
What was special about the Salesforce platform? It is a cloud platform which was new for me - everything I worked with was on-prem back then. With Salesforce, you can have an environment up and running within minutes whereas with an on-premise environment it took up to several months! So that was a delight in and of itself.
People in the on-premise world always had to use some middleware layer to do an integration and it would take several days and you had to deal with firewalls and all that. The Salesforce platform just takes that away from you and handles it for you so you can focus on building added value for your customers.
The speed of everything from development to seeing the results of whatever you developed right up until deployment really impressed me. Previously, the go-live schedule is maybe one to two or three releases a year for the projects I had been working on. In Salesforce you can potentially go-live several times a day. It was a real eye opener for me.
Of course, the platform was a lot smaller back when I started. They only had Sales and Service really. They just started with marketing I believe. There was no Wave Analytics, no IOT, no Einstein. It was really simple and I’m glad I got to start in that period. For colleagues just starting now on the platform the whole ecosystem can be a little bit overwhelming with all the things you can do. Back then it was really simple. The overview was really easy to get. The capabilities of the platform back then were a lot less than they are now.
You say it can be overwhelming with IOT and all the awesome products, any advice for not getting overwhelmed? Start small, focus on one thing at a time and focus on the thing you’re most familiar with. For example: if you come from a sales background focus on sales first. You can learn the other products as you go.
I’m really looking forward to working with Einstein especially when we get developer access to start training Einstein via our code to analyze our data and do cool stuff with it. I believe the possibilities are endless. Salesforce has a couple of big conferences coming up, TrailheaDX and Dreamforce, what are you most excited about at each of these conferences? Well, TrailheaDX I haven’t been to yet and it won’t happen this year unfortunately since I’ll be at Dreamforce. TrailheaDX is an awesome developer conference but Dreamforce is it’s big brother, the biggest IT event in the world! There is a lot of diversity at Dreamforce. TrailheaDX is mostly developers but at Dreamforce you can meet anyone in any role: Partners, Customers, colleagues, Product Managers from Salesforce and many more.
I’m usually most excited about the mood everyone is in. Everyone is excited to learn something new and to help each other. Meeting people face to face that you interact with via social media or email is for me the most exciting thing. Of course, big announcements are also things you look out for and things you really want to attend. For me it’s the people and the network and the community. You have a good time while you talk about things you love and share knowledge and learn from each other.
Any predictions for the next 12-months? No unfortunately not. Of course I’ve heard a few things as I am a Salesforce MVP , but since I’m under NDA I can’t share anything. Make sure you follow all the headlines from TrailheaDX and Dreamforce because there will be some cool announcements. Especially on the learning side of Salesforce and the certification stuff. So keep an eye out for that. That’s all I can say now.
Are you doing a lot of projects with Einstein? Why or why not? Not right now but that has to do with a few things. First of all, it’s very new so we need to get acquainted. I must say a lot of things come out of the box with Einstein at the moment so as a developer it’s not really the right point in time for us to start working with Einstein. I did create a few demos with Einstein Vision - the image recognition tool - but I’m really looking forward to working with Einstein especially when we get developer access to start training Einstein via our code to analyze our data and do cool stuff with it. I believe the possibilities are endless.
In Salesforce you can go-live several times a day. It was a real eye opener for me. What about Lightning Adoption? Is it taking off? Yes. I do see it but I must say I see it more with companies that are just starting to implement Salesforce. They go for the Lightning experience from start. Companies that have been using Salesforce for five or more years have a much harder time transitioning to Lightning. They have invested in their implementation and there is a lot of Apex code and Visualforce pages that you need to make available in Lightning. It’s a big investment to switch at that scale.
New customers mostly start off with Lightning immediately unless they have requirements that Lightning isn’t ready for. I worked with a client that really wanted to use Person Accounts a few months ago. At the time, Lightning did not support Person Accounts so they went with Classic. But when Lightning added support for Person Accounts they transitioned to Lightning smoothly. The biggest bump in the road for customers is when there are key features that aren’t supported yet. I do see Lightning getting better and better, supporting more and more functionality. I see them building the Classic functionality into Lightning but it’s not there yet. We need to give Salesforce the time to make everything available for us and then we’ll convince our customers to move over because the possibilities with Lightning are way bigger than with Classic. It’s the future. Also, more and more Apps on the AppExchange built by ISV’s are now available for Lightning. This really helps with the transition process.
You work a lot of organizations to make their Salesforce implementation better and more effective: What is one of the biggest changes that teams can make to improve their Salesforce code base? Of course that depends on the situation. A big implementation with a lot of custom code? Or small one where mostly is point and click? I see Salesforce moving more and more towards what you could call the citizen developer. So point and click instead of code! A lot of customers that have invested heavily in Salesforce, they should revise their requirements and try to move their code into Process Builder and other automation tools like Flows. It’s maybe a little bit strange to say but that will improve your code base because everything that you build will be supported in the next release. If you get some, how can we say, “exciting” things in your code with the next release your code can break. Anything you can move towards automation tools please do so.
What do you think about Salesforce DX? Promising! I’m really looking forward to it being Generally Available. There are a lot of things going on with Salesforce DX . I’m especially excited about Scratch Orgs because that will change your application lifecycle management and your development lifecycle management. Because in the current situation before DX you had sandboxes and basically the system of record and truth for you code was in the org. With DX that will move into source control. The truth is out there.
It can be challenging to keep sandboxes in sync. It can be challenging with CI. There are still tasks that cannot be done with CI. There are still things you need to do manually because the metadata API doesn’t support it yet. Of course, you will still have those issues with Salesforce DX as well but at least you can just spin up scratch orgs for each feature you create and put it in a central repo. And you can kill scratch orgs and create new ones. So it will be less hassle.
DX will be a game changer for ISVs especially because you can spin up a scratch org with Enterprise edition or Unlimited Edition with certain features activated or not so it will really help ISVs get their product ready for any situation.
I think it will increase the speed of development, the quality of code, time to market and it will actually improve the apps in the AppExchange.
You mention CI. Are you seeing companies invest in CI and DevOps for Salesforce? Why or why not? Yes we see it more and more. I must say that it all depends a little bit on the project. Small implementations with just a few triggers and a few integrations typically don’t want to invest in setting it up. On the other hand if you have an ongoing implementation with a roadmap that stretches for years I definitely see added value in CI. We see more and more of that. More of our customers are running their whole business on Salesforce - Sales, Service, Marketing, Analytics, lots of integrations, etc.. The last 5 teams I’ve worked with you see teams of 30 or 40 developers and roadmaps that stretch 3 or 4 years. If you want to do that without CI then it’s a recipe for major challenge.
What is the best sandbox strategy and workflow you’ve seen? Do you suggest everyone get their own sandbox and set up a staging environment? I’m not sure if this is a best practice but we approach sandbox strategy in an agile way. If we start small as customers often do, it can be as simple as having a developer sandbox and production if you just have one developer. Your dev environment is also your acceptance environment. As your project or code base or number of developers grow it is at least advisable to have a dev environment and a test environment and a production environment. One of the customers I’m working with now gives everyone their own sandbox but a lot of times we see that it’s painful to keep those up to date. You have 5 devs all working on their own sandbox and they integrate changes on one staging environment. Replicating changes back to each developer sandbox can be tricky especially if you have cross references and things like that.
It would be very helpful if you can create a new sandbox from a sandbox. Once you integrate all features into UAT or staging it would be nice to be able to just spin up a new sandbox from the UAT environment so that your next feature is developed on an environment that looks like your staging environment. That would really help.
One of the toughest things with a CI environment is that there are a metadata entities that are not available in the metadata API. Some time ago we had a new requirement where decided to implement Opportunity Teams. To be able to deploy that you first have to go your Target Org and manually enable it because extra standard objects are created by Salesforce and you need them because your profiles when you deploy them reference them and your code references them. Your CI will break in this scenario. It’s especially tough if you have a multi-disciplinary team.
Any closing thoughts? As I mentioned before I urge everyone to focus on one thing and grow from there. And make sure you at least check out Salesforce DX. I know a lot of companies have their own tools but they actually take a lot of the heavy lifting away with DX. I’m looking forward to seeing what IoT cloud will do. And Einstein: I cannot wait for the underlying platform to be released so we can start training Einstein with our data the way we want.
