#22 Low-Code with Mike Fitzmaurice

In this episode, we have a discussion with Mike Fitzmaurice, Low-code evangelist, and our CEO, Tiago Neves  about the interesting world of Low-Code.  Have a listen as they debate the importance this trend and how  it  impacts the industry! 

Transcript

Mario Cunha: 0:22

Hello, and welcome to a new interview of the high tech low code podcast. This episode, we'll be discussing low code with Mike Fitzmorris. And Kevin Nash. Mike is a local evangelist, and He's the VP of North America. Welcome. Mike, thank you very much for joining us on the podcast. How are you doing?

Mike Fitzmaurice: 0:39

Great. Thank you for having me. This is going to be fun, I

Mario Cunha: 0:42

think. Hope so hope so. Could you give us a bit of an introduction so that the audience could get to know you a little bit better?

Mike Fitzmaurice: 0:50

I've been involved in low code development, declarative development, rapid application of it, call it what you will, for close to 30 years, both by professionals and by citizen developers. I've done it as a consultant, I've done it as an IT director. I've also done it while working for multiple companies involved in low code, including Microsoft. I was part of a team that created SharePoint and brought it to the market and I was responsible for developer relations for about the first 10 years of its life. Since then, I've worked for a couple of different workflow centric business process centric local companies. For the last three years, that's been an outfit called webcon. They're really good, clever people based out of Europe. And I spend a whole lot of time not so much selling product, but absolutely selling ideas. And letting people make their own decisions. DSI seller about low code and how to do it. Well.

Mario Cunha: 2:04

All right, that sounds interesting. I think we're gonna have a really good conversation today. Then Jericho, also welcome back. How are you doing? I'd have you been up to.

Tiago Neves: 2:17

Hey, nice to be here again. And looking forward also for for this one, I shared the same opinion as us. So looking, very interested to hear from from Mike and his background, which I think will be amazing for for all of us hearing. So looking forward for for this one. And I'll just let you drive Mario, but I'll certainly probably have a question or two, as I'm certainly passionate about this topic as

Mario Cunha: 2:46

well. All right, please do do quick, ask away. Before anything, I would really like to say thank you to both of you for joining us. Now I know we have spoken about local in the past. But they we do have the privilege of having the opportunity to desert the topic with a spokesperson slash evangelist. So not wanting to waste this chance. I would like to kick off our conversation with the following question. Who do you think benefits the most from low code? citizen developers? Professionals? Oh, gosh,

Mike Fitzmaurice: 3:17

that that's a harder question to answer than you might think. Because it depends on what you mean by Benefit. Alright, so I could see. Like, I probably need to preface this by saying low code and citizen developer, or citizen development are not the same thing. Most citizen development efforts I've seen involve low code, with some exceptions, scripting tools. I've seen a lot of people do PowerShell work, for example, in the world of Microsoft, as an example. But they would call it scripting. In fact, they would go out of their way to avoid calling it code. I wouldn't. It's code if you in fact, if you can make a spelling error and it breaks, then that's code. But it's just a question of how much is involved. But yeah, generally speaking, citizen developers live for low code. Now, it depends on who benefits if you're talking, given the professionals have the option to code, you could argue that citizen developers wouldn't exist or would barely exist. Without low code, that's probably fine. But I care a whole lot more about outcomes than I do about supply side issues. And when it comes to who reaps business benefit, or who reaps the best results from low code, that's professionals.

Mario Cunha: 4:50

I see. Okay.

Mike Fitzmaurice: 4:51

There's a lot more activity in low code on the part of citizen developers but a lot of it breaks a lot of it's fragile. A lot of it requires for professionals to evolve it. Sometimes he'll it's but I don't want to be mean or pejorative because a lot of citizen development work is actually pretty good and pretty interesting. But a lot of it tends to focus on what you know, I hate business buzzwords, but the long tail is not a horrible one in this case. In other words, we've got on one end of the spectrum, very high impact, very high budget high time consuming development efforts for creating big mission critical projects. On the other end, you've got an ever shrinking tail of small applications that affect just a few people at a time. And if you add up all of the productivity to be gained from implementing all of those little applications, it does add up to quite a bit of value, or at least it has the potential to, and a lot of citizen development efforts have lived in that area. And if what was built worked, would work rather nicely. Sometimes it does, sometimes it doesn't. So when you're looking at biggest benefit to the organisation, this is counterintuitive, and probably not not going against the grain for compared to what a lot of thought leaders would like to say on this. But know a lot of the time that people are best able to deal with low code development, our developers, because it's still development. And even if you don't have to code like a developer, you've got to think like one. And if you don't think like a developer, you will create things that are not that are going to leave out assumptions. Or they're going to leave out exceptions, they're going to make assumptions that don't always hold true. Have you ever implemented, say, a simple automation or workflow scenario? For example, I don't care if it involves code or low code, and the client, the customer, the business stakeholder, whatever, the person who's not going to do the work for the person that wants you to do it tells you what's supposed to happen. And what they told you was only the best case scenario, the so called happy path. Yes, exactly. the happy path, they give you the happy path, they don't think about well, what if this happens? Or what if that happens? Or what if the other thing happens? should I handle it this way or that way? In other words, your natural reaction, I'm willing to bet is to come back at them with a whole bunch of questions. That if they aren't answered, we'll create a horrible application. And asking them these questions, results in them being annoyed, maybe dependence, some, some will actually thank you for having thought this through. And they might even say, Oh, you actually get it? Well, what you really get is logic, not necessarily the process they have in mind. But that happens all the time. citizen developers don't necessarily ask themselves these questions, unless they really are developers at heart. The thing I will say about that is if you really are a developer at heart, and you just never did it professionally, and you start doing this, the odds are really good that within a year or two, you're going to change jobs and become a developer instead of somebody that does it on the side. And thanks, come on, join us we have cake. It'll be fun. But um, yeah, look, development is still development. And look, you and I could both grab a hunk of clay. But if you've got artistic talent, and I don't, my sculpture is not going to be as good as yours. And yours will be the only one that that is exhibited in a gallery. So even if there are 50 of me and one of you, you're the one that creates the most benefit to the world of

Mario Cunha: 9:27

art. Goodwin, I like the comparison. Yeah, an

Mike Fitzmaurice: 9:31

end of rant, or at

Mario Cunha: 9:32

least No, no rant. Jaggu anything you would like to have.

Tiago Neves: 9:40

So I'm someone that does certainly see what Mike is picturing for us. But because I'm somewhere in between. I I come from a business background, but I I've been in IoT projects ever since I started my professional life. And, and so that was 20 years ago and ever made that transition really. So I've been a developer myself, and certainly see how I believe I I fit into that citizen developer that actually has a developer minds. And I think I did that transition somewhere. I don't know when it through my career. And I think certainly, this is what I would see myself doing what you mentioned, Mike, which is how would come up with all these questions, I won't be happy with what is just a use case. And all different questions will come up. And and I would wonder, but what happens if so the user just inserts the wrong type of data here? So what's the next question? And what happens then and this and that. And so that was always my my way of looking at this. And I think certainly, this is something that if you don't have that developer mindset of so questioning all these different paths, that that can happen, and you have low code is certainly going to help you put the business logic in there. But if you don't have that developer, mindset, you will certainly be facing with issues of bugs, use cases that you haven't thought about. And so all of that, that we know, happens, and that's why we have requirements, we have testing and and so it's development that goes a long way. And it's not just a question of having a form that that works with one particular case.

Mike Fitzmaurice: 11:59

Yeah, I found? Well, yeah, there are a couple more things we could do along the slide. I don't really want to spend too much time talking about things that citizen developers who don't have a developer mindset failed to do. Topics been done the deaf, and I don't think we've, I don't think we're gonna argue with each other very much about that. But, you know, it's things like security, like, do you? How do you handle accessing data so that SQL injection errors or attacks don't take place? Or, you know, any of a number of things that are security related, there's still hope there aren't so many holes in Word macros and Excel macros and so on that there used to be, but there are still options or things to fail to think about, even if How about this, a lot of projects with a lot of Loko tools, assume by default that you're developing in production, and that everybody has permissions to do everything. And it's the job of the citizen developer to think through or the local developer, I should say, to think through how to take away privileges people shouldn't have. But it's a subtractive approach, as opposed to an additive one, which means if you do nothing, anyone can do anything. That thinking through security carefully, not matters. And that actually has nothing to do with code. That's we come back to the developer mindset for that, in fact, one of our clients last year, what did he say about this? Oh, development is only 10% of delivery. That other 90% involves change management, deployment, user education, it education, for maintenance purposes, security, auditing, to prove things happen. Metrics and monitoring, not the same thing, because that's like application health system health, performance against metrics, and so on and so forth. It's not it's not auditing. It's something different, but it's related and involves keeping track of what took place and presenting it the right way. There's a long list of things that have to be done. And again, somebody with either a developer mindset and a lot and some experience they gained along the way or someone who's been professionally trained, knows these things. A casual dabbler does not. So I circled back to the original question. The world is benefited more, more from low code when it's been used by people who know what they're doing As opposed to people that are experiment every once in a while those experiments however produce really interesting results. I don't want to devalue that. And by the way, if you write an insecure you know barely audited, happy path only automation scenario but scratches a very necessary itch only you and maybe your immediate colleagues feel fine who am I to tell you you shouldn't do that. But the moment you start sharing that with other people, wackiness ensues,

Mario Cunha: 15:38

nice.

Mike Fitzmaurice: 15:39

Scope it right. minimise the risk and can all have a good time.

Mario Cunha: 15:47

Okay, changing gears now. Is locode entirely completely on its online? Or can it learn things from the world of traditional coding high code? And if so, what can they learn?

Mike Fitzmaurice: 16:01

Okay, has to learn things from the world pi code? If it doesn't, it's not going to be very effective. So we come back to two things here, something I said which was low code development is still development. And the second thing would be that developments only 10% of delivery. Things like agile, not agile, like the religion some people make it out to be, but agile, like the principle of team of people contributing specific strengths to an efforts, very short release cycles, constant iteration, continuous improvement, that that kind of concept. That can and probably should be applied to locode. Mike, you know, webcon is devoted to that that concept. We're not the only one. But but I'd like to think we're pretty good about it. But, again, it's the idea that matters here. If you're going to release something, just because it's low code doesn't mean that it's a one and done. In fact, I know of a low code company that has in the past, they've since been acquired, but they used to do a brisk business, but they actually had a marketing campaign devoted around disposable applications, disposable applications, disposable applications. Yeah. And I would argue that if an application is disposable, that means barely usable. If any application that's worth something is probably going to have an extended life of some sort.

Mario Cunha: 17:45

Oh, yeah. I mean, just the time you spend developing it.

Mike Fitzmaurice: 17:50

Yeah. And part of that mindset was okay, well, we realise the application no longer does what we need, because our our requirements have changed, the world has moved on our business conditions are the same, we'll just replace it with a whole new application. That seems incredibly wasteful, and possibly something that would result in a loss of historical excuse me historical data. I don't want to see that. So yeah, there are all kinds of things going on in the world of professional development that Loko development really, really needs to keep track of change management matters to stage deployment from a development environment to a test environment to a production environment. These are things developers take for granted, it's second nature, you're you're not in the club, if you don't follow these things, because they're not even controversial anymore. It is scary. The degree to which I would I would argue that the majority of citizen development efforts never consider those kinds of things, they kind of think of one and done and they think of developing and deploying directly into production. And again, if this is like you and me working together in a in a small team, and we're building a happy path thing, you know, and it's just for us, fine. We start sharing it with someone else. Not so fine.

Mario Cunha: 19:25

Problems are sure to appear,

Mike Fitzmaurice: 19:27

and patterns, like thinking through, you know, try to explain a loop or a state machine or certain just parallel processing and making sure things think sync up so that you know when it's safe to move forward from all the parallel paths, some kind of signalling going on. These are ideas, they're not code. But if you don't do this, it really really limits what someone's allowed to do to basically a simple set of linear sequence events, maybe passing data from step to step. And again, it's it limits what's possible, maybe not in a bad way. But for the love of God, we can't bet the business on one of those things.

Mario Cunha: 20:16

That's actually a good point. And what about you? What do you think?

Tiago Neves: 20:22

I was just thinking about how I see, maybe it's next next question, but how local vendors and so that the low code concept in itself, so comes from that application development beginning, but at the same time, so I think what we see nowadays is exactly what Mike is, is referring to, which is the concept of low code is moving away from just being then the development, and is now being taken to other parts of in this case, the delivery, as well as even other technologies. But the question is still there that we are just abstracting complexity, and that yet at still, at this stage, I don't see how someone just without that developer mindset, or at least some basic technical background, is capable to still deliver a robust, so scalable application. And so all of those concepts that we know are behind a corporate delivery of either then something that can be small, like you're saying, if it's just to be shared between family and friends, it's not going to be anything critical for any business, probably, it's fine. But when we're talking about then critical business applications, it's all of these needs, certainly to be taken care of. And, and I think that's where local with citizen citizen developers can go only thus far. And, and so you cannot have a complete delivery, just with citizen developers. And I think there was a bit of more hype around citizen developers two, three years ago, or so. I think that there's been at least some realisation that it's good, I think that we have low code being a facilitator of the collaboration between business and IT. But that doesn't mean so just business can take over and, and do their own delivery. So take over it at that. I don't see that happening anytime soon, at least.

Mike Fitzmaurice: 22:48

Yeah, in fact, you know, I, let's be very clear here. I'm not anti citizen development, I'm pro citizen development with a fence around it. And what I am anti is people thinking low code equals citizen development. Low code is bigger than that. I love low code. In fact, I want professionals to use low code as much as possible, as long as they choose their low code tools carefully, because low code cannot be a wash, down, or a watered down version of real development. My whole goal in life, my company's sole goal in life, is for load code to be real, professional development, that just takes less time and produces more reliable, predictable results and gets more done in less time with better results. That's the goal of of professional, low code, low code for adults, if you would. I think that matters a lot. And so, you know, if you've got a low code system that only focuses on the development part building thing, you're probably looking at something that is watered down. If you're if you've got low code that only thinks in terms of data, in other words, its development model is based around Oh, I'm going to I have a canvas that will manifest as a webpage or a mobile app. I'm going to draw some controls, drop it onto the form. I'm going to bind that to some data. And then I'll add some reactive logic when somebody you know clicks on something that's a very limiting or limited application pattern, if it's appropriate some of the time but usually if you're editing data, you're doing it for a reason. So I really want to see the business process show up in the application model somehow. Not just reactive activity. But, you know, there are plenty of low code platforms out there that think beyond, you know, building something. And the thing that you're building in the first place is nothing more than a table editor. So yeah, depends on the tools. But you know, actually, that's true of even high code or classic code environments, there are some IDs that are great, and some that are terrible. So yeah, choose your tools carefully. And low code is 100%. Professional. And again, you won't have all the freedom of full code. But you'll have a lot more productivity, meaning, more output faster output for the same amount of work or same output with a whole lot less work. If you turned low code, and include that, as part of professional development shops repertoire,

Mario Cunha: 26:02

we kind of touched on the next question. So I'm going to jump over to the next one. Oh, okay. Because you just answered it. And I was like, Okay, this is perfect. And so pick it up as a segue to the next one. And are the local platforms, the silver bullet for many of the IT problems, or is just generating more entropy?

Mike Fitzmaurice: 26:29

Oh, yeah, it depends a lot on the tool. But it has the potential to solve some many IT problems now. Never all of them come out. Let's let's not kid ourselves. But there are there are really what's citizen development is a useful reference right here, because two of the reasons why we tend to find citizen development attractive, by the way, both and both of them are completely legitimate, they really need to be a time to do Reason number one is the application back blog, the talent gap, the fact that there are, you know, on my side of the Atlantic and yours, you're in Europe, right? Yes, yes. I Portugal, right.

Mario Cunha: 27:21

No, and it's always in the UK. I'm in Berlin.

Mike Fitzmaurice: 27:25

Oh, okay. Great. Sorry, my mistake. I saw Tiago and immediately thought, Portuguese name, but

Tiago Neves: 27:34

we name yes. Absolutely. Yeah.

Mike Fitzmaurice: 27:38

Okay. I mean, added up. So basically, we're covering a lot of places. And in on both sides of the Atlantic, there's a gap of about 600,000 IT jobs, they're not going to get filled their people to fill them. We have a talent gap, we have a supply gap, therefore we have an application gap. And because of this, we need to find a way to get more stuff built with the resources we have. One option was citizen development. In other words, increase the number of people that can build applications by asking less of those applications possibly, or using magic tools. That meant that you didn't need as much skill in order to create those things. Now, that was that was sort of a desperate hope. That pays off from time to time, but as much more modest results, but it's not without help. But I want to focus on the reason here, we need to get more done. We need to get more stuff built locode can absolutely in the hands of professionals can absolutely help with that. Almost everybody's lead code platform in the hands of a professional can help them get more done in less time than if they were coding unless what they've been asked to code is really, really weird, and hopefully weird and wonderful. But usually low code tools, take away some freedom and give you back productivity in exchange for it. And if it's not, they didn't take away too much and you still get to produce the kind of results you need to very happy trade off. It's the second reason for citizen development that's much much harder. I not it's rare, but low code can help with this but not non existent. And that problem is the fact that mine melts only exist in Star Trek. There's no mind reading going on. That's just in the movies and sci fi shows and books and so on. It's very hard for those of us that are trained to be technical software to Developers low code or high code or what have you, to be able to read the mind of a business person that has a problem that needs to be solved. It's also very, very hard for that person to describe what they need, or what they want, or even the problem they have, in a way that you and I can act on to help them. Which means when we get involved in a project, it's not an explanation. It's a negotiation. And if all parties have a lot of goodwill, it doesn't get nasty, but sometimes it turns into an argument. And that's just crazy. But that the appeal of citizen development is if I'm a business person, and I can build something for myself, I don't need to explain what I'm doing to anyone. That's a very attractive idea. Of course, the issue is in explaining it to someone, even another business person, we might realise things we hadn't thought of until we set it out loud, or until a fresh pair of ears, you know, thought about it and asked a couple of questions that help to refine things nicely. It's good to have people communicate a little bit, you've produced better results in some cases. So I think that logo can even help with that. But the low code has to focus on more than just construction. If it's again, I'd say 80 to 90% of low code platforms out there are focused solely on construction 10 to 20% of them think beyond that. Those are the ones you want to take a look at, because they might even help you communicate with users and business stakeholders and come up with a common set of design specifications, common set of plans, even a common review process where people get together, look at what's being built, figure out how to improve it for the next iteration and so on. There's a communication issue, low code can help with that low CO construction tools won't help with that. But low code platforms might. We're certainly trying to do that. Other people are trying to do that, too. It's that will solve the other problem, it has to stick at least in terms of building things. I mean, will it help with solving their integration issues? Probably not integration is as much about politics as it is about protocols, and priorities, and so on. So it is going to have plenty of problems to deal with. But we can get past just the application backlog and the communication gap with the right kinds of low code of purchase. I don't think code integration works nearly as well as some people claim it is. But yeah, those first few things. I think we can do that. I think we can do that.

Mario Cunha: 33:12

All right. It's pretty good. Um, actually, I was just thinking of what you just said, about the integrations and how hard they convenient and that they are more politics than anything else. It's so true.

Mike Fitzmaurice: 33:29

You know, I, here's, here's a red flag for me when I look at a local platform, it's not, if they say we've got hundreds of ready to use connectors, you can treat them like Lego bricks, snap them together and magical habit. It's not that the having a lot of connectors is a bad thing. It's a good thing. It's a useful thing. But thinking if that's one of the first things out of your mouth, it makes me think that you probably started in the wrong place, and you prioritise the wrong stuff. Because if I want to create, again, a personal application to scratch at personal itch, a connector that talks to my contacts in Outlook Connector that talks to my accounts in Salesforce, an account connector that accounts or connects to a shared calendar, or if I'm glueing, together three or four data sources that I work with on a regular basis. Great, yeah, you can do that with canned connectors coming from somebody's library. But here's the key here. You have 100% authority to touch that data. It's your data. The only thing you have to care about is your stuff. Now if I curate our ERP system. And you curate our marketing automation platform, email campaigns, digital marketing, and you want to log activity or outcomes or something like that into my environment, could even be lower stakes than ERP, it could be CRM or something like that. But still,

Unknown: 35:24

I don't know you.

Mike Fitzmaurice: 35:26

Maybe company picnics or meetings here and there, you seem like a nice guy. But I don't know that you know how to work with Salesforce, I definitely know that you don't know how we in my team use Salesforce, we got to teach you a lot if we're going to let you open up our file cabinets and go through them, you know, with a flashlight in your mouth and some gloves. I don't like that. I like that idea very much at all. And again, it's not a question of bad faith. It's a question of, there's more to this than somebody snapping together to Lego bricks, their policies, their procedures, there are permissions, there might be compliance concerns, there might be an audit trail that needs to be followed. Integration at the corporate level is hard. And it's not hard because people are jerks. It's hard because the world is more complicated than we often think about. So it actually does require us to do some negotiation. In fact, that might be we might be better off if I write a small automation script or business process, and make that available to you, as you write an application that needs to talk to my CRM data. So you have a leak, you want to pump it directly into Salesforce, I love that. So I'm going to give you something that you can call as one rest method. And it'll use what whatever scripting facility I want to use within my environment or third party facility that I want to use within my environment that puts the right things in the right places under the right conditions, you just call it magic black box. That works out really, really well. No one's got that in their toolbox of 500 connectors. That's something you and I, and we as an organisation, curate, we create it, we evolve it, we look out for it. It's part of what makes our organisation special. So I think and we negotiated it and created it together. And that is what integration at the enterprise level is like, if an application if a low code platform thinks that integration at the enterprise level is snap this to this and you're done. You're probably thinking of the wrong tools.

Mario Cunha: 37:57

Or getting ready for a big headache ahead of him.

Mike Fitzmaurice: 38:00

Yeah, yeah. But again, that's that that is aimed at one person scratching one inch. And, again, if that's all your application has to do, yeah, use that tool for that. For the love of God, don't use it for more than that. I'm saying

Mario Cunha: 38:17

he has a purpose has a purpose, are about to what do you think?

Tiago Neves: 38:23

I was just thinking about? So basically a question for for Mike. But, Mike, how do you think that the business might might perceive them low codes, in the sense of, it's not a silver bullet. So all these challenges that you're raising, that they are still there? Can it be that business just might then give it too much value thinking that it's gonna solve everything,

Mike Fitzmaurice: 38:55

under help with a lot of things if it's done well. So at the very, very least, it and I'm using it as an umbrella term now to mean all the technical people employed by the organisation as opposed to all the business people, I don't necessarily mean that people who maintain the infrastructure or evolve the infrastructure. I'm also including developers, it if we're talking to technical audiences, there are people that build solutions, build applications, there may be a business process team, they don't think of themselves society. For our little discussion right here right now for the next minute or two. There it. Alright. So yes, low code is going to help it be more responsive to business because, again, a lot of the stuff that slows them down. They don't have to deal with that. That's a good thing. Or they don't have to deal with it. It's done for them automatically in a systematised way, so everybody has to agree that it's okay for it to happen in that systematised way But yeah, it's gonna help them build more in less time and do a lot for them. So they don't have to do everything by hand. It's like using power tools or labour saving devices in the kitchen. It's going to help them get more stuff done in less time with more predictable, sufficient results. You're not going to create grand art with code, which can happen sometimes, but everything else. Yeah, it's going to help. It's not going to solve, but it's going to help. And that might be enough. Here's the key. No, we're not going to win hearts and minds and the love the business community as technical people if that's all we focus on, if we use the right kinds of logo tools to improve our communication, our project management and our transparency, our collaboration with business. Yeah, there's still a lot we can do with low code to improve the organisation the total throughput of the organisation. And the right kind of low code tools save us an incredible amount of time. I'll give you a perfect example. What if we are able to create a business process diagram that is understandable by business people, but the understandable business process diagram is the flowchart. With a lot of environments, you've got one diagram you're going to create to explain what it is you're going to do and a different diagram you have to create to actually build the workflow logic. The latter one you can do automatically. In other words, I could sketch it out in somebodies workflow ma modeller, and then it will generate the application that we need. But the diagram that explains what we're doing that happens by hand, there might not be a relationship between the two diagrams at all. What if they were one diagram? What if it were actionable? And understandable? At the same time, we can get a lot more done that way. What if you and I can sit down together, and we can create the look. And in broad strokes, the behaviour of the application you want me to build for you, in order to build an example of what you want. So I can see if I can try something, you can tell me where I'm wrong. And within about an hour's time, we can agree that this is what it should look like this is what should happen when you click this button, and so on we create, this could be a wireframe or something that looks a lot nicer than that. But yeah, if we look at low code stuff that is not just about construction, but it's also about collaboration, and cooperation and communication. Yeah, that's going to solve a lot of IT problems that haven't been touched in the past. Because it is not known for being good at communication or or good at providing communication or understanding communication. That's the organization's fault as a whole. It's not just it, but but at the same time, you know, we use the right Lopo platforms, platforms, not just tools. We address more than just construction, we addressed collaboration, long winded way of saying you use the right tools than the answer, yes.

Mario Cunha: 43:45

Okay, could Luke code continuous focus on automation? Bring any sort of unwanted consequences? Could it be become too focused?

Mike Fitzmaurice: 43:57

I actually am very, very wary about automation. Because it is far too easy to beautifully automate a terrible process.

Mario Cunha: 44:11

It's a good one. Yeah.

Mike Fitzmaurice: 44:16

And the problem is, unless you live this stuff, it doesn't occur to you that automation and process and workflow are three different things. And again, I don't expect somebody that doesn't live this all the time to care about the difference between processes and automation. But, you know, there are a number of wonderful tools out there from RPA vendors, robotic process automation vendors, you know, the UiPath, blue prism automation anywhere. There are others, but those those are the three rock solid dudes. They, they do good work, but they'd actually be the first to tell you that They're not in the business process modelling and automation business. But they're really automating our processes. They're automating activity tasks, there should be our TA or RA or something like that, as opposed to RPA. But they have the name that you really should combine that sort of thing. with something that looks at the business process, what are the assets, we need to get this done? What are the goals we have? What are the How will we measure whether we accomplish it, what should be done, and then we defer to rpa, or scripting, or automation tools, or any of a number of different things that or even code to actually execute the things that the process tells us? It's time to do? Yeah, it's, if all we focus on is automation, one of two things happen, we will slavish li try harder and harder to automate what might be bad processes, or what we'll have is working very hard to automate implicit processes. Maybe they're not bad, but they're in our heads. In other words, what to do gets automated, why we're doing it gets lost if somebody leaves the organisation, or it's manual and has to be read in order for you to understand which automation to kick off and what to do with the results when it's done. I yeah, I have a problem with that. I think that looking at automation, and only automation is a very incomplete picture. So you have to think of the process and think of the data assets as well. But yeah, there's subject matter expertise that matters a lot in the world of process management, it's thinking about the process first, and then determining which assets you need, and which automated bursts of activity should be created to support the process. Doing it backwards, involves a lot of risk. The same kind of thing happens in the world of business intelligence, I can't tell you how often people have just said, Okay, I've got this data, let's see what I can find from it. By doing ad hoc analysis, after ad hoc analysis without really understanding the data that they're analysing in the first place. They might draw crazy, they might occasionally come up with something no one had thought of, but more often than not, they'll draw crazy conclusions because they are grounded in the subject matter. It's really easy to focus on cool tools, without thinking through, why you're using them in the first place.

Mario Cunha: 48:03

That is quite an interesting, I did like the the example of the business intelligence kind of makes you think we have a set of data, let's look for patterns. Okay. Some patterns just happen because they happen. They don't have any meaning behind it. Or if

Mike Fitzmaurice: 48:19

Yeah, okay. Well, it's it's still it's 2020. It's the beginning of 2022. If someone's listening to this next year, hopefully the whole pandemic thing will be over. Yes. But yeah, this happened more in 2020 and 21. But there were countless armchair epidemiologists who had it, who were business intelligence, people that just love to be able to get at crunch numbers and say, actually, what's happening is this without understanding how viruses work, or how, you know, without knowing things that doctors know, it's not just about data, there is a certain sense of subject matter expertise that matters. Data Analysis contributes a lot to human knowledge, but not without some knowledge to know what to do with the data in the first place. So sometimes wonderful things happen. But a lot of people, basically because particularly in the first year of a pandemic, when there were no vaccines, there were lots of lock downs. You know, what am I going to do? Well, this data is publicly available. Let's see what I can figure out a lot of crazy inferences happened that that that was more 2020 than last year and certainly more than this year, but you know, it's a big obvious example. You got to got to know what you're doing in order to handle the mechanic Parts of it well,

Mario Cunha: 50:01

make sense makes total sense. Jaggu anything you would like the head?

Tiago Neves: 50:07

Don't just just love that example, Mike. That's all.

Mario Cunha: 50:13

Okay guys, on that last note then we end today's podcast. Thank you very much Mike Integra for joining us. I bid love your company like amazing. I would also like to send a big thank you to everyone who is listening and hope you can join us on our next episode of high tech local podcast where we will always talk about more topics about the tech universe. See you soon. Bye, everyone.

Unknown: 50:36

Outstanding. What a pleasure. She is. Bye bye