Maximizing DevOps ROI

Share with

Description

Salesforce DevOps is proven to help companies see a return on investment. Ian Gotts, CEO and Founder of Elements.cloud talks through how change intelligence goes hand-in-hand with DevOps and how you can check you’re on the right track.

Topics discussed:

  • Change intelligence and course correction
  • Business analysis and documentation

Learn more:

Relevant webinars:

Transcript

So for those of you who don't know me, three numbers to, help you. Ten twenty thirty, ten years as a consultant, living as a partner at Accenture. I've spent twenty years in the Salesforce ecosystem as both a customer and a partner. And of those thirty years, it's all around business analysis and change. So you've got my email address there, or you can, hit me up on LinkedIn.

Well, I wanna spend time thinking about how we drive time to value. By time to value, I don't mean how quickly you can implement, but how we get from an idea to adoption by end customers of which DevOps is a part. But we think that's actually DevOps needs to be twinned with, change intelligence to really drive that value out and exploit the value that you get from Salesforce.

So, there was a report by Forrester who looked at DevOps and said that, there's a three hundred and seven percent increase in return on investment if you implement a DevOps solution like Gearset.

And it says eighty percent faster to deliver user stories, and I think you started to hear that from both Andy and Kevin earlier. We're also eighty percent faster to recover from failures. But I think that last metric is a bit weird. We shouldn't be having failures. We shouldn't be worrying about that. Obviously, if we need if we have a problem, we need to roll back quickly, but we should be aiming for, I don't know, very rapid implementation of user stories and never having to say sorry, never having to recover from failure.

So, picture of me there sailing a a hydrofoiling moth, and, my passion was sailing, competitively.

And something we used to say there, which is the faster we go, the further we go in the wrong direction. And I think that can be true of DevOps.

Yes. We're building very quickly, but unless we're building the right things that the customers really wanted no. Actually, that's not true. Not what they wanted, but what they need.

They don't necessarily know what they what they think they want something, but, actually, it's what they need. If we're not building what they need, when it comes to deployments, they look at us and go, that's not that doesn't help me. And therefore, we're not getting that time to value. So what we need to do is make sure that we're supercharging DevOps by making sure we're building exactly what the end users need.

So I think DevOps needs to be twinned with change intelligence, and I did just think that. I know that from we're seeing that in customer after customer to make sure the implementation is going in the right direction. But, also, we can make course corrections at pace with confidence, never having to say sorry that we broke something, but also being able being very responsive as customers obviously are expecting, their dev teams to be very agile.

So let me try and explain what that means very quickly. If we think about a typical, implementation life cycle, right, we're validating requirements. We're defining the work items, the user stories, or the, work items, however you want to define that. That piece of work that gets passed to development. And then you're building, testing, documenting the solution. And if we think about the the materials or the act, first of all, we're starting with changes or feedback, which which is the the wish list. We then wanna turn that into business requirements, which we validate by mapping out a business process, looking at an entity relationship diagram.

And with that, we can then build the work items, that user story. But that work item, we also need to look at the metadata dictionary and do some org risk analysis so that the user story were passed into development. Number one is correct. Number two has enough background so that the development team understands what they're building without any ambiguity. And thirdly, they understand the risk of making those changes so they can allocate the right level of resources.

And then, obviously, the development team can then build it. We then have a solution, and, ideally, we have some documentation associated with that solution, which means that when we come around the the cycle again, all of that analysis is quicker and easier.

So we like to describe it in very simple terms. I'm a bear with a small brain. I like simple things. So we think of the first piece as build the right thing, change intelligence, and then the second area is build the thing right. That's about DevOps. So if I put those terms in there, change intelligence is build the right thing, DevOps has build the thing right, which is why these two things are so complementary and fit together so nicely.

So when I think about the benefits from a DevOps perspective when you add a change intelligence platform like elements associated with any implementation, First of all, we're making sure the development team are building the right stuff. And the benefits of that are clearly reduced rework. We're not looking at, a bit of functionality and then go, oh, actually, I didn't really understand that. Sorry. I'll I'll have another go at it. If we're building the right thing, that must increase adoption. End users are getting exactly what they need, and therefore, that level of, adoption will go up.

And the the last the last thing in that point is we're reducing technical debt. We're not building things we don't don't need to be building, which we then need to take out. We're not building a record type, putting in a record type and then realizing it wasn't a record type we needed, but it actually was a a pick list and a different set of reports. And if any of you seen any of my, any of my articles, record types like glitter. Once you've got them, you can never get rid of them. Very hard to get rid of. So first of all, making sure the development team are building the right stuff, and that's fundamental.

That's all about that that last slide, which was about the faster we go, the further we go in the wrong direction.

The second is making sure the development team are able to do their job well, that they have a clear user story that's not ambigu ambiguous, that they have all the supporting information. They have a link to a process diagram. They have all the discussions that were were during the business analysis phase. They have links to requirements.

But then also they have a change impact. They have already got that analysis of if I touch this metadata item, the the impact is that we also need to consider this, custom field. We also need to consider this Tableau, report. We also need to consider this Slack integration.

So we we get in they are able to walk in and start building something, understanding the true implications of the changes they need to make. That again with the benefits, reducing rework, they can accelerate development because they're confident they're building the right thing and they have sufficient information, And, also, we're reducing those rollbacks.

If we have a true understanding about the impact analysis in making a change, we shouldn't be surprised by metadata changes that blow up when they get into production, which is obviously the the cause of rollbacks.

And the last point there about the user story risk means that you can allocate the right resources.

I I wrote a a slightly, emotive article saying develop and production, which got a lot of people very upset and aerated about it. But, again, maybe maybe the title was clickbait, but the point about the article, if you read it, was not every change needs to go through this long change cycle where it's got to go through, I know, three sandboxes, UAT sandbox, integration test sandbox, and then into production.

If we understood the risk of different user stories, we can then allocate the level of development effort, test effort to those user stories based on the risk level.

If we genuinely understand that this is low risk, we can take maybe a fast path. The problem at the moment is with no understanding about the implications of change, we have to assume everything is going to blow up on our faces. We have to assume everything's high risk, and we have to assume everything goes through that long change cycle, go through that pipeline of the development. So if we have a better understanding about the risk, maybe we can actually have some different paths, the fast path where we know it's low risk, but then we have the longer path where we know that we need to do a lot more testing. We need to do a lot more integration testing. We need to do a lot more, user testing.

So the benefit of that, of course, is we end up with more frequent releases if we can then strip out those ones which are high, sorry, which are low risk. We can then put them through a a a faster deployment cycle.

We use this approach internally at Elements. We did seventy seven releases this year, and that's just the major releases. We've done a series of minor releases below that. So we're driving those changes into production more quickly, which is increasing the trust we get from our business users that, actually, we are delivering the changes they need. It's, and it's also increasingly the trust that when we put things in, we're not gonna break. I think that we've not really talked about that, but improving the trust between business and IT, IT, that IT is responsive to business and they are not gonna break the business with the system changes they put in, that, increases that trust, but it also means it gives a better chance of, the business users, coming back and actually asking for for the changes they genuinely need, and that means that will drive up adoption.

So more frequent releases, the second benefit is faster deployments. And the third thing is we're reducing rollbacks. Again, a better understanding about what the risks are means we shouldn't be putting things in and having to roll them back.

So clear benefits for DevOps in terms of putting change intelligence in place. But but what is a change intelligence platform? Let me just talk about the anatomy of that.

So I think it starts with a metadata dictionary.

I'm sure you can build an Excel spreadsheet, but it's a thankless task with the the speed of change that's in orgs.

We need to use the metadata API, the dependency APIs to do a lot of this heavy lifting for us automatically.

So building that metadata dictionary for Salesforce on the core platform, building it for industries where the metadata is stored as records.

So they that's the first two things on that list. And nightly, we should be building this metadata so it's constantly up to date so the development team know that they are working with the most up to date version. But now Salesforce is no longer just core platform.

It it it's now strategic inside organizations.

It's touching multiple systems. I've I just added a couple there, but but we any change could be touching core platform, could be touching Pardot. It could be touching, Tableau. It could be touching Slack. It could be touching, I don't know, other external systems.

So we need to be building metadata dictionaries for all of those so we then see the combined impact of making a change. So that one change that we're saying, I'd actually like to add a new record type, because we're thinking about, approaching a different, a different customer with a different value proposition, that has impact on maybe a new report in Tableau, kicking off a different notification in Slack, maybe pushing something into Pardot for lead nurture. So no longer is a change just just focused on that one area, which is, the Salesforce core platform. So we're looking at, this metadata dictionary in a broader perspective, multiplatform, and even outside Salesforce.

So So that's the first thing. That's the core of it. The second is then having a place where you can do some solid, rigorous business analysis, which everyone can access, and it all gets connected.

So feedback, requirements, those business process maps, entity relationship diagrams, all of that needs to be versioned and connected back to the metadata items.

So So when you're the development team in DevOps and you're saying, I'm about to change this particular, field, I can see the feedback, the requirements. I get a history of all the user stories that had touched it. I can see the business process it touches. So I'm getting a broader picture, which means that I understand from a development perspective why I'm building this, which means I can build it more quickly with more confidence.

And, obviously, that that that key point and and the key pivotal thing is that user story. That's what's being passed to development. That's what's being developed in the business analysis teams, passed across the development, maybe via Jira or maybe directly to the development team. So there's a tight integration between an element's user story and Jira, and then Jira back into the development of DevOps tools.

So that's two aspects. There is one third aspect. And people say to me, that's great, Ian, but I've already got documentation everywhere, and do you want me to start again? The answer is absolutely not.

We should be using this metadata dictionary to link to all that existing content, whether it's in Jira, Gearset, it's testing in Provar, whether it's, notes, screenshots of that last, workshop the architects did. It's documents in Google, SharePoint, in that or in Box or in Quip or Google Docs, or it could be LucidCharts. So you you've drawn diagrams in LucidCharts. All of those are valuable assets that'll help the DevOps team make sure they can build the right stuff more quickly, and that's what it's all about.

And that all, again, should be connected. And as I said, this metadata dictionary is pivotal. That's where everything gets connected. It's the single source of truth of the configuration.

And that gives you the level of intelligence so you can make change quickly. Hence, change intelligence platform.

So I believe that change intelligence plus DevOps gives you time to value. That's about end users, the the platform owners driving better value from Salesforce, exploiting all the new capabilities, using DevOps to make sure you have confidence in what you're building, but change intelligence meaning that we're building the right thing. I think the two things together are completely complimentary, and it's why I'm delighted to be to be part of this, DevOps Summit.

If you wanted more information, then please contact me. There's my email address or contact me on LinkedIn, And, enjoy the rest of the summit. Thank you so much for joining us.