00:00:14

So one of the topics that has come up so many times over the last decade is how do I do DevOps for cots applications, such as SAP or CBLE or Salesforce, Workday, NetSuite, ServiceNow, and so forth. Various people have come up with answers to this question, but they all seemed rather unsatisfactory to me, that is until Andrew Davis, senior director of research and innovation at CAPA gave a talk called DevOps and Salesforce, which makes sense because he's author of book called mastering Salesforce and DevOps, and the insight he gave seemed universal to all of these applications that I had mentioned above. Well, uh, not really. He had to explain it to me a couple times before I finally got it. This seems like a problem that almost every large enterprise faces and how you think about these applications will limit the impact you can have for that reason. I am so delighted that Andrew will teach us about DevOps for low code platforms, why this is important and why it's on the rise and what makes those applications uniquely challenging and what we can do about it.

00:01:18

Hello and welcome to DevOps for low code. I'm Andrew Davis, I'm the senior director of research and innovation at Koao also author the book mastering Salesforce step. So, first of all, I wanna establish what is low code again? So low code is application development using visual or declarative techniques instead of code. And just to make sure we're all on the same page about that. First of all, uh, I think we all know what infrastructure is. We all understand what code is so low code are systems that enable you to create a user interface like you see in the upper, right, or create a, a, a flow of logic business process logic like you see in the lower right using visual or declarative elements. Now, when we're talking about DevOps for infrastructure, we're talking about all these cloud platforms, AWS GCP technologies like Kubernetes and so forth.

00:02:08

When we're talking about DevOps for code, we're typically talking about build pipelines and C I C D and build scripts and so forth. What are we talking about when we're talking about DevOps for low code, that's what I'm gonna cover today. So, first of all, we need to understand a little bit more about low code because there's actually low code platforms can come from two very different sources. The first is as a way of simplifying code based systems. And the second is as a way of making commercial apps more flexible, a little bit different, two very different streams. So the first one simplifying code based development, this is equivalent to moving up through these levels of abstraction. They say the whole history of computer science is all about increasing levels of abstraction from machine language to assembly language, to higher level languages, to low code.

00:02:58

And so you have a bunch of low code systems. It's something like 200 different low code systems that are all allowing you, allowing developers to build applications with visual declared elements instead of having to write code. So to speak on the command line, what are the benefits with each level of abstraction? You're moving up, you get greater simplicity, which means that the systems that you're building at each of these higher levels of abstraction, they're easier to maintain, but they also have Courser granularity. You're dealing with bigger chunks of things, bigger components. And there's a couple of downsides means you get less flexibility as you move up through the stack and potentially less speed as well. Now, the other very different approach, different direction in which low code arises is in the direction of making commercial applications more flexible. So, um, the first thing you can do to take a commercial application and make it your own it's to put your own data in there.

00:03:56

And then all of a sudden it's yours. You've, you've personalized it. The second thing you can do is change configuration, but we know that humans have infinite desires and infinite different interests, and there's no amount of configuration that can address them all. So at some point, these commercial applications need to develop like no code ways of customizing the application. If they want to meet the diverse needs of their customers and potential customers. And at some point they may even need to enable codes to be written on their platform. So if we look at some of these big commercial applications like ServiceNow, Workday, Salesforce, SAP, and there's many, many more, um, they've all enabled increasing levels of flexibility and configurability on their platforms, why greater flexibility means that they can meet more needs for more potential customers. And it also enables them to make changes, fine grained controls, and changes to an application rather than expecting all of a company's thousands or tens of thousands of users to change their behavior.

00:05:00

So some of these small tweaks really aid a lot in, uh, the adoption for the applications, with anything there's trade offs. Now, when you move from a pre-built prepackaged application to something that's heavily customized, there is more work required to set it up and get it running. And it's more complicated, but one way or another, these two trends have converged this trend of simplifying code based systems, which may be something you run on premise or in a cloud agnostic way. And this idea of making commercial apps more flexible. They both converge in this idea of low code systems. So just to clarify up front now, low code systems are very much on the rise to the extent that Gartner is predicting that by 2025, the majority about 70% of new applications developed in enterprises will be based on these low code or no code platforms.

00:05:54

And that at least half of them are going to be from outside of traditional it organizations they'll be coming from marketing departments, finance departments, customer support departments, and so forth. So Gartner and Forer for many years, they've been studying these low code platforms, ranking them, rating them, uh, very fast evolving space. Now Salesforce is sometimes called the OG of the low code world. It's, uh, origins, uh, started enabling code in the platform in 2008. And so, um, if you really wanna understand Salesforce though, it, you really need to transport yourself into their world because Salesforce has a very different world and very different culture. Not only do they host some of the world's biggest technology conferences, they have some of the world's densest population of stuffed furry characters at these tech conferences. You won't find stuffed furry characters like this at the DevOps enterprise summit, or most other tech conferences, because Salesforce is really trying to connect with a very different audience.

00:06:53

The talent pool in Salesforce looks very different from the talent pool of traditional application development. So I wanna explain that a little bit more. So let's look first at traditional application development, you wanna build an awesome app. How do you do it first? You need to build custom code and infrastructure, and that's gonna cost you some money, of course, but you need a software developer to do it, and they're gonna cost a fair amount of money. They're hard to find hardly expensive to pay and hard to retain 13% year over year attrition in the tech industry. They in turn need to get their education from a, a computer science degree, typically from a reputable university. And that in turn requires a lot of money. So some of these things act as limiters on the talent pool. And so what Salesforce has done is they've really emphasized a different way of building applications using declarative development clicks, maybe a little bit of code, um, and to do this, you can use Salesforce admin.

00:07:52

Now you still have to pay them, but perhaps not as much as you are traditionally trained software developer, because they've come from nontraditional backgrounds, they have migrated into the tech world, uh, later in life potentially, or without necessarily the benefit of a traditional university education. They're likely to have gotten at least part of their education on Trailhead. And one of the biggest, most impactful things Salesforce did is they launched this free gamified learning platform. Trailhead did I mention it was free and made it as fun and engaging and open and inclusive as they possibly could to bring in a very different and much bigger talent pool. There are currently millions of people who trained in Salesforce development. Now, if you're wondering what to do with that extra cash, you'll need to send some of it over to Salesforce. Um, now what is different about DevOps for low code systems?

00:08:48

Now, disclaimer, my background is mostly in Salesforce. Uh, this is gonna vary a lot depending on what platform you're looking at, but, uh, hopefully some of it'll be, uh, relevant to all these different platforms, Salesforce. And in fact, all of these low-code systems make it easy to build now easy is great, right? But there are some limiting limitations to easy. The trouble with easy is that easy means fast. You can get a lot done in a short period of time, which means you build more. And when you build more things become complex pretty quickly. If you get enough moving parts in any system, things tip into complexity pretty quickly. Now the vision in the Salesforce platform is that it's like, we're building with Legos. You can take these small components, you can assemble them. You can build this magnificent structure. Uh, your Salesforce org or environment looks like this.

00:09:40

Salesforce tower made out of Legos, but the reality is bit more like, uh, building a Jenga tower, trying to deal with the Jenga tower. In many cases, uh, teams, as they get bigger, as the org scale becomes increasingly risky to make changes. So I wanna step you through, this is, uh, kind of a summary of the evolution of Salesforce. It's a summary of the evolution of all of these low code systems. Uh, and it's often, uh, recapitulated in the experience of individual development teams. You start with just having one production org, your, your SaaS application life is simple and you spend your days like this. No problem just relaxing. Everything is great because other people are taking care of infrastructure and so forth. Now, gradually you begin to pay the price of success. Now the price of success is that over time you get more and more users using the application that you've built.

00:10:37

Now, this has two consequences. First of all, is that your applications become more and more business critical because more and more people are using them and needing them for their daily work. Now, the second is that all of these users create a massive demand for changes. They all want something different or customized for their needs. Um, now if you take these two together business critical, but high demand for changes, what that means is you're facing a very high risk of changes and your life begins to look more like this. So there is an enormous amount of stress and pressure. Every time you want to try to change this organ org, once you've, if you're doing everything just in the production environment. And so you embark in this amazing adventure called this software development life cycle. Now that may not be new to you, but for a lot of the people who are building the Salesforce platform, that's the first time they've ever done anything like that, it's it.

00:11:36

I can't overstate. Um, how different that development community, the Salesforce development community is from traditional software development. So you embark in this journey, you've got dev test and production environments. How hard could it be as a big adventure lying away? So this is where things start to get complicated in a different way. So you have these new developers who are often relatively early in their skill development. They've learned on Trailhead. It's kinda like somebody who's learning to drive, but you get these large complicated Salesforce environments. And what you need is more akin to traffic engineering. You need the ability to orchestrate and conduct changes at high scale and high speed. The challenges that begin to emerge when you have multiple environments is you have trouble keeping those environments in sync with each other. You have trouble tracking changes. You have trouble propagating. Those changes systematically.

00:12:32

There is a risk of interactions and side effects, and you get this accumulation of technical debt. The net effect is that it many times your org or your environment becomes more like this tangled, convoluted, uh, mess that is very risky to change. So when I'm talking about orgs or environments, you need to understand that Salesforce controls the underlying environments, whether that's a production environment, because this is a SAS system, it's wonderful. They're managing the infrastructure for you. That's a huge category of headaches off your plate, but it does make things a little bit different. The sandboxes you're developing in, they are also hosted by Salesforce and there's a new kind of org. Short-lived scratch orgs, but these also are hosted by Salesforce. Now, what is Salesforce? Anyway, basically it is one big monolithic database on which there is this Salesforce platform and Salesforce provides both the platform and the database in the cloud.

00:13:33

They also provide these standard apps that just kind of work out of the box. You can also install these third party apps that greatly expand the range of capabilities with little or no effort on your part. And you can build custom applications that are specific to your organization. And the powerful thing about this is that all of these apps are naturally integrated with each other because they're on the same platform and they share the same database. So that's one of the very compelling things about Salesforce is that everything is in one integrated database. Although, as we know that can bring some other challenges. Now, if you wanna move changes from one environment to another, let's see you've got an identical environment. You wanna move changes. There is one gateway through which you can take changes out and send them in. And that is called the metadata API.

00:14:20

Now you can pull a set of related changes related metadata changes describing the changes you made in the org. And the idea is you just send them over into, through the metadata API in the target org, except you encounter deployment errors because you were facing, uh, you missed dependent field for example, or you were lacking test coverage, or you had malformed XML, or my favorite unknown error. Um, the list goes on and on and on. Now the powerful thing about this is that it does allow you to begin to track these changes in version control. And once you've got things in version control, you can begin this journey of deployment automation, uh, and you can, and, and that's, that's where things really get fun. But, uh, you may be familiar with this periodic table of DevOps elements, thanks to digital AI because Salesforce works in such a different way from traditional infrastructure or code based systems.

00:15:18

The vast majority of these tools do not work on Salesforce. And so in short, your DevOps mind tricks won't work on Salesforce. And so you've gotta have a different approach. One of the reasons it's a bit tricky is Salesforce relies heavily on these huge XML files. Some of these can be a hundred thousand lines or long or longer. Now what happens when you try to merge XML files in GI, you might think XML merge, how hard could it be? The answer is you don't wanna know cuz if you merge these, you get you how you hire don't could want it to be no, which is probably not what you intended. So this is a diag, a picture of an actual get merge, uh, conducted in Salesforce. This is from a project that I was on a couple of years ago, as you can tell, it's kind of tricky.

00:16:06

So the limiting factor on building your own Salesforce DevOps solution is that you need a people who know Salesforce. You also need people who know DevOps and you need people who have time to write scripts. And so it's a little bit of a narrow intersection between those, which is what makes this a little bit of a tricky challenge. So there are two C I C D and testing options for any low code platform. And it's important for you to understand about the, the trade offs between build and buy because you, as a DevOps expert in your organization are probably gonna be the ones that people turn to people are building on these low code platforms are gonna be needing advice, and you're gonna have to understand the trade offs and the pros and cons of different options. So if you choose to build, um, it's good to know, certainly for Salesforce, the dev tools have improved greatly.

00:16:55

And I think all of these platforms are trying to provide more options for developers. You'll need to commit time, uh, ongoing time to building out the script, uh, building those capabilities that your teams need. Now, what this means is that some of the costs when you build your own are, are hidden. There are two costs. One is the cost in terms of the time that it takes to actually explicitly build the tooling. But the second is if you've not built the most effective tooling, there's a hidden performance cost that the organization will face. So if you're gonna build your own, this is easier with teams that have a predominance of coders, people who do come from more traditional software development background, um, certainly in Salesforce, you're gonna need to brace yourself for merge conflicts and some of these other strange, uh, idiosyncrasies of the platform.

00:17:43

Uh, and you'll probably need to train these non coders in how to use GI. Now, if you opt for the buy scenario, um, there's a growing number of commercial options. So, uh, I work for CODOs one of the leading, uh, commercial option for Salesforce, DevOps, and testing. Um, but it still requires training in, uh, time spent to train people in process. So remember in many cases, these are people not from a traditional software development background. They're gonna have to be guided through the process of why you do certain checks at certain points, why you need to track everything in version control, why you can't access production directly and so forth. But the costs, when you buy a tool are a bit more explicit. You pay the licensing fees and you can get all the support and so forth that you need. Um, this tends to work better for teams that have fewer professional coders, more click based, uh, developers.

00:18:38

So as an example, this is, uh, screenshot from Kopa. Um, Kopa allows you to see all of the different environments that are involved in the Salesforce development life cycle or whatever platform you're working on allows you to view the history of the deployments and the allows you to actually take action and move changes between one environment to another. So, as you can see, it's a low code screen that fits the expectations of these low code developers building on it. And this is a, a testing tool called Copa robotic testing on the right. There's a, a screen where people can actually click through and record their actions. Uh, any user of these systems can record their actions and the recorded on, on the left, in fairly human readable text. So we have to always with any systems we're building or supporting, think about the usability aspect based on the skill sets of the people who are building it.

00:19:29

So, uh, delighted to have a chance to share this with you. Uh, let me ask you for the help that I need. I'm very much still getting up to speed on some of these other low code platforms. If you're working on any other systems, ServiceNow, SAP, and so forth, especially if you're facing new challenges. I'd love to know more about what it looks like in, in that world. Um, and if you are struggling with DevOps for Salesforce, please do get in touch, happy to help. Thank you so much grateful to spend this time with you.