While all three of these approaches have proved valuable in addressing business pain on the surface, these strategies have also failed to address the true root cause (business / IT wedge) and in many cases have only exasperated the problem by overlooking it altogether as vendors continue sell the business “ready to go” applications to help remove their dependence from IT. It’s almost as if organizations are looking externally to companies for quick app functionality much like we look to the app store to fill small pockets of functionality in our daily lives. In our personal life as in business, these apps offer quick ways to fill gaps / add new functionality but unfortunately often act in their own silos and don’t typically integrate or automate with other apps.
All that said, when it comes to RPA, approach #3 above has the best opportunity to address the root cause here but only if we realign our expectations about who (people) and how (process) and what (technology) we leverage to support those low-code / no-code platforms
The argument here is not against low code/no code development platforms, quite the opposite. Low/No Code development is exactly where we need to continue to focus when it comes to filling the need for speed and agility in software development. But as things stand now and into the future, selling these platforms to the business under the false pretense of increased speed and IT independence contributes further to this IT / Business wedge and has proven to directly impact an organization’s time to scale for RPA.
This need for speed and agility in technology is not an IT problem despite what you may hear. Whatever the technology, CRM or RPA or ERP, no matter how “simple” they may look or actually be, if you want disruption, if you want enterprise transformation, if you want scale… you have to address all three change elements (people, process and technology) to make it work. A recent study by McKinsey & Company finds that “successful automation efforts tend to involve IT early.”
Yes, cliché but accurate and look no further than Amazon who delivers a new software to production every 11.6 seconds. If that’s not speed and agility, I don’t know what is and not a result achieved by giving “the business” low code development tools (reference Dev Ops article). Instead, Amazon has addressed the cause by reengineering who they hire (people) and how they develop software (process) supported by updated SDLC methodologies (Design Thinking and Agile) and what new technologies (Low/No Code and DevOps) they use to be able to deliver @ speed with flexibility in a collaborative IT and Business environment. A cause vs symptom approach to removing the traditional wedge many organizations still deal with hindering them from achieving this new world order of rapid and collaborative application development.
So, if ease of use platforms for the business is just providing a short-term fix for the business, how should we think about this instead? Thankfully, as vendors have pushed their development teams to provide an ease of use platform, what this has done is created a better development tool for IT. In other words, while adapting their solutions to be more “business friendly” the biggest beneficiaries are not going to be the intended recipients of this approach but rather the IT developers themselves. That’s right, by building tools for the business, a more popular biproduct of this approach has created a faster way for IT to develop software. In addition to these low code / no code platforms driving development speed, we continue to see the rebirth of once hip software development methodologies like Agile, Dev Ops, and Design Thinking… upgrades in the processes and technology that supports software development to further enhance the speed, flexibility but more importantly are all centered around this idea of collaborative development. Check out these companies as an example of exemplifying the possibilities of DevOps.
About the author