Description
Host Tiffany Spencer (Founder and CEO, Tech Forwards) is joined by:
Melissa Shepard (Founder and CEO, Lizztech Consulting) Sam Wadhwani (Chief Technical Architect, PwC) Brian Shea (Fractional Salesforce Architect, Shea Consulting) Emely Patra (Head of Salesforce Practice EMEA, Publicis Sapient)
In this discussion of Salesforce DevOps trends for 2023. They take us through the common pain points that Salesforce teams are seeking to address and ambitions they’re seeking to fulfil in 2023. Alongside this is a walkthrough of the tooling and implementation of new DevOps trends.
This panel was based on Gearset’s 2023 State of Salesforce DevOps report, the largest Salesforce DevOps research.
Learn more:
Transcript
And so we have, we're gonna go to the next panel, which is gonna be on the trends of Salesforce DevOps.
And then on the panel today, we're gonna be joined by my favorite CTA, Melissa Shepherd, Emily Patra, Brian Shea, and Sam Wadahani.
Sorry, Sam.
I practiced this. I promise. So if all of you are here, Sam, Melissa, Emily, Brian.
Sam, say your last name for me.
Wadwani. Just ignore the h.
Yes. And that's how I got confused because I'm reading it, and I'm I'm so sorry.
It's not the first time. It's fine.
So if y'all wanna go, Sam, if you wanna introduce yourself first?
Sure. Yeah. So yeah. Hello, everyone. Great to be here, and thanks to, thanks to the hosts for, setting up the session. So I am a Salesforce, architect. I'm chief architect for, our financial services, practice and co lead our our Salesforce architecture practice in the UK for PwC.
I've been in the Salesforce ecosystem for coming up to thirteen years now. So I I don't know what point you you know, classed as a veteran, but, I'm certainly long in the tooth. So, yeah. So that's that's a bit about me. I'm a also a a CTA much like Melissa.
Kinda Then you can you can be in my group of favorite CTAs.
I don't wanna leave you out. You know? I I just I really love Melissa and Adena, so I'm sorry.
But, I I don't blame In twelve years, we've been around a little bit.
So but we won't let people call us old, Sam. So, Emily, why don't you go next?
Hey.
Hi, Tiffany, and hi, everyone. By the way, I would love to get added to your list of CTAs. Yeah.
Collecting CTAs.
Yes. Exactly.
So I I am a Salesforce CTA. Yes. I have been in this I was working for Salesforce till about three weeks ago. You know, I've been there eight years. And three weeks ago, I joined as a Salesforce practice leader for Publicis Sapient.
So that's my new home, and I'm very excited about the new role and my new team. So yay to everyone. My experience, I've been in the enterprise architecture space for, twenty years now. So worked on, applications before Salesforce existed, you know, Oracle ERPs, the CBILS, the, SOA, etcetera, and then, moved into the SaaS world with Salesforce.
Last four years in Salesforce was me building up the EMEA practice for MuleSoft. After Salesforce acquired MuleSoft, I was asked to take on that role and, build a strategy and architecture practice there. So, yeah, that's it. A little bit about me.
That's awesome. And congratulations on your new role, Emily. That's great.
Thank you.
Brian, would you like to go next?
Sure. Absolutely. Yeah. Thanks thanks so much for having me. And I I believe on this panel, I'm the only non CTA. So I'm an architect, but not a CTA. So, Tiffany, I I I hope I'm your favorite non CTA on this panel.
Exactly right, Brian. My favorite Brian non CTA.
I Yes.
On this on this panel.
Very nice place. So, I am, independent Salesforce architect more on the kind of solution architect side, doing data architecture, road mapping for clients, business case, those kind of things. I've been doing Salesforce for about, ten, eleven years. And before that, did kind of custom builds and architecture of CRMs. So not in the Salesforce space, but, in the CRM space, particularly at a large financial company.
And I am very happy to be here. Thanks for having me, and it's an honor to be on with these fantastic co panelists.
Yeah, Brian. You have great experience. What a great career, and glad that you're here. Can't wait to hear more, insights from you based off of your experience.
And then our last panelist is Melissa Shepherd.
Hi. Thank you. I'm Melissa Shepherd. I am a CTA. I live in Boston, Massachusetts.
I have my own partner consulting company.
I've been in the ecosystem since two thousand six. I got involved in the ecosystem because my background is being a developer. I was a software engineer to Java then dot net and then got into integration architecture. So I really, I love MuleSoft as well. I've worked with it quite a bit on projects, and I'm actually a new MuleSoft ambassador. So that's exciting.
What else? I've got thirty two certifications. Need to work on some more.
MuleSoft focus now, that's my goal for this year. That was my goal after CTA.
And yeah. So that's about it, I guess.
Did you say thirty two certifications?
Yes. Are they all Salesforce? The sales is are there thirty two? I missed a couple.
So There's at least forty.
Some somewhere around that.
Thank you for that bit of Salesforce trivia because I did not know that. And so this is a really exciting panel to hear from all of you. Right? You all have years of experience in this ecosystem, and that speaks to a couple different things.
Right? The longevity of the ecosystem, the many paths, that you can take, and the levels that you can go to. And so we're excited to hear, from you as far around DevOps. And so the first question that I have for the panel is, can you tell, all of us what does DevOps mean to you?
And I can either nominate you or you can nominate yourself to go first.
I'll I'll here. I actually just answered this at, on a panel at TDX. So, I always tell people I feel like DevOps is, bringing people, process, and technology together to get something delivered and to do it, with lower lower amount of risk, higher, time to value, and a higher quality. So it's defining those things that all need to work together to get something deployed to production.
Awesome.
We could not assume.
I think I'd agree with that.
Probably shorter, I think I answered it.
I think from my perspective, working with as a, as a system integrator, an SI partner, of Salesforce, sit in the delivery of change, through for our clients, and making sure that it's as robust and as efficient as possible. But of the highest quality is probably the probably the biggest, you know, biggest way I could summarize it. I think what what I tend to see is that, you know, this is a DevOps summit, so I'm sure everybody on the in the audience already knows this. But what I tend to see is that there's a, you know, there's an element of dispelling the myths. But it's not just about development deployment with, you know, with a lot of our customers and, you know, a lot of people we speak to. But it actually covers everything from, you know, the requirements definition, the estimation, the design, the, you know, the delivery planning, the development deployment, obviously, but also the testing and QA and and the path to life, which isn't necessarily technical.
So, so that's what it means to me.
Hey. I can go next.
So agree with everything Sam said and, obviously, Melissa said. They explained it very well. So I'm going to keep it short. Devops to me is, about bringing innovation and stability together.
You know, without DevOps, you can't be innovative, but also, provide a consistent stable experience to whoever your customer is, or whatever systems you're maintaining. So like, you know, Sam said, it's not just about development. It's just not about CICD. It's also about making sure you can recover from errors quickly. You know, you you have more confidence when your go to market time decreases and your lead times with development, decreases. So that's DevOps for me.
I like that point, Emily, of making sure that you can recover from from any issues. That's a great point. Brian, is there anything else that you like to add?
Yeah. So I definitely agree with everything, folks have said so far. I think the only thing I'd add and not and not so much on this I'd probably everybody who's listening to this already knows this, especially if you're on this webinar. But what you hear a lot, you know, out in the out in the workplace, out in the wild is people sort of associating DevOps with a particular tool or particular technology.
So, okay, We're using GitHub now. Now we're doing DevOps. But we got gear set. Now we're doing DevOps.
And as people have said, it's, it's about the process. And as folks have said previously, it's about culture and collaboration, and the tools are are obviously an important piece to doing it right. But it's, as I'm sure all the panelists here have seen, there are organizations that have all the right tools but are not doing a sort of modern DevOps process where everybody's kinda using the tools differently, and there's not good collaboration.
So Yeah.
That is very true about DevOps being more of like a methodology, a process. It's something that you can practice, and I think that's really important to understand the importance of DevOps. And so with that, what direction do you see Salesforce DevOps going next?
I can since I went last last time, I'll go first this time. I think, and I think this point has kind of been touched on by previous speakers in this. But, what what I see in terms of, like, organizations that are really investing in DevOps and adopting DevOps, there's a couple sort of trends that I see, which, one, a lot of times when people are thinking about, oh, does our organization need to invest in a a a more mature DevOps process? A lot of times the metric that folks would look at is, like, team size, but how many people are on our team, and then our process is more complex, and we need to collaborate more. What I hear more and more and this gets back to kind of the ROI. How do we calculate ROI for DevOps, like Rob and Jack were talking about?
Like, there are capabilities that you probably don't even wanna embark on in Salesforce without a solid DevOps process. Like, one of them being like, okay. Are we gonna start exposing, Salesforce data to to not just internal users, but end customers. Right? Whether it's experience or cloud or some other delivery mechanism.
Your your ability to, like, have bugs or any issues with that goes way down. And you see organizations that aren't able to do those things because they don't have a a solid DevOps process in place. And I see that more in the conversation when people are thinking about, should we do DevOps or not? What's the RI in DevOps?
It's not just like we can deploy faster or we have fewer bugs. It's like, now we can do we can build more capabilities. We can build more services. We can build even more, like, revenue generating things for our business because of the fact that we have DevOps.
So that's that's one thought on that question.
I love that, Brian, because if you practice it in a small org, then you get good at it, and it's easier to stick to those best practices in a bigger org. Right?
Emily, what about you?
So I am quite excited about the state of DevOps in Salesforce, and and not least because I introduced it at Dreamforce at the architect's keynote last year. And it was still not released and it's still not GA. So I think people saw that demo for the first time. So very exciting.
And I'm also excited that it's the first time Salesforce actually has a DevOps tool. You know? We we being an enterprise suite of applications, I'm not even going to say SaaS anymore. Yeah.
You know, Salesforce is not SaaS. It's too big. And and we've got too much in there to say SaaS. But enterprise suite of applications without DevOps in today's world, it didn't stack up.
So I think adding that capability in Salesforce really makes it enterprise grade. So that that is the exciting part. But, of course, if you're you know, Brian was talking about tools. It's not the most mature tool in market because we've just released it literally, you know, a couple of months ago.
So the trend and the direction has to be it has to get better.
But it's an exciting move because now we don't have to do chain sets. You know, there was never a good way for environment migration or promotion of code in Salesforce. Like, never an industry standard or enterprise architecture standard way. With the introduction of the DevOps tool in Salesforce, I think that that changes the game a lot.
And I think it's the right direction because if you look at the product road map for Salesforce, Salesforce is focusing massively on the customer three sixty. You know, they want to be that enterprise application. They have MuleSoft underpinning everything and that that means APIs and code and integration with other, you know, enterprise applications and that needs DevOps. That tells me that the complexity of Salesforce landscape is increasing every day with every single enterprise that, you know, implements Salesforce because, let's be honest, no one is world to world Salesforce.
You know, it's all best of breed with with big enterprises. And for best of breed, you need you need the process, the development, the process, the stability, all the different IT teams, the business teams, the operations teams coming together and having the confidence that they have some sort of control over their landscape. And DevOps, you know, offers them that. So the direction, that Salesforce is heading in, you know, with the new DevOps tool, and I'm sure we'll see a lot more releases coming up, which will only improve these functionality and, give the right kind of integration with external tools as well.
Sam, you have anything to add?
Yeah. No. I agree with I agree with what Emily just said there, specifically about bringing peep you know, parts of the teams together.
You know, the I expect that, Salesforce DevOps will, you know, continue the, sorry, the direction, will continue, the investment in the native tools like DevOps center.
But I think it's that, it's the the impact has been that they've by doing so, they've taken a lot of the technicality, you know, out of the equation, which has always been a, you know, a bit of a barrier to entry, and embedded even citizen developers into more of a robust enterprise grade, as Emily said, and delivery process, but low code as well at the same time. So I think, you know, what's what's shifted the needle was, Salesforce acknowledging that the citizen developers are actually actually need to be part of the culture, need to be part of the process, and they're an integral part of, of, of making DevOps more, more successful.
And the other thing that I also, you know, think, is the direction they're going in is, obviously, with DevOps center and, you know, a lot of the other, best of breed, DevOps tool sets.
Source driven development is going to increase. I see personally that more customers that I encounter are more familiar, and less resistant to, to that concept. And and, actually, more and more teams are accepting that this is, you know, this is now the way we do it in Salesforce, and there's, you know, and there's a great amount of value in that. The other thing that, I think I think we're moving in a direction of is more automation in the, you know, in the DevOps process itself, and, ultimately, with the benefit of that improving the speed and the agility of, of the changes that we can actually deliver.
So, yeah, I I definitely see more automation going.
Awesome. Thank you so much, Sam. Melissa?
Yeah. Sam actually just took, what I was is I see more automation, companies moving towards more automation. So I I feel like there's gonna be higher adoption now because of DevOps center because the barrier barrier to entry is now a lot lower. With that tool being part of Salesforce, it's easier to use, easier to understand, more admins getting involved in the DevOps process. And, also, I see more team members having roles in the DevOps process, maybe even more on the business side, and everyone has some sort of defined role. And then the other thing I see is a lot of dedicated DevOps roles. Like, I've been seeing this actually, DevOps architect, which is an interesting term.
I've seen DevOps architect, DevOps DevOps manager, DevOps specialist. I'm seeing a lot of these things come through.
So which is a good thing because it shows that companies are understanding that as the bigger your your team grows, the more dedicated roles you're gonna need. So when you're smaller, it might be someone like a senior developer or lead developer playing the part of a release manager. Whereas when you start to get bigger, you need to have defined roles and gatekeepers. So I see that also being something that, companies are gonna start moving towards, and they're just gonna start moving more more along that maturity make metrics as well, the the, which you know, going up to the higher levels of DevOps maturity and also shift left. That's just a huge part of DevOps these days. Catch the bug sooner. Don't let them make it make their way into higher environments, and that's why the automation piece is so important.
That's really good info because, what you hear from from all of these amazing people is that remember, Salesforce is moving to more of a multi cloud, focus with customers, And they're starting to introduce industry solutions, which, will have multi cloud products in them, which makes all of these DevOps, processes way more important. And as you heard all of them say and all of our panelists say that DevOps is not up just about developers. It's about the admins, BAs, QA, all of these different roles. And so the next question we have is around how do, teams implement this?
And one question that we have from the audience was around streamlining release management for some Salesforce verticals and applications. And we all know that there are some, gotchas when it comes to certain Salesforce products, things like custom settings and all of these things. So do you all have any tips or, advice around implementing, these DevOps processes and anything around relief management?
And I'll start with you, Melissa. Sorry.
Sure.
So for streamlining the release management, it's really having a defined process and the roles that everyone's gonna play in that process. If you don't define those upfront, then it's really hard to follow, and it just kinda happens, ad hoc, and it there's more room for error, more room for mistakes. I was in an environment like that where we were using GitHub, but we didn't really have a defined process. We didn't have a defined developer process.
We didn't have a defined, we didn't have defined roles and who was doing what and when and when are code reviews happening. And we had builds that just blew up. Like, our our GitHub at one point had to go through a major, we had to go through a major merge conflict because of something that happened because process wasn't defined. So, I really see it as redefining that process and making sure everyone that is on the team is onboarded into that process and understands their roles.
As far as the industries, I don't really I haven't worked with them too much, so I don't have too much to comment there. So I'll let someone else that has more experience there comment.
Well, no. It's okay. It's more about, someone's asking about release management as well as just how to implement, you know, these trends that you're seeing on on their teams. But I just made the comment about the multi cloud because, again, I know that that's kind of where things are moving toward.
Yeah. And it is important to make sure you're including all the different, clouds that you're using in your process, things like marketing cloud and MuleSoft and not just Salesforce because these are all things that you're depending on in your project delivery. So really trying to, have a process for those clouds too, Commerce Cloud. So, yeah, it's important to include all of it.
And then there's a comment around, for you, I guess, Brian, to touch on as well is just some of the technical restrictions of the platform in the process.
Yeah. I mean, just to and just to add on to what Melissa's answer, and I think I think Richard might have said this in a couple talks ago. But in terms of streamlining, I think one strategy that I've seen work is rather than trying to sort of reengineer the entire process, Like, focus on one particular improvement you wanna make and start there. So if you're whatever.
You've got a bunch of different like, one of the anti patterns we've talked about is we've got a bunch of different people on the team, and everybody's using the different tools, and they're using the tools differently. So maybe if you're going from that, maybe, having a really jumping from that to, like, a really mature branching strategy or really mature version control or even maybe version control at all, start with something else or even start with just having a unified process and and start there and start to get some value as opposed to trying to, like, reengineer the whole thing.
Because I think somebody mentioned, like, that's where you get errors. That's where you get, like, big problems when you try to do too much at once. The other thing that happens is that can really slow the process down. So if you're trying to advocate for DevOps at your organization and you start you say, we're doing it we're doing DevOps now, and it's gonna be fantastic, and all of a sudden, like, releases are slower, like, that's not that's not a a a good way to make the case.
Thank you, Brian. Go ahead, Sam.
I was I was just gonna add, that, when it when it comes to sort of process improvement, if you're, looking to streamline the actual DevOps process, there's a, I don't know if everybody knows about it, but, we recently did did a a session on at our London architects, meetup, about the theory of constraints.
And, actually, sometimes when you've got a release train, you've got a, you know, you've got a DevOps process that's in progress, and it's, you know, got a cadence that it needs to stick to. Sometimes it is actually more efficient to stop, to identify what is the highest priority or most significant impactful constraint that is causing the problem or causing the blockage, swarm on that, you know, and spend the time improving and resolving that conflict itself or or, you know, that pinch point, and then start back up again, rather than trying to do it at the same time as you're, you know, you're actually progressing everything.
There may be another constraint that then comes off the back of that and do the same thing for that. So the theory of constraints can really streamline that process where you've got, as the example was given, a you know, the the limitations of the platform, which mean you're probably having to deal with post deployment steps or, you know, proprietary tasks in order to get the, you know, get the get the change, progressed or promoted.
Actually, look at that constraint itself. Like, how how can you solve that constraint first and then get on with it? Yeah.
Awesome. Thank you, Sam. Emily?
Not a lot to add there. Everyone said a lot. So, I I'll just talk about the constraints a little bit, the same as Sam said. You know?
Yes. It's right in Salesforce, especially, you can't have everything go through an automated pipeline. You know? Sometimes they're custom settings, etcetera, which you you just can't put in that DevOps, sort of automation.
But defining a robust process is the work around that. So, you know, have have the steps defined, have it communicated, have QA gates with check for these port post deployment steps or pre deployment steps, and have a a quality assurance layer. So it's not ideal. You know?
Not everything is automated. So it's not like you can run it overnight and next day your deployment is ready to use. But if if you're aware of these constraints, build a robust process around it to to make sure that they're not falling through the cracks. Roles and responsibilities, which Melissa talked about, very important with these, as well.
So literally, a process cannot work unless you have a very clear accountability, and responsibility matrix defined because you can have all the process in the world if you can't hold someone accountable or if someone doesn't know it's their job, actually, to make sure that, you know, the post deployment steps are done. You could write the best document in the world. It's just not going to get executed. So I think it's the process, the QA, and and quality gated is the way around it.
Thank you so much, Emily.
So I think we have, we went we talked about so much in so little time. I think I have, room for one more question.
So let's talk about I'm looking for to see which question I wanna ask.
I think we've kind of talked about trends. Right?
So let's talk about the demand for certified Salesforce DevOps professionals.
And so I I know a number of you mentioned that, I think Melissa mentioned this, that you are seeing more roles. And so can you all talk about, if you think that that will continue to increase?
And if so, for people that are looking to pivot into that area, what do you think would be, you know, some tips for them in that area?
And, Melissa, I'm gonna start with you because I know that you're currently training some people and thinking about this as far as career building. Right? Because I know that a a lot of people are probably here to hear about the process. They're here to hear about the tools. And so Yeah. Can you speak to that a little bit?
Yeah. So what I learned in my CTA journey is the importance of the process and the roles. That's why I speak about that, the governance around it all. So it's like we've said, it's not gonna work unless you have the right people on the right process.
So I think companies are going to see just like they understood that architect was a very important role, and that's kind of exploded over the past, I don't know, five, six years. I think that DevOps role is really gonna start to come to the forefront in some certifications to back it up as well. I know GearySat has a new certification. I know Capado has one.
Salesforce has their dev life cycle architect certification that you have to do as part of the pyramid for CTA. So I think requiring these things and showing that someone has the training, not just on the tool, but on the process itself and understanding the governance is is gonna be critical in in these roles, starting to become more apparent and more important.
Thank you.
And and I was gonna say too, like oh, sorry, Tiffany. Do you mind if I jump in?
Yeah. Okay.
I was gonna say you you sort of mentioned this idea of of sort of dedicated, DevOps professionals, which I think is totally agree that that's gonna be more of a thing. Like, you know, DevOps isn't something like, okay. We do an initiative. It takes two months, and now we're doing DevOps right. And that's like, it takes a long time, and there's tons of opportunity to add value and continue to improve. But I also think, like, on people who aren't sort of DevOps specialists, sort of your your your regular admin developer architect, like, DevOps ability and experience is gonna be more and more, like, required and more table stakes to just having those types of those roles. So I think there's there's there's opportunity, like, across the spectrum to to skill up in this area.
Thank you. Emily? Yeah.
The only thing I can add to that is, what I said previously.
If you look at the sales Salesforce landscape, it's going towards, enterprise grade, multi cloud, customer three sixty, and all of this brings complexity. And DevOps is one way where organizations would would need to deal with complexity. So these roles are definitely going to be up on the rise, and, obviously, certified professionals, in the Salesforce ecosystem are always highly valued, you know, especially, that's that's one way of of gaining credibility, in the role. But also, I think this is a this is the right time to get into Salesforce DevOps because I think the product itself will mature. The approach will mature. The integrations will mature. So someone getting into it right now will actually be along with Salesforce, you know, will will mature their journey, for the product itself.
Yeah. Thank you, Emil. Sam?
Yeah. So, I agree. The I you know, the way I look at DevOps, it it applies to Salesforce, and Salesforce isn't quite nuanced as a platform just because of the way it's, you know, built and architected, especially when you you got multi cloud and, and what are essentially different technologies under the hood. But the core principles of DevOps are universal, and they're only likely to be sort of additive, with the increase in automation and AI as well. We haven't really talked about AI as a trend in DevOps or AIOps as as people are calling it, but the skills are in DevOps are transferable between the technologies. Like, when you deploy from, you know, in one technology, for a platform, it's, you know, it's fairly similar in its core, you know, competency to another.
So to to be able to employ someone who's able to apply that that, you know, course and knowledge and skills, with a tech stack, It it's absolutely invaluable. And a lot of the a lot of the platforms, the the the DevOps tools themselves are, are providing academies and universities that offer the training materials and certifications to to to for for people to evidence that knowledge and upscale themselves.
What I tend to see is the the natural sort of evolution of the platform means that a lot of the implementations these these days are more complex.
They're more large scale because we're going from what what used to be just sales cloud to their multicloud.
But that's that means, especially with multiple technologies like the middlewares and everything, that all need to be, sequenced and streamlined in a DevOps process.
You do need a dedicated DevOps manager that either looks after the environment management or development management or deployment management or test management or release management. One person can't necessarily do all of that. Therefore, there needs to be dedicated roles for each of these.
Yeah. And I I I don't think it things like automation and AI necessarily change the value of the human in the process.
The power of a human to discern the net effect of a combination of issues in a deployment or or, you know, an implementation or even a design, is far beyond what any automation can achieve at at the present time. I'd love to see that, though. So, you know, when when Excel came around, it didn't change people's ability to do work. Right?
It didn't replace people just because Excel was there. It just changed where we focused. So I still think that's a necessity for for people.
