Moving technologies and services to the cloud has financial implications for institutions of higher education.
This transition may include a shift from capital to operating expenses, changes in implementation and migration costs, new staffing requirements, and the urgent need to communicate changes across the enterprise.
Two case studies illustrate how Centre College and the University of Arkansas at Little Rock included costing and funding considerations in their cloud strategies.
[This article is the second in a series that presents case studies related to important themes within enterprise IT.
- Developing Institutional Cloud Strategies
- The Impact of Cloud Implementations on Budget Strategies
- The Dean’s Information Challenge: From Data to Dashboard
- Cloud Migrations: An Opportunity for Institutional Collaboration
Each article in the series begins with a scenario that provides context for the theme, followed by several case studies.]
EDUCAUSE research shows that most institutions have already moved some of their technologies and services to the cloud.1 This transition has financial implications that may include a shift from the use of capital to operating expenses, a change in implementation and migration costs, different resource requirements for staffing, and the need to communicate these financial changes clearly across the enterprise. This article describes how two institutions have included costing and funding considerations in their overall cloud strategies.
Sara, our hypothetical CIO, has put together a sourcing strategy that aims to be a cloud-first plan as much as possible. She realizes, though, that her budget isn't set up to support this change in focus, and neither are the budgets in the functional units within her institution. The budgets use capital funds for large, one-time purchases of enterprise systems, and she anticipates a need for continuous operational funds to pay for cloud-based subscription services. New funding models will need to accommodate changes in implementation costs associated with enterprise projects, as well.
Sara realizes that transitioning to the cloud will take several years, so her budget needs to evolve over those years. She also realizes she will need to communicate to her stakeholders that they will be in a transition phase for a while.
Her institution is committed to the cloud strategy in principle, but she isn't sure how to implement it with the older funding model in place.
J. Keith Fowlkes, Chief Information Officer
With the evolution and broadening adoption of cloud computing in higher education, many colleges and universities are seeing a bigger picture question to answer. Centre College has had several hosted cloud-based services for a while, but smaller institutions have been slower to adopt the cloud for administrative systems, and for good reason.
Before moving to the cloud for enterprise resource planning (ERP) operations, many institutions have found that they need to reevaluate their ERP platforms to insure they are strong enough for the institution's long-term needs. Some private institutions such as Centre College have had their ERP solution for years. Considering moving to cloud operations presents an opportunity to look into the overall performance, feature set, and costs related to administrative and student systems.
Over the past three years, we have evaluated several different scenarios related to our campus ERP. Centre's current solution has been in place for over 25 years and has proven to be relatively solid. As with many legacy solutions, our campus has become dependent on custom modifications to the software, and our campus programmers have become experts at customizing the software to the unique needs of the institution. This ability to customize our systems is both a blessing and a curse given that we have to pull these customizations along with us every time we upgrade the software.
As noted, Centre has engaged several cloud-based services over the past few years. Cloud services for admissions, career services, and alumni/donor relations are fairly commonplace in higher education. As more and more of these cloud services become available, one key to success will be to successfully monitor and control the growth of these cloud-based recurring costs across campus.
Making a Business Case
Selecting a cloud product for ERP or any other functional system presents a number of dilemmas in evaluating vendor software solutions, their base design, and their performance in the cloud compared to on-premises solutions. In order to make a good decision, CIOs must make a sound business case — is moving to the cloud less expensive overall to the institution? Possibly as important is the question, does a move to the cloud give the institution an effective advantage in operations over an on-premises solution? This question could be answered using a variety of indirect costs and benefits in addition to the cost of the software — efficiency of employees, streamlining of business processes and workflows, and resources freed up for other tasks and services for students. All of these directly affect the financial bottom line of every institution.
For larger institutions, assessing the direct costs could be a bit easier given their larger costs in data center operations, specialized staffing, and equipment. With small institutions such as Centre, our overhead is much less. Smaller operational costs combined with fewer staff professionals wearing many different functional "hats" make reductions in staff extremely difficult if not impossible.
Many larger institutions have already seen benefits in the cloud for providing operational redundancy and enhancing disaster recovery capabilities, but many smaller institutions barely have the funds to do redundant backups. Many CIOs see the cloud as a way to make disaster recovery operations better for their campuses, but these additional (and required) ancillary cloud services add operational costs to their already tight budgets.
The next concern is proximity. The lingering question is, can an ERP solution perform as well in the cloud as it does on-premises? Key considerations include access speed, shared virtual systems, reliability of vendors' data centers, and telecommunications infrastructure. Many smaller private institutions are located in rural areas, which can affect the availability of reliable and redundant telecommunications services connecting campuses to their ERP systems.
Moving data center operations to the cloud introduces another budgeting challenge: the need to move capital funding to operational budgets. The most prevalent is the competition for operational funds. At small colleges and universities, operational funds generally come from student tuition, and that amount is not growing; in many cases, it is shrinking. Institutional operational funds include salaries, utilities, and building and grounds maintenance, which usually take priority over other requests. The final constraint that has plagued IT operations for years is that operational budgets usually do not grow more than 3–4 percent annually, while ERP software costs generally have been growing by 4–7 percent annually. This disparity cannibalizes other operational budget lines, leaving a hole in overall funding for other needs.
Within our small college and university consortium — the Higher Education Systems and Services (HESS) Consortium — one ERP vendor (Campus Management) is attempting to address these constraints in operational funding for moving to the cloud by offering a six-year "no maintenance increase" agreement with a consumer price index (CPI) cap after six years for consortium members. That is a step in the right direction, and we hope to see our other vendor partners move toward this type of incentive for their cloud solutions in the future.
These days are tight for everyone in higher education. I have always said that my technology operations in the past have run "lean and mean," but I identify with a wonderful term that a colleague of mine introduced to me a few years ago. She said that her operation at her school had gone from "lean and mean" to "skinny and angry." Admit it… We have all been there!
Cloud Software and Security
One major issue sometimes overlooked is vendors' various cloud-based approaches. Has the product been redesigned for the cloud? What development platform does it use, and does that platform have long-term support? Has the cloud-based software design been tested thoroughly? How many customers are using it? As many of my CIO friends will attest, there is nothing like finding out you are the second or third customer to adopt a new software solution — in the cloud or on-premises!
ERP cloud solutions in higher education today resemble traditional on-premises solutions in some ways: host-based terminals (yes, they're still out there), client-server systems, virtual terminal systems, and web-based systems. With the wide range of approaches taken by various ERP vendors, it can get pretty confusing for CIOs trying to find the right fit for their campus operations. The harder question to answer is which approaches are the most reliable, fastest, and effective for operating in the cloud. More so, which approach will predominate in the years to come?
The 800-pound elephant in the room for the cloud is security. There is substantial risk for any higher education institution putting its core data in the cloud. Smaller institutions are much more resistant to moving their ERP solutions into the cloud because most cloud providers (especially ERP vendors who use third-party data centers) will not guarantee the safety of the data that resides on their systems. It is true that no network-connected system can ever be 100 percent secure, but without better security and service-level agreements from vendors and their cloud hosting providers, smaller institutions may continue to pass on cloud-based operations. Yes, some insurance carriers will insure against liabilities incurred if a data breach occurs, but this cost and associated risk also must be factored into the overall business case for moving to the cloud.
I believe that better resting-state encryption is the key to encourage widespread cloud ERP adoption and address cloud-computing security concerns with software vendors. A host of developers including Microsoft and EMC as well as the open-source Apache Hadoop HDFS look promising — but haven't reached the sphere of confidence for many institutions. To sell their cloud-based ERP services to higher education, vendors will need to improve and give better assurances for many institutions to make the jump to the cloud. Institutions wanting to make the leap to cloud will need to move past the security concerns (with caution) and meet cloud vendors halfway. Perestroika.
I would never say that any institution's security expertise and infrastructure is or could be as good as the security of a major hosting provider such as Amazon or IBM. Many times, this is a matter of perception and level of comfort for most smaller institutions. The old "security by obscurity" principle continues to prevail at many smaller schools — guppies in a sea of whales. Is it better to be a well-armored guppy than swim with the giants in the AWS pond? Whether they are right or wrong, many think so.
APIs and the World of Systems Integration
With the exception of one major ERP vendor (Ellucian), few strong models for application programming interfaces (APIs) exist for integrating cloud-based systems and services. The result is a confusing process of moving legacy flat-file "dump/load/SFTP" database processes to a cloud-based system securely. In moving to the cloud, you remove one system management "hat" from your professional staff, who immediately get a new "hat" as cloud systems integration programmers.
In talking with functional departments, I hear great optimism in finding an "inexpensive" cloud software-as-a-service to meet some specific need. The problem is that the integration of this "inexpensive" system bares the need for hours of technology staff integration and project time to tie these systems into the institution's database of record. As the number of these inexpensive cloud solutions grows across the institution, central IT staff spend more time, energy, and money to manage and support those integrations. This would be a much less problematic situation if integration work could be replicated between cloud systems, but, sadly, that never seems to be the case. IT programmers spend lots of time learning how the different cloud systems work and devise ways to securely integrate them with the institutional database of record. Many of these "inexpensive" cloud solutions quickly turn out to be costly endeavors for the institution in the long run.
This difficulty is one that all institutions who wish to move to the cloud have to address, but with smaller institutions, API standards pose a huge challenge with integration tasks, processes, and knowledge. Many cloud providers state that they have tested API tools, but often a closer look reveals that they are less than reliable and not secure. My experience has shown that technology support people still recommend the old dump/load processes for data integration needs.
All hope is not lost for the cloud, though. The Linux Foundation's Open API Initiative is promising and could be a great starting point for many organizations looking for an API platform that is free, open source, nonproprietary, and generally secure. Unfortunately, vendors are slow to adopt open-source standards and lean to their own proprietary standards — which causes competing vendors to reject that API schema in fear that they will be subject (sooner or later) to licensing fees and restrictions.
HESS is discussing the viability of creating a truly open API standard that our ERP vendor partners would adopt when working with our member institutions. We also have discussed creating an open-source middleware solution that would help our member institutions with the complex task of managing the growing number of integration needs. In using a middleware solution with a central standard, our members would have a guide to refer to when working with integration between a cloud system and on-premises systems.
This sounds like an easy task. The project has huge implications in the future, however, with lots of upkeep and overhead. Also, the development process includes potential difficulties, with institutions using a variety of ERP and ancillary products. The best hope for an open standard is to start small and recognize our institutional similarities slowly and methodically.
Centre College has cloud-based systems integrated with our ERP now. As more and more of these cloud services are requested by various departments across the college, our strategy is fairly straightforward, based on the lessons we've learned along the way.
Reviews and Approvals: Centre is a small institution. Even so, multiple departments support its success. When departments want to add a cloud service to their operation, someone must serve as gatekeeper. In our situation, IT services are centralized, and my office must evaluate and approve any request for new cloud services, along with the college's senior staff as needed. This process should include contract management for cloud products to insure that they include integration costs, security and service-level agreements, and uptime availability metrics.
Integration: One crucial need for nearly all cloud-based services is their integration with the institutional system of record, our ERP/SIS system. This key reality allows control of reviews and approvals to some degree. We have become skeptical of vendors' claims of "turnkey integration" with our existing systems. I recommend holding discussions with departments, vendors, and your technology staff far ahead of decisions to purchase cloud solutions in order to keep integration as clean and trouble-free as possible. Also, stress to your departments that programming staff time is not free, and integration can be a costly and time-intensive task.
Project Management: As with any successful system implementation, project management is an art as much as a science. Managing expectations, limitations, and requirements is paramount. Also, with any successful system implementation, everyone must understand that all functional system projects are "partnership projects." Technology staff are vital partners, but departments need leaders who take ownership of and responsibility for the cloud service and its implementation. Without this partnership and sharing of responsibility, projects will never be completed in a way that satisfies everyone involved.
Early Adopters: Between the time we started doing research in cloud services and today, we have found that prices and standards have improved. They have not improved as much as I would like, but they are trending well. I believe, as with many newer industries, economies of scale will eventually bring pricing down for cloud services. As I shared previously, the HESS Consortium is looking at our vendor cohort-based structure as a way that institutions can come together to improve pricing while working more closely with ERP vendors on features and requirements. It is always best to find friends who are facing the same challenges.
Reliable and Redundant infrastructure: This should be obvious, but for rural institutions without multiple telecommunications providers, I recommend seriously investigating how downtime on a cloud-based system will affect your institution. If you do choose the cloud, make sure to build redundant telecommunications (network access) carriers into your budget for your planning and decision-making process.
University of Arkansas at Little Rock
John Rathje, Associate Vice Chancellor and CIO
The University of Arkansas at Little Rock (UALR) is a metropolitan research university with more than 12,000 students. It delivers higher education through flexible learning and internship opportunities. UALR is a member of the Arkansas Research and Educational Optical Network (ARE-ON), which provides commodity Internet and Internet2 connections through separate 10 gigabit Ethernet connections.
When I moved to UALR in the fall of 2015, I took a few months to assess university needs, available resources, and IT's capacity to meet the growing demand to recruit and retain students, faculty, staff, and researchers. The message was consistent:
Student Success: Increase retention and graduation rates and improve the sense of community within the student body.
Position: Improve UALR's recruiting yield for students and strengthen support for Human Resources processes to recruit, hire, and support faculty and staff.
Efficiency: Identify ways to reduce complexity, improve productivity, and manage investments in an effort to maximize available resources.
Not mentioned but high on my list of concerns were privacy and security. We needed to find ways to provide a flexible and safe computing environment. What I further learned about our environment would make the above goals difficult to manage without significant change and a willingness to consider other forms of delivery. We have concerns in the areas of:
Aging Infrastructure: Over two-thirds of the foundational infrastructure (firewall, core and edge network switches, compute, storage, controllers, access points, and telecommunications) exceeded their useful life as defined by Gartner.2 In fact, replacement parts were difficult to find for key portions of our infrastructure, and critical components of our technology were no longer eligible for warranty and maintenance contracts.
A "Legacy" ERP System: Our vendor had continued to innovate within their product portfolio, but our awareness and training around those advances had not kept pace. We needed agility, connected processes, and automated workflows.
Perception: The perception of IT on campus was poor. Our "IT-centered focus" combined with distributed and unmanaged solutions certainly contributed to the poor image. We needed to reduce our IT portfolio and adjust our workforce to become more engaged in the business side of the university.
Any plan to revitalize IT, especially in light of the Internet of Things, must anticipate the future. Solutions must embrace and provide for:
Digital Everything: We need to support data and process exchange for any portion of our enterprise and the needs of those we serve. Any user device should be allowed and introduced into a safe and secure environment.
Great User Experience: Those we serve should have access to what they need, when they need it, wherever they need it, and it must be simple and consistent. The user experience is measured by others, not by IT Services.
Leverage: We need to respect the investments already made and leverage the technology for wider use; leverage our partners more fully; and leverage our skill sets more completely. We had a fractured, heterogeneous environment. We needed to optimize our resources and time to build a better experience and a more cost-effective solution.
I am fortunate to be in a position to rethink everything about IT at UALR, from workforce organization to an infrastructure that supports agility. I expect cloud to be a key and strategic part of the plan. In a former position, I headed an effort to move our core enterprise service (HR, finance, and student administration — our ERP) out of our data center and to a managed hosting provider. For all practical purposes this represented a move to the cloud. Additionally, we moved student and alumni e-mail to the cloud. My former organization was similarly situated to UALR in overall budget-to-student ratio. The frugal IT budget required us to be creative. The staff was over-committed, yet we needed to find ways to increase the services offered. Similar to UALR, the university faced increasing pressures to recruit and retain students, faculty, and staff.
Those experiences give me confidence that moving to the cloud is a viable path for UALR. But simply moving services to the cloud is only part of the equation. Organization, process, and budgeting will also change as we transition away from a data center mode of thinking to an agile and more strategic service.
Despite confidence gained from earlier successful moves to a cloud environment, I give my full attention to moving major systems from their current home. Each prior project provided deeper insights into the things we can do better, the items we should manage more closely, and the conditions that promote success during and after the project. I recommend considering these issues carefully:
People: Although technical understanding of the environment is a must, staff will not need to perform system tasks that were once part of their day-to-day effort. Plan for your team to provide more strategic, proactive input and leverage their time to do more design and solution integration.
Costs: Obtain an understanding of the month-over-month costs associated with the complete delivery of the current solution. Not all costs are direct and easy to quantify, and in some cases the costs are not directly part of the IT budget (power consumption, for example) — but all costs affect the organization's bottom line. Use what you learn to inform your planning. Include the following costs:
Server/compute (estimating a four-year replacement cycle)
Storage (considering production, test, development), including rate of growth
Licensing/virtualization, current database management, and server operating system
Labor, from core administration to auxiliary support
Maintenance contracts associated with the solution
Backup solutions and associated needs
Disaster recovery site
Transitioning your budget model from capital expenses to operating expenses is a useful exercise. Develop budget headroom by adjusting the organization (e.g.: vacant positions returned to operating budget), optimizing the portfolio (eliminate overlap and standardize on one tool or service where possible), and identifying the costs that will go to the cloud. Note that some of this work is highly dependent on current contracts and associated exit and penalty clauses.
Risk: Consider how the cloud offering addresses business continuity and weigh that against current planning and disaster recovery investments. Understand where data is located/stored to ensure it complies with state and/or federal requirements.
Transition Management: The transition process requires that you organize it as a formal project. Any and all precautions to help you meet expectations are worth the time. Think through the classification of data and the security and privacy requirements for those data sets. Review the cutover plan, then review it again and practice it with all key personnel. Make sure everyone knows what is happening and what to expect — details in the transition plan matter.
Emotion: During the transition expect to encounter pushback and potentially changes of heart. Know why you are doing the move, the benefits to the organization, and the expected impact. Establish regular briefings (virtual meetings if necessary) with primary stakeholders (functional and technical) to help create a sense of "team" with the cloud provider.
Contract and Service Level Agreements (SLA): Identify performance, availability, and support metrics. Understand who owns each task. Depending on the cloud implementation (infrastructure-, platform-, or software-as-a-service), this might be different. Once the SLA is established (note that SLAs with SaaS offerings may be less flexible than with a managed hosting provider, for example), identify clear financial incentives for the vendor to meet the SLA. Establish timeframes that work for you — don't assume the vendor knows your business. Finally, be clear on who owns the data, where data is stored, and what lead times are required if your organization determines to go another direction at a later time. Exit strategy and conditions are important.
Process: Continual improvement should always be the goal. Review your process, data management, support, security, and system management. Refresh process maps and look at points of handoff (data, support desk, etc.) to see where you can find efficiencies.
Communication: Talk the language of the business when selling the idea of moving to a new model that requires a different method of funding. There is no substitute for a good project plan that clearly identifies responsibilities and timeframes. That plan, along with high level reasons for the move, should inform a multitier communication plan. Communicate early and consistently. Give people a chance to ask questions and engage. Invest time to talk with staff directly involved in the move — let them know how this move affects them and what other plans you have for them to contribute to the mission. Finally, make certain the support manager is involved in updating the process flow for issues relating to the new service model.
Technical Design: Ensure your environment is built to the standard you define and expect. Trust your partner to know their business and remember that you still own the delivery — ensure it is done the way you need and expect it to operate.
Integration: Understand both the technical and procedural integrations. Moving sensitive data from one facility to another or from a new cloud model to traditional solutions may require changes to authentication, firewall and/or VPN rules, and software interfaces. Integration between support desks and ticketing systems might also be necessary depending on your service and support framework.
Support: Stay on point to ensure the first few days, weeks, and months go as planned. Give key users and stakeholders direct access to the integration team to address concerns quickly.
Proof of Concept: For subscription services in the cloud, pilot something simple for a few months to learn more about provisioning service and how that vendor's pricing model works. This will help build understanding of the service and how you might reduce costs for services that are not 24/7 (test and development systems, for instance).
Policies: Review policies for any needed updates dealing with data and the security around the data. While most acceptable use and network policies should be sufficient, a quick review regarding access and integration might reveal the need for a quick adjustment.
Not every decision process will be the same, and considering broad changes (support model, workforce alignment, portfolio optimization — not just the budget) will improve your project. With a comprehensive plan, the cloud will allow us to become a more agile organization and meet the growing demands for digital services in higher education.
Meeting the Financial Challenge
When developing institutional cloud strategies, higher education institutions should address the financial implications of moving services to the cloud. Based on our experience at Centre College and the University of Arkansas at Little Rock, we suggest using the following techniques to manage the financial challenges you will face: make a compelling business case, communicate clearly with the rest of the institution, use governance for decision making, align with institutional mission, and pay attention to risk.
Jacqueline Bichsel, IT Service Delivery in Higher Education: Current Methods and Future Directions, research report (Louisville, CO: ECAR, April 2015).
Gartner, "Recommended Life Spans for Mobile, PC, and Other Endpoint-Computing Devices," July 2016, and "Know When It's Time to Replace Enterprise Network Equipment," June 2016.
J. Keith Fowlkes is chief information officer at Centre College and vice president, Board of Directors, HESS Consortium.
John Rathje is associate vice chancellor and CIO at the University of Arkansas at Little Rock.
© 2016 J. Keith Fowlkes and John Rathje. This EDUCAUSE Review article is licensed under Creative Commons BY-NC-ND 4.0 International.