Short Byte: Colin Earl - How and why CTOs should engage with no-code tools

All right, I always like to say something wrong at the very start. Safiya has to do at least a little bit of work editing. Okay, Colin good to go. Thank you. I look forward to it. Okay. Hi there. My name is Peter bell. And today I'm speaking with Colin Earle, the CTO of agile, oft calm. Thanks so much for taking the time to talk today. Thank you, Peter. Now, usually, but we're always talking about topics that relate to engineering leaders. And so usually it's about programming or building and managing engineering teams or hiring. But I know that you're passionate about a whole other area, which I think is going to be transformative to engineering leaders of the next decade, which is the area of no code, right? So it's where you kind of have citizen developers writing their own apps within the departments. Firstly, why do you think that's going to be relevant to CTOs at all? Well, it's been a movement, which is gathering pace for the past five to 10 years, and the adoption of no code platforms made a lot of progress in 2020. As companies scrambled to deploy new technologies in reaction to the covid 19 pandemic, with highly configurable automation, no code increases efficiently. But above all, it greatly reduces the time and the risk in deploying digital systems. And this gives organizations a new level of dexterity, that allows them to customize their systems to fit the most complex processes adapt when circumstances change, and automate processes to free up time was better spent from customers or other initiatives. So that makes a lot of sense. If I'm a CTO, and I'm working, perhaps in a larger enterprise, I have departments that are saying, Hey, we want to use web flow, or Babel or one of the, you know, BPA tools. How do I engage with that? Is it a project that my team should be developing? And I hire some kind of semi coders? Or are how do I support? Or should I be supporting the business units in building their own solutions? Well, I think that the engineering leaders need to select Tools that empower the rest of the organization to operate as independently as possible, while maintaining security uptime and seamless upgrades. And these enterprise considerations are really something that the engineering leaders, CTOs VPS, see, CIOs need to address and make sure are fully supported in the options that they give two to the business users and to the other IP phone. So engineering leaders need to manage the discussion. But of course, make final recommendations based upon the input of both business leaders and IT. Now given that, Does that suggest would you primarily choose a tool This is our business protect process automation tool, or provide a menu for different departments to choose from, depending upon their use cases? You would typically look look to find the tool that can address the needs of as many departments as possible. Yeah, subject, of course, to the proviso that you shouldn't be jamming a square peg into a round hole, it has to be a natural fit. But given that there are tremendous economies of scale, simplicity, and above all the seamless flow of data between departments if everybody is running on the same tool. Now, when you're running on these tools, do you still find that there is a role for the engineering org in a support role in terms of providing API's around databases, or how what parts what subset of these systems should still be built by an experienced engineering team? The the engineering team typically has expertise in data mapping basic configuration, which the business users don't have, and they will frequently be involved in designing architecting these systems. There's this there's two truths here. The core truth is that providing a no code system to a developer to an IT person as much as to a business user increases, efficiency increases the speed with which they can build a production quality solution from that by an order of magnitude or more. It's like giving somebody a chainsaw to work with if they're carving a statue rather than the hammer and chisel. However, giving somebody a chainsaw doesn't turn them into Michelangelo. You know, you still, you still need to make a lot of decisions when you're building these systems. And it's typically it people who can make the complex architectural decisions that base the decisions that what data they're going to capture, what are the relationships between that data and the workflow, etc. That said, once that's done, there's a whole ton of work that can can be done by business users with no risks in a matter of minutes, they need to add a new choice field, for example, that shouldn't take it. But you know, it should be a five minute task. trivial. And you shouldn't need to take the system down in order to do it. Absolutely. And I feel like that's a trend even in the software development world is we're looking at how we can reduce downtime and give ourselves more control over the deployment experience. So it's one of the it's always interesting to me for I feel that I usually built a no code solution back in 99. It was million dollar websites for 1000 bucks a month. And we had this incredibly rich kind of XML language for describing user interfaces and functionality and workflows. And MDM we didn't we were a little early for our time and unable to scale, but it's a domain I've been fascinated about for years. Typically, the challenges and the push backs I see from engineering orgs are the things we've learned the hard way about writing custom software. So maybe to go through some of those. So for example, how do you think about data integrity, where you have six departments creating front ends that effectively engage with the same persistence layer? How do you ensure that the business rules are wrapped around that persistence layer in a way that you don't get invalid data from department number three, the person or the persistence by the GUI with which they enter interface with the system is tied directly to the backend database structures. So even if you have to have six different gooeys, they're all interacting directly with the database. And database locking prevents them prevents two people from accessing or updating the same system at the same time. The very worst that you can encounter in such a system is that it may be that one GUI, for example, requires that user a user enters particular data, the other GUI doesn't require that they enter that provide a value for that field. And, and that's really where I've seen this happen. So I mean, obviously, you can create database constraints, you can't put a string, you can't put a series of alphanumeric characters into a numeric field, you can't put a string into a Boolean. So there are base level database constraints you get for free from most relational database systems, the challenge becomes when you says, This must be a US phone number. So it must be this number of digits, it must, and if one of the gooeys requires it to be a US phone number, but the other just requires it to be a phone number, you get, you know, plus for for for a call to the United Kingdom, one of the one of the systems might get a little unhappy, have any of the vendors starting to think about and solve that class of providing a richer set of constraints around the persistence mechanism? Well, speaking, just fragile if we implement the constraints that you describe at the server level, not at the GUI level. And of course, that in those constraints implemented instantly, not at the database layer, but a layer above the database, so that we can have a rich that so constraints that databases don't typically support. To take an example, we might specify that when somebody is entering their age, it should be somewhere between zero and 125. Data databases don't have such constraints, but it's a reasonable constraint to ensure the age is valid. That That makes a lot of sense. So you do have that level. Because it's something like with custom software development, what you often do is wrap an API around the database. So you don't just have three Rails apps speaking to the same database, and one of them messing up the the underlying data. So so that makes perfect sense that you have this this model of a server level where you can effectively enforce those constraints across scurries. Just so nice. So I guess the next question is, I as you see adoption of this, are you primarily seeing this as something that is driven by the CTO and or CIO, who's saying, hey, departments go solve your own problems? Or is it much more kind of a consumer pool thing like it was with BYOD, a few years ago, where people are just rocking up and saying I've built something in a tool, it began as somewhat of a BYOD thing, the business, the business users would find the technology, they'd find the solution, engage with the vendor, and start building applications or have an application built for them on a no code platform, and then take it over to IP and say, This is what we want. Increasingly, though, it's because it's being driven by IP, the IT folks are extremely sharp, and they recognize that this is really a way for getting them out of from under what has been completely unrealistic expectations on the part of their business users. You know, the business users expect turnaround times measured in a few weeks, it has been saying for years, that they're able to roll out a new release of this enterprise system to make substantive updates to it on a nine month schedule. You know, here's the thing, if you're rolling out a new release of SAP, say, every nine months, that's, that's a truly herculean task. I mean, it's extraordinary, you know, monumental effort and dedication and disciplines required to do something like that. But the person is still extremely unhappy. And you know, and rightly so. We had one customer who said, you know, it's always great to go into a meeting and hear people talking about the features and functionalities that they'd like to have, and have that functionality built out hours later. I mean, literally the same day, I turn around, say what, you know, here it is, guys, I've even seen that the like working session meeting experience where any doesn't work for everything, where it's like, Wait a second, what was it You said you wanted that field to be called? And you can actually even engage in real time to get real time feedback on none of that. That's what I said. But now I see it, that's too many fields. Let's just remove some of those. Exactly. We do that from demos the whole time. You know, they'll say, what can you do this? And we'll do it and say, you mean that? It really does, it empowers I think the business stakeholders when they compare with a, let's just call it citizen developer for the lack of a better term. Now, somebody who is capable in a no code platform to actually run those experiments. It brings one question to mind when when I'm take this term citizen developer or whatever, it should be called this person who is capable of configuring a no code system? Is there a compensation impact on this? Are they gonna cost you the same as senior front end react developer in New York City? Or do you do you get some benefit from the fact that their skill set is at least nominally easier to teach other people? You get a tremendous benefit from from that, I mean, you're paying a lot less than you would pay for a developer because there's there's far greater range of people who have the core attributes of intelligence and attention to detail that they need for the job, but haven't gone through five years of programming, development and experience. But I'd say though, that the greater benefit is the level of expertise in their domain that they bring to the task, because they're a citizen developers are not typically people that you've just hired off the street, the parents staff who have a particular expertise in, you know, say the configuration, the building of machine tools, and they bring that knowledge to the automation that they want to implement for the department. Whereas programmers have no such experts have no such domain expertise. And you have this tremendous communication challenge between the SMEs and the developers and invariably communication lapses in so that what the developers finally deliver, isn't close to what the SMEs thought that was specified. That makes perfect sense. I've certainly certainly seen that once or twice. What kind of support Do you need to provide with the citizen developers? I'd say you've got somebody who appears to have good at that, you know, the appropriate attributes in terms of attention to detail intelligence, logical reasoning. How do they go from there? Having the app in terms of training them in a tool, but also do they need? What what what areas might you bring maybe somebody with a more formal engineering background in to support them with here and now? Well, they space, it then essentially need to go through training. You know, they need to go through the two week training course, to come fully up to speed on the platform, the capabilities and get some practice using it. And you know, two weeks may sound like a long time. That's, that's not trivial. But that compares with yours, to become a professional developer. And a tool which has the sophistication to allow you to build a CLM system supports us the Monnet is necessarily a very sophisticated tool, I think, then you need experience, and in the things that so come for some people really naturally and easily, and others just need a lot more work and practice at it. And data modeling, deciding how to manage the data, what fields what, to create an above all, what the relationships are between tables, that's something that you require a bit of experience. And it's an area where it can help all the vendor can help. So either way, you'd have something so really, it's the database modeling and the domain modeling to be thoughtful about the relationships and presumably constraints and things like that. Yeah, you know, at least at least for high end, highly complex applications, you know, if you're just adding a new table to an existing application or some new fields, is very straightforward. That makes sense. So it's interesting, when you talk about this, it makes me think, because obviously, there's the well, should we have our engineering team building? Or should we use a no code platform? Do you feel that no code platforms are going to start to infringe upon Hey, should we use to take an example you know, Salesforce, or my cat or something that is specifically tuned to a domain, but still requires customization within that domain? I are people potentially going to be using no code tools to build out their their marketing hubs and their their email marketing systems? Whatever limits? Oh, absolutely, they are. And in fact, people are now developing no code layers on top of products like Salesforce, to provide exactly this, this kind of flexibility. Now, I have to say that that's an extremely challenging thing to do. And, you know, there's, there's a limit to the extent to which you can lair no code on top of a system that wasn't designed from it from the get go. But it certainly in the fact that they're even trying reflects the level of demand at the market. Is this primarily for solving departmental problems like in marketing, we need this in operations, we need to track our trucks and their locations? Or is it potentially also something that could be used by you know, for your core corporate web applications, especially if you're a real product based company? Oh, it's something which stretches across departments and across the whole enterprise. And, above all, it allows different departments to build modules and functionalities on the same core system. And to build them in such a way that they're integrated by that by design by default, rather than having to be glued together with baling wire and to get bubble gum. Now, usually, when a new technology comes out, or newer, I say new, I mean, no code is 4chan was supposed to be no code, even even business people could write it. Obviously, it's, it's come a little bit since then. But as a, as people start to adopt a new way of solving a problem, it often appears to be the solution to everything. And then over time, it's like, well, there are some sweet spots it should probably start with. So I guess I have two separate questions. And the first is going to be Are there any sweet spots which are particularly well, well aligned with it. And then secondly, Are there areas where you know, you might not want to go here such as, you know, gigabytes of data transfer or or super complex real time systems? It doesn't there are no problems with with no code systems handling gigabytes or in our case, terabytes and potentially petabytes of data. The challenge is more in terms of The flexibility of the GUI, in a no, no code systems tend to have gooeys that lock in that for a given system, the GUI tends to look the same. And this is great for building web applications for building b2b applications, where it's the data, which is core, not the interface. It's not great for building applications such as Photoshop, you could not build Photoshop within the Agile framework. Right. And, you know, in general, I'd say if you're building something with where the the key point, that the kind of primary focus of the application is the sophistication of the GUI, rather than the back end processing that that system provides, then no code is more of a challenge. The other area is, of course, into integration between systems. If you're integrating with some other third party system, you're typically going to use an API to do that. And API's imply coding. Got it. That makes sense? And then Have you noticed particular sweet spots, things? Which commonly people are building? Like what is some of the examples to get somebody's mind going? Contract Lifecycle Management, the creation, the management, the flow of contracts within an organization, support automation, for both traditional support and ITIL, service first level support? A great examples. Yeah, that's great to be applications where data integrity, back end processing with rules, automation, and databases with terabytes of data, great applications for the technology Makes perfect sense. Some of the other things that sometimes come up are around how you think about things like multiple developers, and automated testing. So maybe you didn't one at a time. How does collaboration work? Because obviously, I can a software development world, it's pretty straightforward, you'll typically create a branch off of main, you'll do your work there, you'll create a pull request, and then you'll merge it in once you've got some eyes on it, push it to production, and then maybe behind a feature flag, and then deploy it, which is incredibly difficult, slow, tedious and complex. But it allows larger teams to collaborate on a single app. What does that typically look like in no code platforms? On the no code platform, you may have multiple developers or multi citizen developers, or IT folks logged into the system concurrently. All of them, making changes to the system, adding fields to different tables, changing fields, configurations, etc. and the backend database manages all of this without a problem. The interesting challenge, then is then how do you move and of course, you can then test on that platform, ensure that the new functionality works properly, you then have the challenge of moving those changes from the test system, the dev system, to the production system. And there, we employ a technology called sync, which allows the developers to tag the entities that they want to transfer and say, okay, you know, in this table, all the changes, I'm not going to bother going through each of them, just take all of the changes in this table, and include it in the transfer set. This table over here, only take these three fields, this table, take these workflows. Okay, that's what I'm transferring, now, export it to mouse clicks important on the other system. And those changes are synchronized. Nice. And then you mentioned testing, how do you think about a, again, in a custom software development world? I come from the world of, you know, test driven development, you write unit tests, you have acceptance tests, to make sure that you don't introduce regressions by accident. Do you feel like there is a comparable testing story or simply not a need for comparable testing story? There's certainly a need for it, because you can make if make errors when you're configuring the system. And exactly the same ways you can make errors when you're coding the system. You know, you add if you add a new choice field, you give it the wrong name. Or you should have added two choice fields, but you only added one, those arrows. I mean, they're not programming bugs Exactly. But they have the same net effect. So yes, there's certainly a need for casting them happily. They're automated If you're testing tools now, so that you can, you know, essentially script a set of user actions which occur within the interface. In effect, you're recording the most place that the user is going. And you're recording the response given by the system to those clicks, and you just you ensure that they work after the upgrade just as they work before the upgrade. Got it. So it's not quite a full continuous integration flow yet, but at least you can have the scripted tests running. So you don't have to go go and click through every screen to make sure you didn't just break anything that use the user stable. Well, it's it's, it's as automated as it can be, you know, the, the no code platform guarantees that what you do what you've done, works, that you're not going to get a blue screen of death that you know, the system is going to function. What it can't guarantee is that it works right. What it can't guarantee is that you have made the correct changes. Right And that's what the automated testing can do. Makes perfect sense. And so I guess, bringing it back round as a CTO, how should I think about this? How should I think about? Do I just wait for one of the departments to come to me? Should I like get a couple people to start kicking the tires on different systems? How do I go about formulating a strategy for this? So when I hear from the contract team, that they want to go try to do something themselves? We can give them some good advice? Well, I think I think the key is in the last comment when you hear from the contract team, because the way to go about this isn't to say, Oh, I'm gonna find some cool new technology and then find some way to use it. Rather, it's to look at the problems that your organization is facing, and figure out what technology would be appropriate for that particular challenge. So if the contract team is asking for something, then go out and look and find out what solutions can best meet the meet the needs of the contract team. Then consider Well, what other departments are saying that they need something? Is there a solution which can address multiple needs in my organization? Or is there a solution that can be used to address contracting right now, but then scale and expand seamlessly to address multiple needs after that initial deployments? That's great Colin, well thank you so much for taking the time to chat today. Well, thank you, Peter. It's been an absolute pleasure. And that's awesome to hear. If you want to stop