Confessions of a Cloud Skeptic

When I first contemplated cloud delivery of financial ERP services, my reaction was, admittedly, highly skeptical. From my vantage point as someone responsible for both the development of the open source Kuali Financials product as well as local customization and deployment at my institution, I couldn’t help wondering whether the people pouring and drinking the Kool-Aid had ever actually developed or supported an enterprise system as complex, mission-­critical, and integrated as an ERP. Back then, before Kuali shifted to the current professional open source model, I was working as the project manager for the Kuali Financial System product and as the enterprise financial system manager for Indiana University. I knew that every school had different policies and practices, and my local development team had coded so many customizations over the years, that I couldn’t believe that one system could possibly adapt to all those requirements. With our own local install, we could change whatever we wanted, which made us look like heroes to our users. Why would we give up that superpower?

Granted, I wasn’t completely closed-­minded, because I knew the status quo wasn’t sustainable. On-­premise customization makes all the work of upgrades the responsibility of the customer rather than the product team. Early in 2013, when I was responsible for deploying the local install for financials at my institution, we customized and replaced all but the travel and disbursement (check/ACH) functionality of our legacy systems with Kuali Financials. We’d hoped to replace the remaining pieces within a year or so following that implementation. Instead, for the next two years straight, sixty percent or more of our time was focused on just keeping up with:

• Product upgrades, especially analyzing impacts, reworking, and retesting our customizations.
• Rice upgrades.
• Infrastructure upgrades (Java, Tomcat, Oracle, etc.).
• Implementing (coding) policy or budget­-driven changes.
• Ensuring security for everything we’d coded.

That local custom coding that we had been thinking of as a superpower was turning out to be kryptonite in disguise.

It’s hardly surprising that, despite our best efforts, we weren’t delivering much business value for our institution or keeping up with our new role in the “-ilities” (high availability, usability, accessibility, and mobility). Have you ever had to talk to your boss’s boss’s boss about something like an email notification that all faculty and staff received, which contained a table in plain text with just the pipe symbol (“|”) between fields that, of course, came across completely garbled and worthless on his mobile phone? I have. Not fun. Users have been increasingly disappointed in local ERP, having developed their expectations of functionality and UI based on cloud services like Amazon and Mint that are attractive, intuitive, mobile-­friendly, and available 24×7. These products, however, have design teams and a well-coordinated development process. My local development team did the best we could, but the evolution of the industry was increasingly exposing the failure of the development model available to us at the time.

So, while alternating between local meetings about competing priorities and all of the things that we weren’t getting done and Kuali meetings about the new professional open source model and SaaS hosting, I really started wondering whether we could do better. How might financials in the cloud work? Could the cloud really accommodate my and other institutions’ unique needs?

• What if, instead of hand­-coding customizations, we could simply configure the system to do most of what we need it to do and, in the cases where we’d need something more, leverage APIs to extend the functionality of the system?
• What if we could add value for our users at a fraction of the cost (and headaches)?
• What if those all­-consuming upgrades from the product team could become as simple as periodic updates to API calls, like a library upgrade? (That wouldn’t be even vaguely comparable to the scale of constantly striving to just keep up that we we’d been dealing with.)
• What if those changes were being delivered to users on a weekly, or even daily, basis, instead of once every six months to two years?
• What if the vendor had to take on responsibility for infrastructure changes and ensure security and all the various “­ilities”?
• What if all of this could be done in a way that simplifies this overly complex system?

As part of my work with Kuali, I did some careful research and consideration on cloud computing. Over the course of several months, I investigated current cloud offerings, spoke with people involved in delivering them, and learned about how implementers had customized Kuali Financials to date. There was no magical moment where my perspective shifted, unless you consider working through each point of skepticism magical. What can I say? I don’t like Kool-Aid.

I may not like Kool-Aid, but what I found speaks for itself. I’m now working as the product manager for the new professional open source Kuali Financials. Ultimately, when it comes to institution-specific customization, I realized that there really aren’t any technical limitations that result from shifting from on-­premise code customization to SaaS configuration and API usage. On the contrary, shifting to a configurable product with APIs could drastically improve local teams’ ability to roll out and upgrade value-added extensions to core financials and empower their stakeholders to do the same. Extensions could be developed on top of stable APIs and upgraded/replaced independent of each other with reduced QA effort. Configuration and APIs shift the burden of upgrades to the product team, including ensuring that the product works for all configuration options and keeping APIs stable over time. And, configuration and APIs provide a much cleaner separation of concerns.

Workday has made some admirable strides in proving that cloud delivery works. They have frankly done a great job educating the higher ed community, which is not always quick to embrace new technology. However, solutions built by education and for education simply fit better and deliver more value than trying to force fit corporate products. That has been a core belief from the beginning. We can and are doing better.

So, what about functional limitations? In terms of existing implementations of Kuali Financials, I made two key observations pertaining to the potential to move from customization to configuration.

1. Many people did the same things, in a number of cases as many as six institutions. Clearly in those cases, critical functionality is missing from the product.

2. There are very clear themes that identify what needs to be configurable. Identifying those themes enabled me to consider how each could be addressed. In doing so, I realized that Kuali has already solved many of those problems in different contexts.

I used to think that all the customizations that we’d each coded at our various institutions were for such unique needs, but as I looked closer at what everyone was doing, rather than discovering that the vast majority of customizations were outliers, I realized they were all really similar and could be simplified. Honestly, we are still searching for the outliers.

Once I satisfied my concerns about supporting institution-specific needs in the cloud, other economies of scale associated with this approach became blatantly obvious.

• Allowing the vendor to keep up on the latest and greatest with regards to regulations and security.
• Significantly reducing the effort to react to product changes by leveraging APIs and configuration to accommodate unique institutional needs.
• Eliminating the need for massive upgrade efforts in favor of continuous deployment.
• Pushing the cost of managing core, mission-critical software to a vendor hosting the product for many institutions.
• Developing best practices, streamlining business processes, and improving efficiencies through collaboration with the vendor and the broader cloud community.
• Alleviating the burden on local technical staff to allow them to focus on adding real value for the institution.
• Giving the vendor responsibility for high availability of services as well as disaster recovery.
• Leveraging the cloud product for basic reporting and insight, so that local IT staff can focus on high-­value, university-­wide business intelligence.

This is exciting stuff with real potential to change an increasingly dire situation for many higher ed institutions that want a simpler approach to great functionality. And they really don’t want vendor lock-in. The bottom line is that an institution doesn’t need to run Kuali code locally, customizing it and dealing with the resulting synchronization headaches, in order to retain unique business processes. Going to the cloud not only takes care of that, it frees up their IT team to do more.

My thinking on all of this is still evolving. I’d love to hear your ideas and about your experiences.

‍