Salesforce Project Evolution

Salesforce project complexity has evolved from basic administrator console (UX) based configuration in the early 2000s through the addition of the Apex programming language, APIs, metadata packages, change sets, web services, callouts, Eclipse / Force.com IDE, SalesforceDX, Heroku and now to Evergreen. In this podcast, Andy Forbes talks to Matt Prorok, a Capgemini Technical Architect in the Capgemini America Salesforce Practice, and Erik Ivarsson, a Managing Solution Architect in the Capgemini Sweden Salesforce Practice, about the current state of Salesforce projects and future of Salesforce projects. To learn more about Capgemini and Salesforce, go to https://www.capgemini.com/partner/salesforce.

Matt Prorok: [email protected] | https://www.dhirubhai.net/in/matthew-prorok-6752371a/

Erik Iverson: [email protected]

Andy Forbes: [email protected] | https://www.dhirubhai.net/in/andyforbes/

Podcast: https://soundcloud.com/capgemini/capgemini-salesforce-podcast-salesforce-project-evolution

Discuss: https://trailblazer.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000LoWn

This transcript edited for brevity and clarity.

Andy: Welcome to the Capgemini Salesforce podcast series. I’m Andy Forbes from the Capgemini America Salesforce Practice, and I'm talking to Matt Prorok, a Technical Architect in the Capgemini America Salesforce Practice, and Erik Iverson, a Managing Solution Architect, and Developer in the Capgemini Sweden Salesforce Practice.

You have been both been working with Salesforce for about five years. Erik, can I ask you to talk a little bit about how you saw Salesforce projects run when you started? What was the environment like for you?

Erik: My first Salesforce project was a massive project where we had a lot of knowledgeable people. I worked as a junior developer, knowing very little about Salesforce. My Salesforce mentor introduced me to the IDEs that we used as part of a rigorous DevOps approach with a focus on continuous integration when it came to version control and complex branching and merge structures. Overall, a very nice CI/CD delivery model back in 2014. It was the key to introduce those practices at the beginning of my Salesforce career.

Andy: Matt, how about you? What were Salesforce projects like when you got started?

Matt: When I got started in Salesforce about five years ago, I would say that the projects I worked on were Agile, but the interpretation and running of Agile were the responsibility of the project teams. There was some level of autonomy for the project to figure out what Agile meant. Then implement according to their preferences. Over the past five years, what I've seen is a shift towards top-down management of the Agile process through centers of excellence to enforce compliance with Agile on projects.

Andy: It's easy to say "we want to be Agile" but, of course, pure Agile means that other than the next sprint, you don't know what you're going to get or when you're going to get it. I find most clients want to sign a contract that says, "It's going to cost this much, it's going to take this long, and it's going to result in this scope." Given our work environment, what do you see in terms of the Waterfall, Agile, and DevOps mix?

Matt: I see what I would call "Wagile," which is a mix of waterfall and Agile. I do a lot of net new build project work as opposed to ongoing support and run. In this situation, clients are buying a fixed scope that they want to see implemented. There's not the ability to do an exact Agile project where what you would be buying is a fixed amount of resources for a specific period. But the projects do have some of the ceremonies and trappings of Agile. So we have sprints, there are demos and retrospectives. It's kind of a little bit down the middle, taking some of the things about Agile that are helpful for a waterfall project, but not going the full enchilada towards 100% Agile.

Andy: Understood. That's what I see exactly. But then we work for the same practice so that only makes sense. Eric, how about you? What are your current projects like where the Waterfall, Agile, and DevOps mix is concerned?

Erik: I would say that there's a clear desire to be Agile. The methodology and the result of Agile are so appealing - to be able to quickly ship tested reliable functionality from user stories into the production environment.

Andy: Predict the future where delivery methodologies for Salesforce projects are concerned. Over the next couple of years, where do you see things headed? Especially given things like Lightning Web Components, Heroku, and Evergreen.

Erik: Salesforce is continuously growing. They recently acquired Vlocity; before that, they acquired Tableau, before that they acquired Mulesoft, and before that … the list just keeps growing. The Salesforce product list and ecosystem just keeps getting bigger and bigger. It's going to be essential to have a DevOps approach and toolset to deliver work based on the Salesforce core, and Marketing Cloud, Heroku, and Evergreen, as well as external products like Informatica and Boomi. I think that we're going to see a lot more from Salesforce as well, like what they are doing with Customer 360, to tie it all together.

Andy: Matt, what are your thoughts on the future of Salesforce projects?

Matt: I think more mature DevOps is going to be critical to managing the complexity of Salesforce projects. I'm thinking specifically CI /CD, automated regression testing, maintaining deployment control, and managing workstreams. I think the other point that I'd like to highlight is that in addition to all of the various code based capabilities that are available. Salesforce is pushing more and more towards configuration, which, when deploying, does not require the same level of testing to go into a production environment. I think that clients will need to get a handle on how they manage the regression testing of these configuration based components because it doesn't necessarily have the same testing requirements as a code base.

Erik: That's an interesting point. I'm always in projects where there is a mix of programming solutions and configuring solutions. There is still the question, "Do we need to write tests for the configurations?" Yes, of course, we need to write configuration tests! We need to make sure that the performance loads etc. are manageable and that it's scalable. So we'll get new testing strategies in the future, I believe, where we'll need to tie it all together and ensure the scalability of our advanced solutions.

Matt: I think that what is going to change in the future is looking to testing as a way of controlling the DevOps process and governance as opposed to what I feel it is today. A lot of clients I work with its more of a "check the box" exercise that you have to do to deploy into production but isn't being used to take control of managing the deployment and its success.

Andy: I'm going to go back to a word that Eric used, which is "interesting." I think Salesforce projects are going to get interesting on multiple fronts. Matt, I know that you're a Salesforce certification acquisition machine, but at some point, there's just too much. Salesforce bought Vlocity recently. So Salesforce is Sales Cloud, Service Cloud, its CPQ, it's flavors of CPQ, its FSL, it's Einstein, Heroku, its Evergreen, its verticals - a push into Retail, push into Health, and push into Manufacturing. At some point, we, the people that work in the Salesforce space, are going to have to specialize in the parts of it that we know, and we're going to have to specialize in how we deliver it. Even with DevOps, when I'm on a project where the client wants DevOps, fabulous, but I struggle to find the time to learn Capado and Snapshot and Bitbucket when the project needs to start I already know my way around a different DevOps toolset. We're going to have to start drawing some circles around where in this space we operate because it's just getting impressively complex.

Matt: I agree with that, completely. I think that being able to guide clients towards what are the best use cases for the Salesforce platform. They should think about the roadmap in terms of rolling out the various features, figuring out what are the dependencies between the different technologies. The different clouds and all of this high-level architecture and design questions. As consultants, we need to make sure that we are keeping up to date with all the latest developments so that we can effectively guide our clients. I think this is going to become increasingly more important as the rate of change accelerates.

Andy: I think your days have more hours in them than mine do, Matt.

Erik: I feel that Salesforce has had an issue in the past where the number of certified people and the number of people with the skills for the Salesforce platform is not at the level that Salesforce would like it to be. For example, they had Lightning Components before that were very, very Salesforce specific in how you develop them, how you would deploy them, etc. Now you have more generic Lightning Web Components that provide a framework that any web developer that knows JavaScript and HTML can use. I think this will attract people with experience in web development because they will be able to come into a project, contribute, and develop something great.

Andy: I think we're heading into an exciting time where Salesforce projects, Salesforce development, and Salesforce architecture is concerned. Matt, Erik, thank you for your time, and thank you for the insights that you've provided today.

Matt: Pleasure to be with you.

Erik: Thank you very much.

Andy: You've been listening to the Capgemini Salesforce podcast series. To learn more about Capgemini and Salesforce, go to https://www.capgemini.com/partner/salesforce.