The truth about transformation - the view from Pega's VP digital automation and robotics

Profile picture for user gonzodaddy By Den Howlett October 22, 2020
The pandemic has exposed just how fragile and broken enterprise business processes really are. RPA was supposed to solve that and it didn't. Can low-code/no-code? It's a complex but useful discussion. Buckle up folks.

Restaurant automation service concept robot waiter serving bottles and wine glass © Besjunior - Shutterstock
(© Besjunior - Shutterstock)

I recently spoke with Francis Carden, VP of digital automation and robotics at Pega. It was a lively and animated conversation in which we discussed where we're at in terms of robotic process automation (RPA) and the much-vaunted but almost always missing outcomes of digital transformation. It's a conversation some will find disturbing because at its heart we're trying to understand what is driving continued interest in RPA while the digital transformation moniker continues to be plastered on (almost) every enterprise software pitch. 

In my view much of this comes down to the reality that the dream of integrated end to end processes as originally promised in the early 1990s with SAP R/3 but also aped by other vendors never truly materialized. If you buy into that you then understand why IT investments never showed through ont ofinancial results in any material way. 

In order for that end-to-end dream to be reality, you'd have to believe that all systems are capable of talking to one another in a seamless fashion. That doesn't happen in the real world and when it does, it's often and quite rightly seen as incredibly difficult, hugely expensive and of limited value. And that's largely because of the following: 

Processes exist in all kinds of database and in all kinds of code including UIs and disparate applications. It's also a fact that the last 20 years have seen an explosion of technology. In the RPA world alone, there are literally hundreds of offerings. So the enterprise software market is both expanding and fragmented. And nothing talks natively to anything else. It is one of the unique characteristics of software that two different developers working on the same codeline can build applications that on the surface look similar but are in fact different. So what you have are landscapes that are a spaghetti soup of whatever has been bought, used and maintained over a 20-30 year period. Analyst Josh Greenbaum calls this extreme heterogeneity arguing that:

The generalist in me cringes every time I see product pitches that dive deep into feature/functionality without paying attention to the larger context of how products have to become part of a holistic system. There’s an aphorism that calls out this problem aptly, and it’s one I’ve been using for years: The biggest mistake enterprise software vendors make is to sell products the way they build them, not the way they’re consumed. In other words, vendors fail to pay attention to the reality of the software acquisition process – which is chaotic, irrational, and prone to almost whimsical decision-making, and all too often not about deep feature/functionality  –  and instead focus on what they think or wish would be the case with the highly-engineered products they develop.

It's a topic we're slated to discuss - soon.

It should therefore be no surprise that on the one hand, IT has to spend an outsized amount of its budget keeping the edifice upright while the business rightly asks why. 

Then around 2012, along comes RPA, aided and abetted by certain analyst firms, who were suckered into believing they'd seen the Second Coming but which as most vendors will quietly admit, is really screen scraping UIs. The promise of automation, pitched as a way of removing inefficiencies using RPA looked good. It was also pitched as relatively easy. Business users loved the idea and, as Carden says:

When you call it screen scraping or desktop automation people go meh and IT giggles. When the word 'robotic' was applied, their eyes lit up, But here's the point - and I've sold this stuff since around 2006, I always, always say, it's a stop gap. It's a Band-Aid. It's not going to solve your underlying problems. Sadly, some buyers see it as a long-term stop gap.

In terms that buyers will understand, RPA made promises its technology could not keep. While promising that bots would be a cure-all, it turned out that wasn't the case. Instead of eliminating manual processes and tasks, much of what we've seen was really augmented manual processes. There were wins for sure but they were transient. And then along came the pandemic. 

In my view, the pandemic has exposed just how badly broken and outdated many of the processes that we assumed would work for all time really are. The reasons for this are not entirely clear but my sense is that accumulated technology, sometimes with the oversight of IT that has concerns about governance, security and the like never worked the way it was originally intended. I have often said that insistence on using the term 'best practices' when referring to implementation of enterprise apps is a rear-view mirror approach. What I should have added is ...and no-one really does it even when implemented. Processing mining has exposed that fallacy.

So if you're papering over the cracks then the answer must surely be a reset, a replatforming of some sort? But then who wants to do that? Over to Carden:

And that, I think, is the dichotomy because everybody still believes today that's impossible. The reason RPA is so successful is because it's a quick Band-Aid. And that's okay, because anything else is exponentially years away. But it's not OK. 

Phil Fersht, CEO HfS Research claims that:

When the fog clears in the coming weeks, we're faced with rebuilding workforces, rethinking failed political ideals,  revamping education and healthcare systems,  re-energizing ourselves, our families, our attitudes towards diversity, our own health, how we work… and so much more.  While we are all weary of living a real-life Groundhog Day, we have to stay focused, motivated, healthy and prepared to be ready for a new era that is approaching.   Surely this will represent the biggest reset in modern history.

There is no place to hide anymore. We are the dawn of a Hyperconnected Economy with the advent of connected global talent and the infinite possibilities of processes and data running in the cloud.

He's right but then what's the real cure? Is there one? I'm not going to assign blame but now is a good time for IT and the business to come to a mutual understanding. ASUG's Geoff Scott says:

We need to let the users inside the gated walls of the IT department, grant them a seat at IT's table (yes, you read that right), and take advantage of new methodologies and tools to deliver software with greater speed and transparency.

Because, at the end of the day, aren't we all tech professionals now?

Really? Scott's argument rests in part on the rise of the low-code/no-code movement, a topic that is close to Carden's heart. 

We have got to stop writing code and build applications. The low-code/no-code movement is rapidly changing the way people think about building software, not writing applications, but building applications in a way where you never hard code the business logic into the app, the UI or the back end. You don't need to do that anymore. And people that jump onto that movement build applications not only quicker, much quicker and, what you end up with is something that never needs to be customised ever, but can be configured for ever and evolve for ever. A business process is a business process, it shouldn't matter what the UI is, it shouldn't matter what the back end is, it shouldn't matter what the database is and low-code/no-code enables that. Conceptually, we should not be living in an era where business and enterprises need to be deciding what hardware and platforms they want to run on. It should be inherent in the platform you build your applications on.

A powerful argument? You bet because in Carden's argument, much of the basic application building cost is removed as a constraint to achieving timely outcomes, something that matters in a pandemic. So not only is low-code/no-code faster to deploy but it is exponentially less costly than traditional ways of delivering applications. Does that mean we'll be replacing the SAP's, Oracle's Salesforce's of the world anytime soon? No - of course not. But in order to get value across processes and responding to broken processes, we will have to think differently, 

My take

This all sounds wonderful and I get where Carden is coming from.

Viewed objectively, you can see how the history of IT development informs the current fashion for low-code/no-code. But I don't think it's that easy and it shouldn't be. Carden will likely agree and that's why low-code/no-code platforms need approaching with a degree of caution. IT wants to ensure that whatever citizen developers are doing that they are compliant and secure. But there's more and here it's useful to quote Martha Lane-Fox from a story by Stuart Lauchlan titled Martha Lane Fox - why technology has to be at the heart of the post-COVID recovery:

If we could take the entire British establishment and dump it in a better level of digital understanding, we would be light years ahead of where we are. If we don’t build our society and our economy for 2030 rather than for 1820, which we sometimes tend to do, then I don’t think we’re going to have the best shot at the future.

And therein lies the rub.

As someone who attempts to explain technical work to non-technical people on a regular basis (and I'm not super technical by any stretch), the difficulties in just getting heads around the language that developers use, the conventions with which they're familiar but which are, as Scott rightly characterizes 'mysterious' makes for an education gap that cannot be solved by simply showing users a flashy UI or whizzy workflow builder.

Working with low-code/no-code tools like IFTTT and Zapier is sometimes perplexing although potentially rewarding. I know the frustrations of not being sure or outright confused as to why a specific connector doesn't do what you think it does and then finding you really need a native connector because the API in question hasn't been used correctly in the templated use case. 

I often hear the term 'digital native' when what is really meant is someone who uses technology not someone who understands its capabilities.

So while I am hopeful that the message Carden and others in the low-code/co-code camp are putting out, there is a ways to go and even then I wonder whether we will truly get outsized value from technology investments. For me, the acid test comes when a buyer says that they not only solved X problem but also solved a gazillion problems that resulted in direct impact on both top and bottom lines. And, I see the evidence for that both in financial statements and in earnings calls. Now that would be different.