Mark and Brent discuss the latest news in RPA. This week we talk about whats happening in the RPA space, like recent venture investments in Tonkean and Electroneek. We'll also talk a bit about legacy COBOL and why we think low-code is still code. Mark and Brent discuss the latest news in RPA.
Google Play / Apple Podcasts / Spotify
Episode 2 - Industry News
SPEAKERS
Mark Percival, Brent Sanders
Mark Percival 00:02
Hey there, welcome to another edition of the it's atomic podcast.My name is Mark Percival.
Brent Sanders 00:06
And I'm Brent Sanders. Yeah, so
Mark Percival 00:09
we have a fairly good chunk of topics to talk about a little bit of legacy code to talk about, we can talk a little bit about sort of the what we're seeing in the space, the pushing around the low code, developers, so the citizen developers, and then there's a fair amount of funding activity going on in the RPA space.
Brent Sanders 00:31
We're in the midst of a pandemic, as everybody on this planet seems to know. And the first bit of legacy code news that's been in the mainstream news has been around unemployment checks getting held up by a coding language that almost nobody knows. Yeah, the famous in, or I should say, infamous,programming language of COBOL, which has been around for a long time. And we seem to not be able to find COBOL developers. But if you were to look up COBOL programmers right now, just a little tidbit, you'd find an ad on Toptal. They have the top 3% of COBOL devs, and Toptal is not a sponsor of the automic podcast. But um, yeah, so mark,maybe you can tell us what you know, like, what have you heard about? Yeah, the state of sort of these unemployment agencies?
Mark Percival 01:28
Yeah, I think there's a couple articles that came out this week.And then wired wrote one and Ars Technica wrote another one. The general gist of it is there's about six, I think six states right now that basically have their unemployment system running on a COBOL system. COBOL code base. So essentially, what's happening is the pandemic has caused the unemployment obviously, spike, that's meant that more people have gone to these systems, and overwhelmed them overwhelm the systems. And so you're seeing the system just basically fall apart, and the states are rushing to figure out how to actually fix this problem. And it's what's coming to light is that these systems are a lot of these systems are written in fairly old languages. And in this case,we're one of the oldest, which is COBOL, New Jersey's I guess, the poster child of this, they actually have asked for, for volunteers to help fix it. IBM,meanwhile, is trying to ramp up their education, and training on COBOL. And essentially, yeah, these are old systems that are running our unemployment systems and COBOL. You know, to give a quick history of COBOL, I think, about 60 years old 59 was when it was first developed. So, you're dealing with a really one of the first computer languages along with Fortran. So, you saw sort of COBOL go through these different iterations. And it was heavily used by the government at the time by the Department of Defense, and then it sorts of seeped into all the other government institutions. And I think you see this in a lot of computation early on was a lot of it did revolve around payment processing. All right, you know, you looked at like the some of the first use of IBM mainframes. Really the punch card was really social security was like,how do you write all these checks? And how do you keep track of all this, this money that's being served. And so, it's not that surprising that unemployment is a system that's been built, you know, 34 years ago in the States, and it was built on COBOL and hasn't really been updated.
Brent Sanders 03:13
And it stands for common business-oriented language I'm reading.Yeah, I'm looking at the Wikipedia page. I don't know that off the top of my head. But it reminds me of something else that reminds me of robotic process automation. I mean, it's, it is it's a weird, like an omen. It feels like an omen.
Mark Percival 03:32
Yeah. And you see it too, right? It's very procedural. So, it's all about process. And, and it came at a time when software development really wasn't a, you know, thing, outside of, you know, it was basically the systems were fairly unknown. And, and you had a, you could program an assembly, or you could, you know, this is this was the age of punch cards. And so, this was supposed to make it easy for sort of anyone, it was sort of the low code platform, you basically didn't have to have an expertise in assembly language,or some of the more esoteric issues of software development. And this was all about putting together a really simple program, it looks if you look at it, it kind of reminds me of back in the day, when you took if you depending on how old you are back in the day, when you took basic, right, it kind of feels that same procedural like that same type of procedural language minus the go twos,but basically it has a perform a call that you can then write a procedure that runs when you call perform. And so, it's very much like calling a function, but it kind of goes to that place and the process.
Brent Sanders 04:31
I should say, many of the systems have been in the process of rolling off and they were they were supposed to roll out to new I think there was one state I don't remember the name, or the actual I don't remember the state. But they were about to roll off of cobalt and the next coming weeks, but they weren't quite there yet. So, it just it exposes This is the rewrite. Yeah,the rewrite was almost done. Only took five years. It comes back to this comic conversation. That you'll hear on this podcast. And you'll know, we personally talked about often, which is, you know, just legacy code and the risks associated with it. And so, with COBOL, it's been taken to such an extreme where Reuters reported in 2017 43%, of banking system still use COBOL, with over 200 million lines of COBOL code. And yes, I mean, that's, it's nearly a majority of what I would expect bank mainframes a couple years ago, and knowing how long it takes to move off of those platforms, that's likely, in my mind,it's likely the same number now, or at least very similar number, which, you know, how do you get off of them? You know, there's a lot to be said for the work that went into that. And there's a lot to be said for how the business has a depth did to the legacy code, for example, like what workarounds might be in place that you get trained on when you work at the Department of Labor that says, Oh, well, the computer gives us this information, then we have to fit in,in this program, and programs on programs that are written to sort of workaround how the law changes, and like, the government similar to a lot of businesses where, you know, it doesn't change quickly, but it does change overtime. And you have to have to keep that, you know, software up to date, or you're working against it. And this is, I think, unfortunately, with a pandemic, there's a delay, and there's, there's a call to the public for help.I can't imagine what the volunteer force that dialed in. That's like, I can't imagine, you know, how, how you're organizing those people how you're trying to get them to work together,
Mark Percival 06:42
or that they can do much. I mean, I think the other issue is that even if you know, cobalt, you know, if you've been programming it for 50 years coming into this and saying, Well, I can fix a problem of what it really comes down to just demand search. And there's not a lot of maybe you can make some easy wins early on, but there's probably not a lot you can do other than maybe you're trying to put something in front of it that can flatten out the demand.But it's hard to sit there and imagine that a volunteer force is gonna come inhere and solve the problem that hasn't been solved, you know, in the last 20 years. For these dates,
Brent Sanders 07:18
let's move on. But anyways, let's, uh, let's talk about uh, other news. What else have we Mark?
Mark Percival 07:24
Uhm we got. Let's see, there's a fair amount of funding we can talk about this week, I think you can see there's two funding to fundraisers that I think we talked about one of the newsletter was the $24 million raise by Tonkean. The other one, the other one was the raise by electronic. And I think one thing for the for the targeting group, the 24 million is huge. I don't know if you had a chance to play with it or see color their demos, it's more graphical lightweight. They call it a no code, no code version of RPA. But 24 million, obviously a massive, massive rays, and led by a fairly, you know, class A's VC firm. And then electronic came out of Y Combinator. And they raised and for them, that was a smaller raise it but it's sort of a seed stage race. But I think the interesting thing here is, you're clearly seeing a move from VC and RPA Space. Yeah, you have older companies that have existed for you know, a decade or more. And now you're starting to really see they are gaining massive attraction. I mean, the other piece of news we'll talk about in a second is that you were UI Path is, but right now you have these new up and comers, that VC is really starting to pour meaningful, meaningful amounts of money into.
Brent Sanders 08:41
Yeah, the word I would use is frothy, right? There's a it seems like there's a new RPA product that I find out about every week. Yeah. And maybe I'm out of the loop. But it seems like they're popping up. And there's different takes on similar problems. And it's exciting. It's really interesting to see, as people are putting more and more talent into solving sort of these repeatable work problems.
Mark Percival 09:06
Yeah, and it's not too unusual to see this in a lot of technology spaces, which as you'll see kind of the incumbent, grow a market to a certain size. And then once you see it hit that size, and then the growth will kind of accelerate from there. That's when you really see the next level companies sort of come in and start to feed off of that.
Brent Sanders 09:24
Would you call this a no code platform? Or even like a loco? I mean, how does it stack up to some of the incumbents out there again, you know,us, we don't really have a perspective of every single platform, but we sure have seen a lot of them.
Mark Percival 09:36
Yeah, I'm skeptical. I mean, I think you're skeptical as well. But I'm skeptical and no code low code. Yeah, I find no code is hard. It just, it just means it's graphical. But there's still the problem of it's still a process. And it still takes that sort of mindset of, well, what is this process going to look like when it breaks? And then what will the failures look like?And how do I expose them in a way that that's useful for debugging. No code doesn't take that away. I think it's, it's an expertise that you have somebody who either has an expertise or they don't, if you try to plug somebody into that, without a fair amount of training, I don't think you're gonna get what you want out of it. The same with low code, which is, which is still here, if you've dealt, if you've ever dived into UI path, or you know, somebody who's an RPA developer, it's hard to really look at this as low code. It's still code.And that's the I guess that's the crux of the issue is that it still ends up being code. And if you kind of dive into this space, you start to see that what looks like low code very quickly evolves into something very complicated. And you will start to have to have a knowledge of things like queueing systems. And you know, what happens when the queueing system fails and exception handling,and Error Reporting? All these things are, are not easily encompassed by just saying what's low code, it's very easy to do. It's up, it's not easy to do it,there's a reason why you know, that people have this, this expertise, and they can kind of go in and do this.
Brent Sanders 10:54
Yeah, I really am intrigued by these platforms in, in the sense of the future, right of like, you know, you can start to roll out some pretty simple processes. And if those automations, if they last for a year or two,what are those look like on the respective platforms? As you know, a company that's raising a series Hey, my expectation is the platform is going to evolve a great deal. And, you know, what does it look like? If you adopt this product?You put it into motion? And you're about sits there for a couple years? You know, is it? Is it going to just run as it has? I mean, are there gonna be generations of this platform that evolve? And you have to keep your thoughts up to date? I'm curious, I would love to. Yeah, hands dirty with it.
Mark Percival 11:43
Yeah, I mean, I think I wrote an article about that, about this this week, it was basically equating this to excel. And I think you see the same thing with you, you pull an Excel developers might who's not doesn't have a ton of experience that wants to work in Excel, they can get some results very early on. And they work great and excels at a phenomenal program for somebody,I would call it low code in itself. But obviously, you know, Excel spreadsheets have a tendency to become very cluttered and disorganized. And then a year on,they don't make sense, because the person who developed it is gone. And it'snot really clear how it works, or what the you know, the inputs are. And I think you're gonna see the same thing in the bot space, which is, it's probably easy to start off with one of these packages. But if you're in a large org, and you're a year out, and you don't have a good idea of how to create these bots in a way that makes them very easy to test, and to figure out how to debug and understand the context and have documentation, then you're going to have a total mess on your hands. So you'd be no different than having an Excel spreadsheet from two years ago, written by a guy who's no longer at your company. And you're just kind of stuck.
Brent Sanders 12:45
Yeah, it's funny, it's exactly like code or Excel sheets, or that's a great metaphor to use, because it's a reflection of like how you think about a problem, and how you think about a solution. And you're given a grid, right,you can decide to organize things in sheets or not, you know, it's, it's, it goes back to standards and best practices. And so, I it, you know, regardless of the platform, writing code, or dragging boxes and connecting lines, there,there still seems to be a strong need for standards and practices.
Mark Percival 13:20
Yeah, processes. I think you see this in almost all software, you see this, you see an early version of software, something like PHP, there's,there was very little direction as to how you could handle it, how you can build on it. And then you sort of have everybody's pick comes up with their own best practices, and excels in that same place where it's, it's, you can build your values on one sheet, you can put them on the same sheet, you can use things like V lookups, and H lookups. You can build documentation into it, you can even do some form of you know, sanity checks, numbers and testing or not. And then what you see in software world is the same thing with best practices. As these tools get more mature, best practices show up and when you're have hire somebody to do that job, that person will typically take those best practices and when they utilize them, it's for the future where you bring somebody else and they can look at that same code base and say, Oh, I know what they're doing because they're doing the same way I would have done or this doing this? This certain they're using a certain pattern? And you don't see that with Excel.
Brent Sanders 14:18
Yeah, yeah, funny little story. I my first job out of college was working in an options trading firm in Chicago. And we had a couple of traders that would literally trade through the parameters they would set in their Excel sheets and they use VB scripts do the training the training for them it was hilarious to see because it really just kick their feet up, drink coffee,watch, you know the colors twinkle on their, their Excel sheets, you know, they were able to color and styles and everything and it was a it was quite the sight. But yeah, it's a tool, right? And so, it's you look at Tonkean and you look at Electroneek you look at any of these things, their tools, you can't really get mad at a screwdriver for what it does, right? If somebody if you put in the hands of somebody and they build some monstrosity that the next person looks at and says this, this needs to be thrown out. It's really no different than modern software engineering with a framework in place or best practices in place, or standards. But, you know, what do you do, automation is not a new industry. However, this this sort of new wave of low code and RPA tools, or even no code tools, it's just bringing me back to the heady times of the web event, which we've talked about in our previous podcast of, you know, like you said, PHP, there was, you know, however you want to handle a request, we have tools here for you, you can use it however you like. And you started to see,okay, well, there's actually classes that get developed, and there's a right way to do something. And if you do it the right way, hey, we'll build in things like sanitization, and make sure that it's, it's safer, because that's, I think, with all these tools, there are probably some hilarious, you know,vectors in ways that you can potentially pollute your data, which is probably the scariest thing that a bot can do, to me is to, you know, to get some undesired data into the mix of your cleaning production data and managing Howto Unravel that problem.
Mark Percival 16:23
I think that I think that's right, I think that goes back to your options trader analogy, which is that person was sitting in front of that spreadsheet. And if they saw something they didn't like, they can go in and tweak it. But when it's automated, and it's running at, say, 3 am, on a Saturday,and it's dealing with something on the payroll side, you know, you're not gonna you don't get those same advantages to have somebody go in and tweak it, it's going to do what it's going to do for you, for better or for worse. And so, I think that's sort of the danger there. And then going back to the PHP side, I think trying to put those things in afterwards is very hard. So, PHP, I think,is a good example, because I remember, I'm sure you remember this as well. PHP first came out very simple, you know, embedded in HTML, and it didn't really have this idea of classes. And then they came in and said, oh, we're gonna add all these options for object-oriented programming, and nobody used it.
Brent Sanders 17:13
But you know, could if you want.
Mark Percival 17:15
Right, right, but everybody had gotten so used to not using it. And they'd also built other systems around it without this object-oriented layer. So,it was like, well, adding this didn't necessarily make sense. And there wasn't a clear way of how to add it later on. I remember, this was always an issue with things like ORMs, as a PHP developer, you were basically just stuck writing SQL, which was horrible for security standpoint. But you would just write SQL code raw SQL code and feed it in there. Maybe it was sanitized, maybe it wasn't. But you know, this idea of an ORM, or a layer or a class, object-oriented way to access these data models, these structures was just wasn't there. And so,when they put this in later, you know, you saw sort of programming languages like Ruby, and rails, kind of put these best practices in, and these are M layers, and people started using them from day one and expecting them. But they didn't have that with PHP. And so, I think if you build that automation process, on one of these systems on these local systems, and you don't have those best practices in place, I think you wind up, it's very hard to come back in later and add those.
Brent Sanders 18:13
Yeah, yeah, but yet, PHP7 is here. And, and it, you know, you can still use a lot of the same code that was around, you know, 10, 15 years,again.
Mark Percival 18:23
Yeah, not to knock PHP, it's amazing how long that language has lasted and how much it runs. It will be the next COBOL.
Brent Sanders 18:32
Maybe a topic for another discussion, but whatever happened to PHP6. there truly was, I think, you know, I think it was related to, I think they took on UTF-16. They adopted that. Yes, early on. And that was the, the nail in the coffin, and they kept trying to develop it, and it screwed up performance,I believe. But we can dive into that another time.
Mark Percival 18:54
That would be a great podcast, I think we should do that.
Brent Sanders 18:58
I'm looking at, you know, this talking deal. I'm from another perspective, more of the VC perspective. I'm interested that, you know, they closed this deal during the middle of a pandemic, I assume that this was probably done a month ago, nearing, being done month ago, and probably just was delayed slightly, but I'm curious what your thoughts are, I mean, do you think this deal probably close faster? Or was it you think it would have been delayed or seeing a hesitant because, in my mind, I see with the pandemic and I, you know, I you could go off the deep end on what its effects are going to be on the economy in the workforce. But I, I think it’s fairly common sense that the desire for automation will go up.
Mark Percival 19:40
I imagine I mean; I think there's probably a fair 5 few things to play here. Obviously, the VC had to be comfortable committing that kind of cache at a time when things were getting a little bit dodgy and you just don't know where that VC stands in terms of where are they on their fund raise from their LPs. How much cash Do they have how much dry powder do they have to go and make these investments? But I think where RPA is right now is in such a,you said it before frothy space, I think everybody is sort of trying to figure out where this industry goes next, and who's going to be the next leader in it,who's gonna be the next UI Path. And so, I think it makes sense that we're still going to see a fair amount of investment, even through the pandemic,there's still a lot of VC activity going on, even through this pandemic. I mean, even just looking at the stock market right now, it hasn't. It's been surprisingly resilient after the initial drop. And so, I think you still have a lot of companies out there that are gaming the fundraising period, I think the harder companies are honestly the ones that are in the middle. So, if you don't have that meaning for revenue, but you've taken money in the past, that's a tough position. But if you're coming into Atlanta, like we're talking is, they actually, you know, clearly things are going right, they're building a product that the VCs believe in. And so, this is a very early stage.
Brent Sanders 20:51
Yeah, it's great news. It's great news. Let's move on.
Mark Percival 20:54
Yeah, what else do we have? We had a couple articles this week, I think one that I found interesting was the seven, crucial RPA developer skills.And then the other one was the, you know, there's a great article about how messy tech sometimes wins, basically, in the software business, and they were referring this, they were referring to this and the RPA space, especially basically saying, look, RPA really does kind of come down to connecting these messy technologies together. And I think that's the best way to describe it is it really is binding a process that you have a business process that's very hard to connect with another process, and there's a human in the middle, and they're performing some role that is that is, you know, easy to automate. But it's just, it's hard. Because there, you don't have the system, you may not have API access points, you may not have the resources, and RPA kind of comes in and says I connect those two imperfect systems together, in a way, and so I think it's an interesting article where he the author kind of goes into sometimes messy tech does when it's not always going to be the technology, that's perfect. That kind of wins the market.
Brent Sanders 21:53
I think when you go back to messy, it's like, to a certain extent.And this is, I think, from the business world, it's like, Who cares if it's messy, if it gets to like, the one thing I learned in the last, I don't know,half a decade is like business in general is very messy, like, you think, you know, when you're, especially when you're writing software writing code, you'r eat the outset, you're moving quickly, and you're everything's clean and Greenfield and you're putting everything where you want it to go. And then, you know, the thing that starts slowing you down, as you start uncovering business rules,well, we want that form to only show this field when this, you know, this case is true. And you start gathering and throwing all this, this weight in your backpack, so to speak, and encumbering you in slowing your ability to respond to change. And this is like a common thing that happens. And if you know,that's kind of reflected in the tools we use, and again, going back to COBOL,or going back to RPA, or even low code technologies, you're still going to have that long term sort of bloat that happens, it's like, well, things change, we have to build on top of the thing that we built on top of and yeah, until there's this massive rewrite. And it's like, you know, I'm kind of straying from what the article was saying. But if you can use small tools, or sort of small implementations with straightforward to use tools that may appear messy,that is an alternative to a rewrite, or an alternative to sort of furthering your tech debt, by, you know, I'd rather let me put it this way, I'd rather look at a solution to apply a couple of bots to some legacy code then to do a rewrite number one, or number two, to dig into the legacy code and pretend that I know what it's done for the last 20, 30 years, and start making changes and see what happens. Yeah, the reality is, is like, the ladder is, is that might be the let's pull the band aid off. And let's fix this thing once and for all.But you know, I think that's where you see the Department of Labor in the states falling behind, because it's like, oh, we had five years to roll off COBOL and we couldn't get there or we didn't you know, pandemic it. And now we seize the system entirely.
Mark Percival 24:18
And I'll tell you them that that kind of stood out to me in the article was they mentioned familiarity with meltdown and methodologies such as six sigma and lean, which I think was an interesting one. Because if you come from a software background, Six Sigma doesn't really exist outside of accounting and enterprise and sort of on the on that spectrum. But if you're from the sage spent, you know, 10 years in Silicon Valley, six sigma was just not there. Lean is a methodology that you see a lot and you see a lot of software shops that organize around that, but I think that kind of highlights that. These professionals sit at a different level. They really do sit in the business process side a bit more. And that's really where you see this. The this you know need for people that are not just good software engineers, but also have the ability to kind of get their hands dirty on the business side and understand those business processes and really understand how those organizations you establish that level of excellence, but not on the software side. But on the business process side, which isn't always clear.
Brent Sanders 25:17
Yeah, know that. It's an interesting aspect. And I think it's the right take, because, you know, you're trying to solve something for the business, you can't come into this without any context. And it's, this is going back to like this sort of citizen developer, citizen engineer aspect of like,hey, this, these RPA platforms are like Excel, I think that we'll see, you know, depending on where the industry goes, right, it's like, it's possible that this low code - no code approach takes off. And now those people are the ones creating the bots versus, hey, we need to create a process diagram, a solution diagram, and we need to hand this off to an RPA developer. And so, you know, if that ends up being the case, it'll be really interesting to me, again,I go back to the part that I found most interesting is like, where are these bots going to be a year and two years from their inception? Right? They start off, and they're solving real problems? I mean, how do they respond to change?How do they respond to changes in environment? And what do you do when they break? And if you've replaced that manual process for a year now, no one's done that job is? How do you, you know, manage a business continuity plan? Or how do you manage a breaking pot?
Mark Percival 26:36
Yeah, I think it's frightening if, you know, I figured if you're a company looking at this, and you don't have an idea of where this is, in a year, I think it's hard to kind of map that out. without, without really looking forward to that 10-year marker of what's gonna, what's this gonna look like, when I have 10 of these bots, when I have 20 of these bots? What's this gonna look like when I have, you know, if I have the citizen developer group is this, what's gonna happen when I have a bot for every employee as they pitch.That's a lot of automation taking place. And it's, you know, it's potentially written by a lot of groups, that's a lot of training, that's a lot of getting people up to speed, I think you're gonna see more of the more of the software development side kind of come into this. And as well, from the staffing side, I think you're gonna see more and more software developers move over to the RPA roles.
Brent Sanders 27:21
Yeah, I mean, you're writing code, which is, you're creating liability, because it's something that is potential to crash. But more importantly, you're gonna see code review happen, I think you're gonna have to see, like the code review process be introduced in non-engineering cultures.And we talked about engineering cultures last week, and probably put a good definition against it. But in short, you know, Johnny from the accounting department doesn't know, you know, there is no such thing as a code review process. And if he starts writing bots, or creating these bots, and then leaves the organization, there's going to be this discovery upon his departure, or when the bot breaks, and someone has to fix it, just like you mentioned, with the Excel sheet where, you know, it's completely disorganized knowing really tease out the mental model that was used to develop it by looking at just the formulas and it's a rewrite. It's alright, throw this stuff out. We need to do it again.
Mark Percival 28:16
Yeah. And I think that's what a lot of companies are, unfortunately,looking at if they don't actually get a handle on this early on, is they're gonna be looking at that a year later. It's a rewrite, which is horrifying.
Brent Sanders 28:25
Yeah. Yeah. I mean, imagine the resources going into training these people in the time, I mean, some of these tools look great, right? It looks super easy to get about stood up, maybe you can do it in a day or two. But, you know, is there any accountability for them? Is there a peer review? Is there a Hey, you know, because what I think will happen is that they're going to work really well, right? And so, processes are going to change where, hey, we don't have to do the job and or have to dash anymore that, you know, the bot just goes through our email and does it for us, and then you lose that context. And it's just, yeah, it's a huge risk.
Mark Percival 29:03
Yeah. So, I think I hear what I think what you're saying is that you wouldn't invest in talking.
Brent Sanders 29:07
I think that I think I would I actually, you know, it's a top tier VC firm. They obviously know what they're doing. Not to say that's my investments, is just go with whatever the good ones are doing. But no, I do think that this space is it's frothy. But then again, this product, I mean,their product then was great. And like if you want to you want to move it does remind me of was ifft.
Mark Percival 29:37
Yeah, no, I think it has a great product, I actually think that the IoT issue is I think it's probably going to be less used by the citizen developer and it's still gonna it's gonna be another tool in the development. The RP developers tool set.
Brent Sanders 29:49
Yeah, yeah. And I think that's a still a great outcome. Like if that becomes You know, this. Yeah, the thing I was just gonna because my end You know, being a web developer in the past, like if you can become the WordPress of RPA. Like, that's amazing. You're, you know, it's full of, you know, its own issues. But it's an easy to use platform that everybody sort of just realizes, okay, well, this is what we want to be able to do some basic,simple pieces. So, if I wanted to launch the equivalent of, I just want to launch a blog and a landing page for RPA. That's huge. And that has its place where it's like, you know, you don't need Sitecore to launch just, you know, a blog and a landing page, like the, these larger enterprise products have their place. And, you know, I'm not saying that this is where Tonkean wants to be.But I think that there's, there's a lot of different options. You know, this RPA, the, the, the article around messy tech, you know, they talk about is RPA,the next Salesforce, and so if your mind, it's like, it'd be great if it is right, it's like that's not a to me, Salesforce can be used for anything and you see, you know, in one to two year old Salesforce instances, you know, what data ends up in what fields and sort of that cloud of Yeah, that that messy cloud of data that needs to be sort of fixed after a couple years? And because the business changes? It's like, Oh, well, we stored their phone number in the email field, because, you know, we wanted to show up in the view, right? Yep.It's like, Oh, God. So now we have to, we've got to migrate this thing. And so,I think we're gonna see a lot of that in RPA, I think. But it's also, we're just, you know, one thing I wanted to talk about in it might not fit right now.But if you look at what automation is doing, and we talked about COBOL at the beginning of this podcast, and in looking at it, okay, well, this was the first sort of local version of assembly. Right, yeah. You in this is a common pattern that's been happening generation after generation is that you get more abstraction.
Mark Percival 32:01
Yeah, I'd say that the code that you write today is going to be in production for longer than you expect.
Brent Sanders 32:06
That's a good point. So, I think that leads us to the this other, I think there's the last article we're looking at for the week was around why you need a digital transformation Center of Excellence. This was on Tech Beacon.
Mark Percival 32:21
Yeah, and this was based off a nursing young report that basically said 30 to 50%, of initial RPA. initiatives, and a failing. So basically, the first, their first RPA, push as a company, typically 30 to 50%, end up failing,and they're really boiled it down to, that's that lack of a center of excellence. And I think that's business. It's obviously a term that's used all the time in RPA. But just boils down to best practices, having some structure,having some idea of what this is going to look like in a year having some idea of how you're going to account for all this, how you're going to keep track of it, and how you're going to keep paying on, you know, paying off the maintenance on needs on all these automations.
Brent Sanders 32:57
I think was part of the article, according to Forrester, two thirds of automation leaders cite the fear of job loss as a concern, because his most negative attitudes about automation projects. And so, I think it's, you know, as you have this COE, they need to be addressing, like the other grave thing, which is around culture. And I have a post that I've been thinking about and around, you know, what is the cultural implication to automation, right, obviously, there may be changes in the org structure, you know, people may Institute hiring freezes, and, you know, there might be some replacement of human workers, it's like, Okay, well, what does that mean to the organization? And what does that mean to the workers? Because that's, that does have an impact. And so, you know, going back to a COE, and like, how would they help in these situations? Obviously, there's the best practices around code, but there's also this, this element, it's like, what is going to be the overall impact of automation on the business? As we're talking to more people on the podcast, I really want to know, you know, what their experience has been around what RPA did, has done to the culture and their implementations and, you know, was it positive? Was it negative, you know, but I do think that that's one positive effect that I see we can have on, you know,doing an actual through and through automation implementation?
Mark Percival 34:27
Yeah, I think that's a good point. I think it's I think it's important to address the cultural aspects of this. And it certainly makes sense in the coming from the software side, which is the culture inside a development shop is critical to actually what you end up outputting. And it's not just about the code reviews and about the best practices, it's really about the larger issue of, you know, having aligning people on those values.
Brent Sanders 34:49
You can look at other areas of software and apply them and that's exactly what this list just looks like. How do you introduce these sort of engineering principles into accounting and HR, whoever is applying these, these bots?
Mark Percival 35:03
So, what I thought was one of the responsibilities they listed was enhancing a business process before automation. And it was really like, I do think that's about figuring out Well, what does this process look like once you automate it, but also, let's look at it beforehand and actually understand it and actually see if there's other improvements we can make before we actually get to automate it. Because I do think it's not going to be the same as just saying, well, this person did this, this and this. So, we'll just have the bot do this, this and this, there's probably a chance that you can drop something out or there's a realization that maybe some of that is not actually all necessary.
Brent Sanders 35:32
Well, I think that's it for this week's edition of the it's automicpodcast.
Mark Percival 35:37
I think that's it. I think that's it. I don't think we have anything else. I think that's everything that happened in the RPA world.
Brent Sanders 35:43
Stay tuned. More podcasts on the way we have a couple of interviews that were lining up. Feel free to email us at Brent@itsautomic, and Mark@itsautomic. And stay tuned. We have some new blog posts coming out and feel free to follow us on Twitter @Itsautomic. Thanks for joining us.
Mark Percival 36:01
Yep, Thanks.
