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:
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?
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.
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.