More than 10 years ago, in December 2010, the U.S. chief information officer, Vivek Kundra, wrapped up 18 months of intense research, studies, and consultations with public sector IT leaders and issued a report with a hard-hitting conclusion: the government was wasting millions of dollars by building its own infrastructure and applications instead of using what he called the “light, shared-services technology” that was increasingly available. Why? he asked.
Why wasn’t the federal government taking advantage of the cloud?
The public cloud was far more economical for storing and processing data—and hosting applications—than building more data centers. Plus, it had other advantages, Kundra said, in “A 25 Point Implementation Plan to Reform Federal IT Management.” So started the federal government's journey of “cloud-first” operations: to move as much IT functionality to the cloud as possible—both infrastructure and applications.
Over the years, this initiative has taken on various guises and names. The current directive, issued in 2019, “Cloud Smart,” offers practical implementation guidance for government missions to fully actualize the promise and potential of cloud-based technologies while ensuring thoughtful execution that incorporates practical realities. One of the most notable recent federal cloud contracts has been for the Department of Defense (DOD) Joint Enterprise Defense Infrastructure (JEDI). JEDI is intended to be a $10 billion DOD-wide system capable of supporting “unclassified,” “secret,” and “top secret” requirements. It was awarded to Microsoft for Azure.
Implications for the federal government’s accelerating adoption of RPA
What does this move to the cloud mean for the accelerating demand for Robotic Process Automation (RPA) by federal agencies? Plenty.
The federal government is, to put it mildly, increasingly bullish for RPA. The recent “State of Federal RPA Report” assessed 23 agency RPA programs and found that the number of automation increased by 110% between 2019 and 2020 alone. Hours saved by RPA rose 195%. And the maturity of the RPA programs increased by 70%. RPA was even a line item in the Budget of the United States for Fiscal Year 2020, called out in a box to stress its critical nature. This insertion into the budget followed a call to action in the President’s 2018 Management Agenda to shift employees from low-value to higher-valued work. Earlier this year, the Federal RPA Community of Practice released an RPA Playbook cataloging automation best practices in a way that government agencies new to RPA could use to accelerate the adoption of RPA.
But what happens when RPA and the cloud meet? There are many ways this can play out. RPA application vendors can deliver any one of many different cloud “flavors” of their solutions and still call them “cloud applications.” But beware: there’s really only one flavor of cloud-based RPA—cloud-native RPA—that takes full advantage of the cloud. Consider these flavors.
This involved starting with an on-premises app and making tweaks to it so that it works similarly to a cloud product. These cloud-compatible solutions are adaptations of legacy versions; the code and data are still based on a monolithic architecture. This means long downtimes when product updates need to happen, slower and fewer update and product enhancement cycles, and a lack of scalability. Many RPA solutions fall into this category.
This typically means that the application was initially developed for on-premises deployment and has been “lifted and shifted” from physical servers and migrated onto cloud-based ones to make it accessible through a web browser. They typically have some level of cloud integration, but it is limited. Although physical servers no longer need to be managed, system updates, integrations, and maintenance require significant IT involvement and overhead. Most RPA solutions that claim to be “cloud-based” are really just cloud-washed.
This type of application requires creating a completely new architecture design and software development strategy to take full advantage of all that the cloud has to offer. Delivering a real cloud-native application, especially at the sophisticated level that RPA requires, is not easy. A cloud-native approach typically leverages the following components:
- Containerization—This is when developers package up software code with all its dependencies to run consistently on any infrastructure. Because each “container” is abstracted away from the host operating system, it can run across any platform or cloud, allowing developers to create and deploy applications faster and more securely.
- Microservices—This is an architectural style that structures an application as a collection of services that are loosely coupled, independently deployable, and organized around business functions. A microservices architecture allows developers to rapidly and reliably produce large complex applications and evolve their existing application portfolio.
- Continuous development/continuous delivery (CI/CD)—This is a developmental process in which rather than creating software in one large batch, it is broken up into small batches, allowing code to be delivered to customers as soon as it is tested in a continuous flow.
Benefits of cloud-native architecture for RPA
Modernizing apps by moving to a cloud-native architecture is not just an RPA thing. Here are some of the benefits for the RPA market in particular.
- Scale easily—Containerized microservices architecture allows organizations to rapidly scale up or scale down their software robots (“bots”) as demand fluctuates.
- Optimize resources—Since containerized microservices can each be scaled up independently, they use fewer IT resources than traditional monolithic architectures.
- Improve and enhance RPA software—With a cloud-native RPA solution, the vendor can add additional features and capabilities faster with the loosely coupled microservices architecture. This allows vendors to deliver the latest RPA innovations more quickly, giving enterprise customers a competitive advantage.
- Resolve issues faster—With a microservices architecture, it is easy to isolate and identify the root causes of problems. The CI/CD development process also allows for quick fixes for any microservice that needs attention, allowing for much faster resolution of issues than a traditional or cloud-washed RPA architecture.
- Manage updates seamlessly—Because RPA vendors can update and patch their software in the cloud, it’s virtually invisible to enterprise customers, who formerly had to manually install the upgrades and patches themselves.
In summary: buyer-beware versus buyer-gains-cloud-benefits
Federal agencies are beginning to get savvier about seeking cloud-native apps in general. With RPA, however, there’s just one cloud-native option: Anywhere 360. Naturally, the rest are trying to catch up. They’re offered cloud-compatible or cloud-washed versions of their on-premises RPA software while they work on getting cloud-native ones ready. But the fact remains, enterprises that invest in anything but cloud-native at this point are piling up technical debt. They’re investing in old technology that—sooner or later—will have to be replaced. That is painful. Even if upgrading your existing RPA vendor’s current offering to their cloud-native one, it won't be easy. This might be the time to consider a switch to a different platform—one that is far ahead in the app modernization game.