Automation Fabrics and Business Process Efficiency with Charles Crouchman

This is Textron tv. Hey guys, thanks for the throw. We're here with Charles Crosman, who's chief product officer for Redwood Software.

And we're talking about, well, the rise of automation frameworks. Charles, welcome to show. Thank you.

We've been automating things as long as anybody can remember, but I feel like, um, we wind up, uh, all these islands of automation. They're kind of isolated from one another, and then we kind of try to hand things off and things break, and we wonder why. Um, so what exactly is an automation framework and how does it fit into that context?

Yeah, that's exactly right. So what happens is over time is you introduce new applications or new platforms in your business. So you might introduce an ERP system like SAP or you might move from on-premise systems to public cloud systems.

Every time you make a change, introduce a new platform or application, you tend to go out and buy a new automation product to automate that thing, automate the cloud, automate your virtualization environment, automate your SAP environment. And what this leads to is, as you mentioned, islands of automation. So you've got little pieces of automation for each platform or each application across all of your IT infrastructure.

Now the problem with that is there, there are a number of problems with that. So the first one is, um, business processes or even IT processes don't live in a single system. They cross multiple systems.

So a typical, if you're a large bank, for example, large financial institution, a single, a single process might start on the mainframe, move through some of your on-premise infrastructure out to the public cloud across multiple applications, both homegrown as well as commercial and or SaaS applications from beginning to end. And if your automation is spread across all different platforms for each, for each one of these steps, you don't have an end-to-end process automation, right? You've effectively got to do all kinds of manual work or, or, uh, custom integration between all these solutions on your own.

So the idea of an automation fabric is something that either replaces all of these islands of automation or orchestrates them, the ones that exist or some combination thereof, so that you can get end-to-end process automation across all of your disparate applications, whether homegrown or or commercial, on premise or SaaS. And across all of your platforms, whether it can traditional on-prem platforms or public cloud platforms. Well, I don't think most people are gonna be able to rip and replace a lot of their existing automation.

So how do I orchestrate all that into some sort of meaningful way to create that and then process? 'cause I think, you know, you hear about it every day, every customer has some experience with somebody who says, I have visibility into this, but I can't see into that, so we'll call you back. Right?

Right. That's right. So, so, so this idea of orchestrating what you've already got is incredibly important.

You have to be able to both automate anything new that comes in that's not al not already automated. Sometimes you replace existing things that are coming to their end of life, or they're doing consolidation or replacing vendors. But in many, many cases, you have to effectively orchestrate across things that are already there and already implemented, as you mentioned, that they don't wanna rip and replace.

So effectively what you need, the, there are really three main components to an automation fabric. The core of it's an orchestration engine, so a workflow engine that knows how to build, uh, complex workflows, but ideally in a low code, no code fashion so that, you know, you don't need to be an expert coder in order to build these automations, right? You've got visual designers and now emerging things like, uh, AI copilots to help you build these automation automated workflows.

So that's the first part, the second part of the library of connectors. So you have to be able to, this workflow engine has to be able to talk to all of these backend systems, typically through, uh, APIs that they've developed. Most, most systems now have APIs where they don't, you have to deploy agents that know how to kind of talk to these systems without APIs.

So you need a robust library of these connectors to all the existing systems, again, for everything from traditional mainframes to public cloud, from, from SaaS applications to homegrown applications to open source systems and everything in between. So you need a robust library of connectors. And the third thing, the third thing you need is this, again, this low-code, no-code design experience.

If you're, if you're, if in order to make this work, if you have to bring in developers who know how to write Java code, for example, you're never gonna get there. You need to have, you need to bring the skill level required to build these automations down to what we call citizen developers, non coders through a low-code, no-code interface, typically a visual designer and, or now an AI copilot. And then the last thing you need, and this should not be overlooked, is an observability layer.

So the key to adoption of automation is trust. I mean, if you think about an analogy of something like, um, autonomous vehicles, right? So autonomous vehicles we're gonna be, have been on the verge of being fully autonomous next year for the last 10 years.

It hasn't happened yet because it takes time to build out this full autonomous capability. But more important than building of the technology, it takes time to build trust in the automation. So people, humans, you've got early adopters who are gonna be the first one in these auto autonomous vehicles who are gonna be comfortable taking their hands off their wheel and their feet off the pedals.

But you've got the mass market, which is waiting for those early adopters to kind of work out the wrinkles for the technology to evolve before, before they adopt. It's really the same with automation. So in the same way that with the autonomous vehicles in version one, they don't take the steering wheel and the pedals out of the car.

You still have to have human override. You still have dials in, in to tell you what your speed is. You can still see the GPS system in an, in an automation system.

You still need that set of manual controls so that humans can override the system when they feel they need to. But also an observability layer, like the dials, like the dials in the GPS that tell you what's going on, what's succeeding, what's failing if something fails, how do I diagnose the root cause, correct it and carry on. So you need all of those components as part of a, as part of an automation fabric.

Will AI further democratize that? Because I may not even need to know how to make the low code thing. I'll just describe what it is.

I wanted a natural language interface and something building. Yep, yep. So, so now we're talking, we're, we're, so there's, there's, when, when you're talking about the evolution of ai, you kinda have to talk again, like I mentioned with autonomous vehicles about timeframes, right?

When is it going to be at level one, level two, level three, level four, level five. And it was very difficult to predict with ai, because it's evolving so quickly. Now, our, our, our intuition is then to say next year, we'll no longer need developers because ai, ai, AI will be able to write all the code itself.

That's probably an overambitious prediction. But in the, in a five to 10 year timeframe, you can see many of the, of the tasks that are done by to, by traditional coders being done by AI systems. I'm not, I I can't predict exactly what that timeframe looks like.

I don't think anyone can, anybody who tells you they know is probably, uh, is probably overselling their kick, their, their knowledge as it relates to automation. AI is going to have a dramatic effect on automation the same way as it does in everything else in a few ways. So remember those components that I spoke to you about?

So first of all is, is the, uh, orchestration engine or the workflow engine. So AI is evolving to be able to, um, manage complex orchestrations. It really can't today.

It can do things like task lists like, like, uh, serial task lists and some decision trees, but not which you would, the complexity of what you would do with a traditional workflow engine, potentially hundreds or even thousands of decision points and branches and merges and loops and all that kind of crazy stuff. So it's not there yet, but it will be, and it'll, and, and it will be eventually be able to create those workflows, either pro partially based on human language prompts, but probably mostly based on ingesting data that describes those processes and then turning it into automated workflows, right? Um, so over time, yes.

Today, no, not yet. Um, the, the creation of the automation, like I said, if it can automate, for example, a process document, it can maybe created, uh, uh, an automated workflow from that a hundred percent in time. Um, the integrations are things that people are building.

So you hear about an ag agentic AI all the time, uh, and this is really, uh, individual companies effectively taking, uh, building, taking the APIs for their existing systems and teaching an AI system how to talk to their system so that they can be automated by an AI system. Those, uh, those, those, those AI agents are not being automatically generated by ai. They're being created by the companies that own the systems that they're being integrated to.

But over time, a, a wide library of these agentic of these AI agents will be available and many systems will be automated and orchestrated by ai. Uh, as an example, what AI doesn't have yet, and again, this may come, remember the last part that I spoke about, which is the observability layer, right? So it doesn't, so, so there are really three things that have to be addressed.

It has to be deterministic, meaning for a set of inputs, you have to be able to predict the outputs. And that's one of the issues with AI today, right? It's not deterministic.

You can ask it the same question twice and get a different answer each time. Now, if you're only using AI to help you as a writing assistant, that's fine. But if you're asking AI to run an automated process to, to close your, close your books at the end of the quarter, you have to know that it's not gonna make any mistakes or have any hallucinations.

So that's something that has to be corrected over time. The second is, um, is it has to be transparent. So, so you, in order for you to come to trust an automation system, again, you have to, has to be deterministic, but you also have to be able to observe how it does its work in order to build that trust.

And then someday, maybe you trust the black box, but you don't trust the black box right away. And then the third one is, is again, it has to have that observability layer. So it, there has to be the ability for humans to intervene and take control and or supplement the system.

Uh, and those aren't available yet in the ai. So over time, these thing capabilities will be, will, will become more available in gen generative AI systems, uh, and the, and the traditional automation systems, and these AI systems will merge. Uh, but, but again, that's, that's a multi-year, uh, process.

That's not next, next week, next month, and next year. Do we need to revisit the processes we're trying to automate? And I ask this question because as we enter, the age of ai seems to me, uh, when I look at a lot of this stuff, there's more exceptions than there are rules.

And the exceptions have evolved over the years, and they were meaningful at some point, but maybe we need to kind rewrite the rules. Yeah, I mean, we see this all the time, which is we go into a, a very large corporation that's been around for decades, if not hundreds of years, and they've accumulated over the time, over, over that period of time, many, many, many systems record, right? And some of those, they continue to operate, but nobody really knows how they work or why they do the things they do.

All they know is it does what's necessary. Um, and so there's an arcane set of rules that nobody wants to touch, because if you pull on one thread, the whole thing might come un unraveled, right? So that's one problem with, uh, with dealing with traditional or legacy systems.

But when you're creating new automation, as you're, if you're, as you're implementing new applications, new platforms, and you're building new automation, you, you hit on an an important thing. This has nothing to do with the technology. This is just kind of process or philosophy, which is simpler is always better, right?

We learned this in the, in the days of ERP. You see this in the evolution of ERP systems, the original, uh, implementation of ERP systems. They took the ERP system and they massively customized it to fit their own, their, their custom processes.

And they realized over time that the burden of carrying forward all those customizations from year to year, from release to release, from system to system was very heavy. Where the, the modern approach to implementing ERP systems is really to adopt your processes to the system, to, to simplify, to not create all this customization. And so, you're absolutely right.

Lightweight is better. Doesn't mean that the need for automation goes away, but you shouldn't overcomplicate it. You should do, you should do the minimum required to get the job done, uh, and not overcomplicate it with all kinds of exceptions and custom processes and roles as much as possible.

So adopt your processes, simplify your processes as part of the automation, rather than taking complex processes and simply reflecting them in automation roles, if that makes sense. It does. Do you think over time we might flatten our organizational structures as a result of AI and automation?

'cause when I look across these, uh, companies, there's all these silos, marketing, sales, manufacturing, and yet they're not really aligned around delivering some end result. They're just kind of aligned around a set of vertical tasks and processes that, uh, somebody stitches together manually at the end of the day. So, are we gonna have a moment here where maybe somebody wakes up and just says, you know, the way organizations are aligned needs to change.

So, so this isn't a technology answer, this is more of a kind of a philosophical question. I'm happy to answer it. So, so my perspective is this, the most complex machine in existence is the human.

And, and the most complex interface between two machines is a human to human interface, because it's not deterministic, right? You know, we're governed by emotions and desires and all these things. And so when you see the complexity of interoperation between organizations, it's because interoperation between humans is difficult and messy right now.

So the more that these things get automated by computers, those interfaces get simpler and more deterministic. And you'll see integration across silos, as you mentioned, right? Because computers know how to talk to each other pretty well, pretty easily.

Now, again, I'm not advocating for nor predicting that humans will be replaced by computers and all these organizations, they will be supplemented by ai for sure, for certain. So the more that you, the more that you reflect your business processes in software and computer code, the more integrated they can become, the less reliant you are on humans, which are the most complex interfaces between, between machines. If you wanna allow, allow me to call com humans, machines, uh, you'll simplify and start, start to solve that problem.

You wanna eliminate it, but you'll, you'll start to simplify it, right? A lot of these organizational issues are, are really the root, the root of how humans collaborate with each other. It's a messy, difficult thing, always will be.

So computers collaborate with each other extremely well. So the more that you can, um, put your processes into software and automate these things, the, the better results you'll have in that regard. Again, not replacing humans, but supplementing them.

So what's the one thing you see organizations doing as they attempt to automate things that you kind of shake your head and go, folks, we need to be a little bit savvier about what we're doing here. Yeah, so, uh, probably the number one problem is the one we started with, which is the islands of automation. They've accumulated systems over time, particularly large companies that have existed for decades if not hundreds of years.

Over that period of time. They've accumulated, uh, an incredibly diverse set of systems and incredibly different diverse set of platforms, applications and automation, islands of automation. And, and to your point around silos, they've got the ability, as I mentioned, to integrate all of this through software, but they haven't done it.

So they've got all the traditional problems of silos, uh, but they've got the ability to eliminate those silos through automation fabrics, through integrating these things across all of those islands. They just haven't done it right. Um, and it's the traditional ROI conversation, which is to say there's some upfront effort required to do that, but it'll pay for itself incredibly quickly.

And over a three year, it'll probably pay for itself three x, right? But you have to take that upfront effort in order to get the long-term benefits. Alright, folks, you heard in here they say the definition of insanity is doing the same thing over again and expecting a different result.

Well, right. If you think about that in the age of ai, just how crazy might we be? Hey Charles, thanks a shot.

My pleasure. Thank you. Back to you guys in the studio.