Anup Jadhav joins to talk about Salesforce governance and change management in Salesforce.
Anup is a Salesforce Developer MVP, Co-founder of London Salesforce Developer User Group, Technical Architect.
Sponsor
Proton Text is a complete SMS texting solution built for the Lightning Platform, and by one of our previous guests Pat McClellan.
Main Points
- Anup’s self-introduction
- Anup and Francis hosting podcast – Salesforce Posse
- Governance and change management in Salesforce is critical
- What is governance and what is change management
- Technical process part
- The non-technical business process part
- In Anup’s opinion, the key is alignment and autonomy
Links
Video Teaser on Salesforce Governance
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] Our sponsor today is Proton Text, a complete SMS texting solution built for the Lightning platform by one of our previous guests, Pat McLehame. Here's reason number two that admins and users love this app: easy automation. Pluton Text uses platform events and invocable Apex actions, so admins can create automated texting that is customized for the needs of their work and users. Starting with the app's open source automation library, admins can set up text notifications, appointment reminders, text leads, and text cases, audience polling, customer surveys, and all of it built with processes and flows. It's not magic, just good design. Check out the Proton Text open source automation library at protontext.com.
[01:11] Hey everybody! This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today I'm sitting with a new guest. His name is Anup Jadhav. Hello, that's right. Hi Xi, how are you? I'm good. I'm good. Excellent. Really excited to talk to you. Likewise, thanks for having me. So, Anup, would you like to introduce yourself? Sure. So I'm Anup Jadhav. I am a Salesforce technical architect. My current role is I head up an engineering department at Zurand Writing, which is an insure tech company. I've been doing Salesforce for ten plus years now, and I've seen it all. I started as a before Salesforce, I was doing Java development, and then I stumbled upon a company who was using Salesforce, and I was right there in the beginning when Force.com was launched. So when I looked at Force.com, I saw an opportunity to learn a new technology, and I was quite excited by the. Potential of that platform, so I taught myself Apex and Visualforce and switched career track from Java to Salesforce. And I haven't looked back since then. So I've been a Salesforce developer, Salesforce technical lead, solution architect, technical architect, enterprise architect, managing a big implementation team. I've done it all. I've seen small size projects, medium size, big size,
[02:41] successful projects, projects fail, and it's one of the top. Well, our topic of today is about you know how do you ensure that your Salesforce implementation is successful? That's cool. Gets you a better ROI. Yeah. And in addition to that, I know you have a podcast. I do, I do. I I blog, and I do have a podcast podcast with Francis Binder, who's known as at Radnip on Twitter. So the two of us talk about. Development and architecture on our podcast, which is called Salesforce Way. So, if you'd like to check it out, you can go to SalesforceWay.com. We have two more episodes coming up, so hopefully that should be live in the next couple of weeks. That's cool. We keep it. We try and keep it updated on a regular basis, but both of us are quite busy, so it becomes it's challenging to kind of keep adding new episodes. But we try. Definitely, I know. I know how much work it involves, not just two people talking, right? Yeah. And definitely, I will put the the podcast page link in our show notes. You know, for our listeners to check. The more podcast we have, the better. You know, for the community. I cannot agree more. Yeah, that's right. You know, information sharing is great. I mean, one of the good things about our community is it's it's a friendly community, very collaborative, and people love to share information. That's cool. Yeah. Let's start with our topic today. So you said we're going to talk a little
[04:11] bit about the governance and the change management. I think maybe that's a bit because you're working in the insurance company. These things are critical. Is it so, or you already have this passion? So. I think governance. So you're right that in insurance and in regulated industry, governance is an important part of, or rather, having good governance is critical because you're you have to.
[04:44] Follow some rules that are set out by the regulators, which means you have to keep your data secure. You know, even before GDPR, regulated industries were had. Have to make sure that their customer data, sensitive data, is secure, or the regulators would find them. But governance and change management is a broader topic than that, and absolutely it applies to regulated financial institutions, but it can apply to non-regulated industries as well and other domains like media and other sectors. So, so yeah, I mean. I'm quite passionate about governance and change management. It's one of those things where Salesforce can do more, and there is a lot of opportunity for the platform to grow. You know, in in Salesforce world, when I started back back in 2008, we had Apex, Visual Force, and the way to deploy these things was through the IDE. So we had the And migration tool, we had the metadata API and we'd use that to deploy from one environment to another. Over the years, that process matured and migration tool became more robust. So we could kind of script around that, you know, write scripts to automate that deployment. Then change sets came along, which Kind of made the in a way introducing another way of deployment added more
[06:14] challenges because now you had two ways of deploying things, which means tracking changes becomes difficult. Yeah. So. Governance is broader than that. Change management is part of that. So, what what do I mean by governance? You know. So, at its most basic, governance is a framework for how organizations operate and make decisions. So, if you don't have a governance. Process or framework in place, then you can't prioritize all of the requirements that you're tackling. You know, and if you work on a typical Salesforce project, you have a huge backlog of requirements, and that list just grows. You know, you have users providing feedback, you have bugs, you have new projects coming in. How do you decide? Which request to implement, which feature to implement first, or which initiative to pursue? So governance gives you a framework to make those decisions. And this is different from like a technical governance, which usually, for example, an admin they need to validate the data, clean the unnecessary data, some some user account to deactivate those stuff. So this is a different angle. What you're talking about, it's more like a higher level, right?
[07:45] Correct and technical govern governance of that sort is becomes part of the strategy, right? So one of the outcomes as part of your governance would be that you want. Clean data set. Yeah. So, what do you do to to achieve that outcome? You set up processes where you do. You probably have identify one or two people from the business who are data stewards. You know who are responsible for making sure that the data is clean in the in the Salesforce org or orgs that you might have. And they run regular reports. They do all of the data cleansing activities on a regular basis. So these are processes which serve an outcome, which is. Cleaner data or useful data inside of your org. So, as as part of governance, what you would have then once you have the vision set up. Then you define the the process. Okay. Now there are two parts of this process. This process, business process, and there's a technical process. The technical process can be summarized as the development methodology that you are you may or may not have. It is quite, or at least I've found that on a lot of projects. That process is not defined. So, you might have one or two developers, maybe an admin. You know, they they are possibly using something like Jira to manage the stories and backlog,
[09:15] but then there is no process to deploy that change from one environment to another. In some, in a lot of companies, they don't even use things like version control. So they work on the story. They deploy that change. A developer might use their ID to deploy from their dev environment to QA. An admin might might use change sets. What happens there is that you don't have any tracking or auditability, auditability of your changes. Now, me coming from an insurance background or working in the insurance domain. And financial services domain, you know, if an auditor comes then, and they kind of take a look at this process, they'd be shocked because they'd be wondering how do you track your changes? How do you know that something that went to production which accidentally. Exposed customer data, how was that change tracked or reviewed, right? So, but then that that can be true. The GDPR age it applies to all organizations, not just financial services. So you need to be able to track all of the metadata changes that you are propagating from lower environments to higher environments. It also helps you. If you have a technical process set up, and I'll talk about what that process might look like. If you have a technical process set up, it also helps you identify issues early on rather than in production. Many times, because your changes might be localized. You know, you might be adding a validation rule for a specific business
[10:46] requirement, which will have An impact on another part of the system. So a trigger might be creating a record without entering the field value for which you have the validation rule, but you haven't tested that functionality because all you tested was that manual flow with that validation rule. So having a more Repeatable, auditable technical process helps everyone. Now, what does that look like? So, an ideal process for me, and I'm not going to give a Salesforce DX example. I'll give you a non-Salesforce DX example, but then it it has elements. This is where Salesforce DX is going, you know. So, what you would have is different environments for different things. So, you'd have a one or you know either one dev environment where all developers and admins work. Or you could have one dev environment for each developer and each admin to work. I think that's less important. It all depends on how complicated your org structure is. So let's take a simple example: one dev environment for all devs and admins work. Now, once they've kind of, let's say they picked up a ticket from Jira or any other project management tool, they worked on that ticket. A good technical process would then say, okay, you now need to deploy this change, but if you want to track this change, you need to track it in version control. So whether it's a dev or an admin that makes the change, they would then create
[12:16] a pull request. They should be using a version control. Most popular version control system is right now is Git, and you can use Git Hub, Bitbucket. So you would create a pull request. That gets reviewed by one or more developers or admins. It gets merged into the QA branch, for example, and then an automated process. And what I'm describing here is a continuous integration process that can be set up. Then an automated tool like Jenkins or Travis CI or Circle CI will identify that merge, take that change and deploy it to QA environment. Before deploying it, it will run all tests. Let's assume you've got Apex tests, and you know if it works, it's good, it's deployed. If it doesn't work, then it'll notify the developer or the admin who deployed that pull request, who created that pull request. Yeah. Yeah, let's let's have a quick summary here. So you mentioned basically that the pipeline thing is more or less is called DevOps, right? So we have the automations, or we have the code review, whatever quality gate somehow inserted into the pipeline, different stages, and that ensures each time when we have new code, new meta data changes. Certain quality validation happens in between, and then it goes along the journey to different environments, so that the quality is always assured. Along along the
[13:46] the path, right? Correct. And I think for developers, more or less, people have heard about this. You know, it's been many years like this. Ant tool, this Salesforce migration tools. And the Jenkins definitely has been integrated. Again, the question and the challenge is always how to make sure everybody in the team really understand the pipeline, use the Git, the version control in the good manner. And this is where this is where having a governance formal governance framework helps, because as part of that, you've kind of said that this is the technical process, DevOps process we use to to do any changes in our environments, and if you. Set out the rule that this is how we do deployment, and but then at the same time support whoever, whether it's a developer or an admin who joins the team, to learn how to use both version control and the pipeline and how to deploy through these environments. Because the initial learning curve. Can be steep, yeah. But the long term payoff is very high. You know, once they might they might spend three or four weeks struggling to use this. There is a temptation to just kind of oh it's a small change let's use change sets to deploy this. But once you set the rule that this is the only way to do something. You kind of said the you know either you like doing this yeah and you adapt you know everybody's adaptive and
[15:17] admins are also quite technical these days given the kind of complexity they they deal with on a on a day to day basis with flows and process builders so. Even though they're not writing code, they are thinking like a coder. So, I think we shouldn't underestimate their their ability to pick up these things. And in to in today's world, learning version just to reiterate, I I think I might be repeating myself here. Picking up version control skills is crucial for everybody who's involved in technology implementation.
[16:01] Hey! Thanks for listening to the show, Salesforce Way Podcast. It's all the time looking for both guests. And topics. If you have guest recommendation or any topics you like listen to, don't hesitate to let me know. My Twitter, LinkedIn, and email information is at the end of the show notes of each episode. You can also find it on the SalesforceWay.com website. I really, really, really need help from you on this matter because only you, my lovely listeners, know what yourself want. So, please help me invite great guests to talk on great topics, so that we spread great knowledge. Now, let's get back to the show. On this point, I think you are more optimistic than me. You know, I I I truly understand. I agree with you. It's critical, and it's a really good tool skill set under your belt, right? No matter it's admin or developer, but to me usually I hear the argument is that either admin or consultant who are using declarative tools only. They come because you don't need to touch technical details, and that's the reason they they have avoid to use
[17:31] like a version control or the command line or the Git tools, you know. And this is something they don't want to do. That's kind of a mindset. I I agree with them. I mean, they come here that they never expected this coming, and now Salesforce is like, you have to learn this. Well. This is where, if you have this process in place, then the challenge is not whether they have to use it. The challenge is how do you onboard them to use these things? Then you give them the knowledge and the training and the support to use these tools. You know, they're completely valid in saying that they've never had to use this before, but if you're Process maturity is high, and you already have this pipeline set up. You know you've got Jenkins or Travis CI or everything set up. Then the challenge is how do you onboard non-technical admins to start using? And the tricky bit is just the version control bit, right? Once you kind of teach them how to create a branch, how to create pull request, and how to do reviews. Once they've gone past that learning curve, then it's easy because everything else is you know we you're not suddenly asking them to write or review Apex code or write Lightning Web Components. They continue to do what they're doing, creating workflows, process builders, flows. What what's
[19:01] changing is that and they understand metadata. What's changing is that they just need to understand how to then take that metadata and add it to the pull request by creating a branch. Yeah, I think sooner or later, definitely admins, consultants who are using the clever tools, they will start using. Position control. I think where Salesforce is heading with Salesforce DX, it is becoming more and more important for everybody to know these tools. I know Salesforce DX is very much command line heavy. And I think that's probably one of the criticisms. Yeah, but it doesn't have to be as as Salesforce DX matures. I think they'll have more, possibly more declarative, yeah, declarative UI tools to manage this. But Understanding version control still helps even in that environment. So, so yeah, that's kind of the the technical process around this. Now, that's you know that you don't stop there. So you have that process in place. Then you need the the support around delivering these things, which is the business support. So you know how do you how do you make decisions? How do you keep track of progress? And you do that in a in a number of ways. You now this is. This is where people might say that it becomes a bit process heavy, but it's still useful. So you, you could have a steering committee which is composed of all of the business stakeholders and decision
[20:31] makers. It could include C-level execs. And this steering committee is responsible for the vision and the high level roadmap because vision and roadmap is never set in stone. They constantly evolve depending on the changing business needs, consumer needs. You know, tomorrow there's there's a new business model that the business needs to. To build or adapt, then they need to change the vision and the roadmap accordingly. So the steering committee is responsible for kind of making sure that what's being Built matches the reality of the world. They can also make decisions around budget approvals and you know project initiative approvals and stuff. Now under that steering committee, you can have a a project committee which is responsible, which is a bit more low level, and they're responsible for specific projects where you review. For a big enterprise, it's common that you could have. Three or four initiatives running in parallel, then you have to make sure how these three initiatives specifically, if they're in the same org, how do they, how how are they built in parallel? What you don't want is duplication. You know, one initiative is building something that initiative number three has already built. You know, this reuse aspect of this. The other aspect is conflict. You know, you're building something here that actually conflicts with something that the other project is trying to build. So the project committee
[22:02] keeps tabs on all of these different initiatives and kind of says, okay, this is. This is where we can reuse things. Now you could have multiple levels in this. You know you could have a technical design authority which reviews all of the technical things. Depending on how large you are, the more components you can add to this. I'm not saying that you have all of this, but I'm saying that maybe you can start small, but by just having one steering committee and then you know then grow from there as, because Salesforce, once you start building on Salesforce, it's just going to grow and grow. Once it becomes key part of your business process, it's very much likely that your usage of Salesforce will increase. You'll have more data in there, even though it's a systems of records, it will interface. A lot with the assistance of engagement, which is your website or your app or whatever, it relies on the data in Salesforce. So you have to just kind of plan for that, and you have to assume that that implementation is going to grow. Which means the time and money invested in creating this committee and the process is worth it. I see. Yeah. So. It's a lot of things you just shared. You know, we started from the technical part, how to build a technical release tool and the pipeline, right? And then, of course, there must be something from the business to drive. That the technical
[23:32] pipeline. Why you are doing that? What's the purpose of doing that, right? And how to adjust the items inside the pipeline? So that's the business. You have this steering group. You have the commute. What is committee, right? Project committee. Yeah, yeah, yeah. So different levels. It depends on the size of the company, right? So they drive layer by layer down to the technical part. Yeah, I think the key thing is alignment and autonomy. Okay. The more alignment you have, the more autonomy you can give to people down the the hierarchy. If there is No alignment. So if people down the chain don't know what the overall organizational goals are, they're not aligned. Then they won't make. They won't be comfortable making decisions. But if you have high alignment in terms of the goals and the vision and you know what the outcome that's that the the company desires. Then you you can push down more autonomy down the line down the chain rather, and how do you have more alignment? You have more alignment by having better communication between different layers in the hierarchy. So better communication leads
[25:02] to good alignment, which leads to more autonomy. The governance and change management framework gives you, the structure, to do all of these things: to communicate, to have better alignment, and also to be able to give more autonomy down the chain, so that the project managers, product owners, developers can make decisions, because. Important decisions because they know what the desired outcome is. That makes sense. Yeah, and I think what you just mentioned applies to Salesforce, but definitely applies to other IT systems as well. Like if you have SAP, the same principles, right? Yeah, I think that's that's just a general thing within an organization. But yeah, yeah. So it's more to me. It sounds like like an enterprise architect who is kind of like drive these and make sure all these layers are are working aligned. Yes, I think if you are an existing Salesforce customer who Who thinks that they're who are not sure what the implementation is like, and who know that they have these problems of you know deployment not being able to track the changes, systems are hard to refactor. Even a small change takes a long time because there's a lot of custom implementation. Where would you start? So you would first start by identifying where you are. So what you should be
[26:32] doing is, you should do a health check of your organization, or not just of the implementation, but also the process, and also identifying all of these. Nuances to decision making on how things are being prioritized. Once you've identified how good or bad your implementation is, how broken your technical and business processes, and what kind of structure you're operating in, that's when you can start looking at okay, this is where we are, and what we want to where we want to be. We want more agility. We we want to be more scalable, and how do we get to that? And The whole thinking about how to set up governance and change management can then begin because now you know where you are at least in the context of Salesforce. So do a health check, hire someone or do if you have an internal architect, get them to do a honest review. So the health check, the purpose is not to identify issues and. Point fingers. The purpose is to do an honest assessment of your implementation and process, so that you can identify the gaps and create a more long-term strategy on how to fix these things. You will accumulate technical debt. You know that's the it's it's it's not a Salesforce specific problem. It's a problem for all implementations.
[28:03] Yeah. You know, even if you follow the best practice, best practices, you will still accumulate technical debt because when you are building something, you probably don't have. Typically, a developer doesn't have the same domain knowledge as they do after they spend some more time within that domain. So initially, they will build something that's. Short term, that you know, based on their current understanding. But as their understanding grows, they'll look back and say, "Oh, we could do this in a better way." So when you write something, you're introducing technical debt. The key thing there is to how do you address that technical debt on a regular basis? It's it's. Easy to say, but difficult to implement. You know, you need to have kind of go back and take care of some of that, pay off some of that debt. Otherwise, it keeps on accumulating. Another analogy that I like to use is snow shoveling. You know, if you're there's snow in your driveway, sometimes the way we accumulate technical debt is you just keep shoveling snow forward and forward. And by the at some point the snow is so piled up high that you can't go anywhere, and that's that's the visual analogy I use when you're building systems. What you need to do is just get rid of the snow, you know, put it push it sideways, or just throw it away, or do something about it, rather than just shoveling it forward and forward. So you do a health check, identify where you are, identify what your technical debt is. That's not sufficient. You also need to identify what your process gaps are and use that to then define
[29:33] all of these governance and change management processes. Because Salesforce is a big implementation for you. You know, it's a it's a big investment for a company. Sometimes they they spend. Up to mill, you know, lots of millions of dollars on license fees, but they won't get an ROI if the if a simple change takes weeks or months to do because the promise of the Salesforce platform is you can go from design to launch in days. But the bigger you grow, the more difficult it becomes to make that change. But if you have these processes in place, if you have this governance framework in place, then you can actually make change every day if required. Cool, there was a lot of information. You know, these things, I think most of developers won't really think about it. Because we are writing code, we are get the the assignment finished. You know that's our daily job, and there are different scales. You are really looking from a much larger scales. You're talking with the business stakeholders. To make sure they are driving on the correct direction and even pushing down further. But I believe it's it can be a developer's or an admin's responsibility to highlight these things to their management, because. It's very rare that you know everything is going right in whatever project you're working
[31:03] on, and usually these issues are a number of smaller things that are going wrong in a number of different places. So you just need to kind of start thinking about, okay, how do we We know that things
[31:19] will become more and more complex. How do we set up a process that helps us deal with this complexity down the line? You know, and even if you're a developer.
[31:34] Identifying these things and creating a strategic solution, or at least proposing a strategic solution to the decision makers, is a useful thing for your career. You know, it helps you think. Look at the entire forest, than just looking at a single tree, and you can. And it's useful for anybody, you know, a developer and admin to have that kind of view. It's not just a responsibility for the architect. No, you're welcome. Yeah, thanks a lot. So I think it was valuable. It's definitely valuable, and I love to. I mean, even though this is a so-called a Salesforce Developer podcast, but these things I do want to bring in every now and then. You know, these are invaluable information, and it really makes developer a better one. All right. Thanks a lot, Anup. Yeah. See you next time. Thanks, Xi. Thank you. Bye. Bye. To
[32:34] bind our fortunes, damn what this does and rend my heart open. Then your love profess, a winding, weaving fate to which we both attend. You flee my dream. Come the morning, your scent—berry star, lilac sweet—to dream of raven locks and twisted stormy, of violet eyes glistening as you.
