Supercharging DevOps

Share with

Transcript

Right. So, my name is Ian Gotts. I'm delighted to be joining you to talk about supercharging DevOps.

So let's just share that.

So a little bit about me, three numbers, ten, twenty, thirty. So, ten years as a consultant with Accenture. In fact, it was twelve. Twenty years as a Salesforce customer, and, thirty years involved in systems analysis, building systems. So I'm really coming this from a perspective of how are you gonna make sure you build the right thing.

So that QR code there, if you wanna get hold of the presentation, take a photograph of that QR code, and you can download the, the presentation deck.

So that's a picture of me, racing a hydrofoiling moth. And one of the things we used to say when we were in the competitive racing was the faster we go, the further we go in the wrong direction. And I think that's also true for software development. It doesn't matter whether it was writing COBOL, writing, Java, or now drag and drop.

If we don't build the right things, then the users are unhappy, and often they don't know what they want. I I present this all the time in live audiences. I ask how many people have built things which, nobody wanted, they didn't actually use. Everybody puts their hand up.

So it's not a it's not a Salesforce issue. It's not a a CPQ issue as we've just heard from our speaker. It's actually a a software issue. And if we're not understanding what the users really need, not what they thought they wanted, we spend an enormous amount of time building it only to discover that when we finish building it, they don't use it, and that time is wasted.

So it doesn't matter how fast you build. It doesn't matter how good your DevOps process is. If you're not building the right thing, then you're just getting to the wrong answer more quickly. I I was talking to a customer the other day.

They said, the beauty of Zenite Salesforce, any of these low code fast app building application platforms is I still get bad dreams. I just get to the scary parts faster. And we really need to make sure we don't get to that situation. The last speaker was talking about CPQ and the the complex data models.

Yes. You can build CPQ really quickly, but the question is what should you be configuring? What should you be building? And you need to be able to have a decent conversation with customers, your end users, about and and dig into a level of detail to understand what they really need. And that's what I wanna spend a bit of time talking about.

There's a concept in development called shift left, which is, it's very simple. The earlier you find problems, the cheaper they are to fix.

If if the problem you fix, find is in production, you deployed suddenly, a bunch of flows aren't working properly and it's breaking production. Everyone's running around with their hair on fire trying to fix it. Wouldn't it be nicer to have known that three months earlier, three weeks earlier, three days earlier in the analysis phase where you could have predicted that, yes, that flow also needed three other flows and two x Apex classes to have been changed. Otherwise, it would break. So this is all about early problem detection.

And, again, how do we get that as far left as we possibly can to make sure that, we understand the risk of every change we're making?

So I always like to phrase it in two things. One is, are we building the right thing? That's all about the front end business analysis. And then are we building the thing right? That's all about DevOps, which you've been hearing about over the course of this summit.

And I think what's interesting is how in the Salesforce world, the build the right thing, has become more and more important. We're seeing a business analysis certification that's now available. I think I heard over six thousand people have passed that, which is fantastic.

That doesn't mean that people manage to do the training and then pass it. I think that a number of people out there already have the skills. The certification has simply validated that. If you think about the well architected program that Parker Harris, the cofounder, is, sponsoring and and spearheading.

And in fact, this afternoon, we've got the San Francisco architect user group where Tom Leddy is one of the evangelists is talking about well architected. These are all the things that happened before DevOps. You think about the user design, the big push inside Salesforce for getting decent design. That, again, is ahead of the DevOps. So there's quite a lot of, emphasis now on building the right thing, the things that happen before you start building in DevOps.

So if I think about this little cycle, you may have your own terms for each of these different boxes, but you're actually doing these things. At some point, you are understanding what's in the org, pulling the documentation, making sure you've got a a metadata dictionary with an, an understanding about what's in the org.

You're then capturing and validating business requirements. So you've got to bear in mind business requirements are not what you're gonna go and build. That's what the end users said that they needed and want it. You need to validate that to make sure that, a, they are complete, b, they are valid, c, you have a clear understanding about not just the system changes, but the business changes and the regulatory changes that are associated with those requirements.

That piece of work, mapping processes, understanding the data model, building architecture diagrams, then allows you to define the work items. And that's the critical handover between the the analysis side and the development teams. You may call it a user story, call it work item, different different groups call it different things, but it's actually the piece of work, the technical piece of work that needs to be done and the changes that need to be made to the system.

But before you can send that across, you need to understand the impact of those changes.

And the reason you need to do that is that a work item has a risk associated with it.

You need to make sure that the the most complex and and, risky work items are in one release, and that release goes through the DevOps cycle, which gives it, the the right level of testing, the right level of rigor in terms of development test. It might go through, I know, from a through a sandbox to integration into UAT and then into production.

If you know that a series of work items in a release are very low risk, then that can go through a fast track. You can get those changes into production more quickly.

And only once you've done that, can you then pass it over to the development teams where they can configure and build, they can test and deploy. And that really is where, Gearset excels. That's the point where getting those changes through the production cycle quickly, accurately, is critically important. But it requires that the user stories being passed to the the DevOps team using Gearset are thought through, complete, well understood, and have some assessment of the risk associated with them.

Let me pause and just see if there are any questions.

Nope. So let's keep going.

So let let me show you what this thing looks like in practice. And, again, I'm gonna I'm gonna use elements dot cloud as an example, but, again, it doesn't matter what you're using. What's important is you're actually doing something. You are actually capturing requirements. You are validating them. You are building user stories.

So it might start with, someone leaving some feedback on a page. So with elements, you can, as a we take over the help icon with a little purple icon, and people will then post their feedback there. Now feedback doesn't mean that's a change.

The worst word in the vocabulary is just. Could you just add a pick list? The answer is, well, of course, anybody can add a pick list, but the question is, should we? Actually, a pick list that should be added is a record type with a series of reports associated with it.

There's a lot more to it than just can I add a pick list value? I was talking to a customer the other day. We did a a a an analysis of their org because we pull all the metadata and do an analysis. One of their objects had two hundred and fifty seven record types.

One object.

That object also had a hundred and thirty pick list fields, many of which had hundreds of pick list values. So if you know that you actually need to go and allocate every single pick list value to a record type, there were over five million mappings.

And then we we obviously look at how much data is in each of the fields. Only one record type had been populated. There are two hundred and fifty six record types with no data. Now I wasn't there when it happened.

I had no idea the the backstory for that, whether they built it and then they got rid of a business unit. I have no idea. But we see that this time and time again where we're building up technical debt because we we don't understand what's in the org. We don't understand whether we can make a change to something.

So instead of creating or changing an existing item, we create another a new one because, we don't change the old one, and that technical debt builds and builds.

So just because someone's asked for something doesn't mean they necessarily get it. We need to look at the business process and under and work with the business users and say, okay. Talk to me about how this change in, this new business value, how it will change the business process? What are you trying to achieve?

I think you've often heard the five whys. Like, why are we doing this? So and just drilling in and drilling in. Why why do you actually need this particular, bit of functionality?

You may find it already exists. You go through the process and the person go, oh, actually, it already what you're suggesting already works. Fantastic. I don't need to make a change.

You may may find that, actually, yes, it was a pick list value they needed, or maybe it was something else.

So you need to look at the business process. You need to look at the data model. You need to look at start thinking about the architecture for the implications of those changes.

And then you can build a user story.

That user story here as an SDR, so as I as a, I want to so that I can.

But you can then start to understand which metadata items or it could be as, the last speaker talked about, it could be CPQ items. Which of those need to change to support the business change we're trying to to put in place?

And that user story could well be kept in sync with Jira if Jira is the, the system of record that the development team for, managing all the changes through the system.

But think about this as this is the business analysts trying to give as much information and pass it to the development teams as possible.

So this user story, this right panel would then flow into Jira. It would then sit inside Salesforce. So everyone in the team is working to the same set of information and and really building on all the business analysis, the process maps, the discussions, the the screenshots, the wireframes, the user designs, all of those connected to that user story, that work item. So when it gets passed to development, they're not running off one sentence and trying to guess what it means. This is all about context. This is all about making sure that a handover from the analyst to development is as easy as possible with as much knowledge about the risk of changes.

So let's just think about the risk of changes.

Elements builds a metadata dictionary. It pulls every single metadata item, and it starts to give you an understanding about in this case, this is a commission field. We've said it's high high impact, but we're also telling you where where it's used.

So then as an analyst, you can start to have a a view on, okay, if I make this change, how how how complex is it? How big is it?

Another little, little customer story. They did the analysis work. They probably spent three or four weeks doing the analysis work, realized based on the risk that the number of changes that needed to be made, not just to Salesforce, but to actually third party systems. Yeah. It's Salesforce, but we have to change Slack. There's a MuleSoft integration that's now gonna change something in NetSuite.

It's actually has some of these changes have quite broad, impact.

They did the work. They did all the business analysis work, realized that, the development was gonna probably cost twenty thousand dollars, went back to the business team and said, k. This is gonna cost twenty thousand and gonna take four weeks to build, and the and the business went, no. No.

No. No. There are more important things for us to do than that. Please don't do it.

Now you may think about it and go, well, that's a little wasted effort on analysis.

It wasn't. They actually saved a whole bunch of time in development. It's making sure we're developing the right things that the business need, which will actually drive their business forward. The business can then make a judgment on if that change is gonna take that long, I could get three other changes in which I'd rather have.

You can't do that without decent analysis and a decent understanding about the risk and implications of making changes.

And that's why you need a metadata dictionary.

But also if I go to the next stage, every one of these, every metadata items will show a dependency. So you can see that this field is used in one field, four flows, I don't know, twenty one reports. But then I can open up each one of those items and it just drill into more and more detail. So I get a a better picture about what's happening.

And here on the right hand side, because I'm on any particular item I selected, I can see the documentation.

I could see the user stories. I could see any discussion. So, again, it's getting everybody on the same page to have a discussion about, okay, what do we need? What's it gonna cost? How quickly can we put it through development so we can then optimize our development cycle?

And all of this, information I'm showing gets built overnight. It gets built every single night. So these are the the features that you should be expecting now when you're building systems.

And the the key point about this is that that metadata item is the one that's being touched in gear set, which means that it can leverage the elements content.

And that's why, again, elements and gear set are working together to make sure that, they they walk forward step hand in hand.

You can build development, but you can actually leverage the, the analysis that's already been put into into elements.

So just think about the benefits of this approach.

First of all, greater user adoption. People go, well, hang on. Why why will this make users adopt more? You're building the things that they need and want.

You're doing a lot of the work upfront to make sure what they are really asking for is what they really need. So when it actually gets delivered, they start using it.

If they're not using it, maybe it's the they've they've now had the business moved on and therefore we can course correct, but we're not having organ rejection. Again, another customer story, one of Salesforce's biggest customers, They said their description of the the apps they build are a confetti. That's the collective term, a confetti of applications. They're all beautiful. They're all amazing in their own right, but they actually they all they're not connected.

And then when they fall on the floor, they kill them off because they're not being used and three months later someone comes up with a need again, they build it and it never gets used. So we need to make sure that we're building the things that the users want so we can leverage the power of the Salesforce platform.

The second is reduce rework cost.

People talk about agile. Yeah. Agile. You just build it. If it's not right, we'll build it again, and we'll build it again.

No. No. Agile is about chunking the work into smaller pieces so you can stay more, tightly related to the business as they move forward.

Not the six months waterfall analysis phase, and then we'll spend two years building it, but actually smaller, faster phases. That doesn't mean don't ask what the users want and build them. If it's wrong, have another go at it. Very quickly, you're if you erode the trust of the business if you do that, number one.

Number two, you can't do that to strategic applications which Salesforce is now. You can't be going, oh, sorry. That didn't work. Let's have another go at it.

When, we're talking to customers with ten, twenty thousand, end users who you make a change and it breaks something for them, it has a significant cost.

So if we're delivering things more quickly because we can fast track those with low risk and we we take the right amount of time with those with high risk and we don't break things, we're actually increasing business agility. We're giving the business users what they need, the tools they need to be able to go and, you know, do what they do well, which is, I drive sales, drive customer success, improve service quality. Whatever it is the business needs, we can actually deliver Salesforce more quickly and give, basically, the business back the agility that Salesforce has always had, but the technical debt has killed, that a lack of, good analysis has killed.

And the last thing, which I think is relates back to DevOps, which is fewer rollbacks and the related downtime.

There are four metrics that people talk about, when we're talking about, DevOps. Number one is how quickly do we release?

The second one is how often do we release?

The third one is how often do we roll back? And the fourth one is how quickly can we get back to the the previous situation we had to have a rollback?

So I understand the first two. That's about increased business agility, getting changes through faster. But the the second two are strange. That's like having a Tinder profile that says, I've been divorced four times, but I get over it really quickly.

We shouldn't be having those situations.

We should be doing sufficient analysis so that the rollback number is actually a rounding error. It's so small we're not even worrying about it, and we're not worrying about how quickly we can roll back.

We should be getting to a point where we have more confidence in building things because we're actually drawing on better and better analysis.

But that's also incumbent on the development team to when they're making changes to actually document them because we're then building that institutional knowledge of how the system's being built back in that metadata dictionary, which means the analysis can then pick up the, the pick up those changes, and, better analysis.

So I wanted to get us back on track. I know we had some technical problems at the beginning of the day, so I thought I've been been through this relatively quickly. If you wanna know more about how you would do that front end business analysis, then there's a a change intelligence report which was written by advisory, an independent analyst firm, who's looked at all the products in the space, ourselves included. I'd encourage you to go and look at that, but also reach back out to me in terms of but if you wanna talk to me about, business analysis or or or can reach back out to the, any of the people in the gear set team who, are well versed in what we've been talking about in terms of shift left earlier business analysis.

So thank you so much for inviting me. Delighted to have a few minutes just to talk about business analysis. I'll hand it back to Marco.

Hey, Ian. Can you actually stay on for, just a few minutes here? We have a question for you. Yeah. Of course.

Of course.

So how so how much of the, how so how much of the difficult with deployment comes down to a necessary complex business process and murky data?

So, I mean, the complexity of the changes you're gonna make will will vary, obviously, based on, how complex the the org is. You've got I mean, if you're implementing CPQ as the last speaker talked about, it's a complex beast. It it's difficult to do, and therefore, you need to take more time and analysis. You need you need to rely on better an or analysis of the org.

However, we should all be striving to simplify processes.

So the other the other benefit of this of the the upfront analysis is is actually dealing with the business users where you start actually simplifying some of the way the business works, which will make it easier to build systems.

And we're seeing typically twenty five percent reduction in in the overall cost of, of, that that process by driving out waste. So you get a twenty five percent hit just in terms of under getting the business users to go, oh, is that how I meant to work? Oh, no. We don't need to do that.

We can simplify it. So there's that. And then at eighty percent reduction in rework because you're actually building the right things. So there are I know it's hard when the the users are going, just build it.

How hard I've I've watched the videos, Salesforce videos. Just build it. It can't be that hard.

You've got to resist that and go, trust me. If we spend more time just understanding what you really need, we will build exactly what you want really quickly, and and you won't have to come back and ask for it again. So I think there's a there's there'll be a little bit of tension to start with. Certainly, the first time until the the end users have actually been through this and then gone, actually, it works.

So there's a question from, about architects.

And this is I mean, everything about business analysis, the the key groups there are the business analysts, the architects, the designers. Absolutely. This is everything we're doing here is about making sure we've architected the right thing. You can't build an architecture unless you understand the real requirements.

You can't build the right thing unless you understand you've got unless you've architected it correct. So this all goes hand in hand. And I'm delighted that the architect practice inside Salesforce is gathering so much momentum because it's it's reinforcing the importance of this.

Perfect. Thank you so much, Ian.

My pleasure. I'll let you, take over. Bye again.