Issues and Complexities Revolving Around Cloud Sprawl

By Kim W. Tracy, CIO, Northeastern Illinois University

Kim W. Tracy, CIO, Northeastern Illinois University

As we continue to deploy more vendor-hosted or cloud-based applications, we are starting to experience a phenomenon that I’m calling “cloud sprawl.” This cloud sprawl is resulting in a new set of issues and complexities that this article explores. These issues are particularly critical for those applications that are tightly-integrated with other applications (such as the ERP).

Background

As many institutions are doing, we are taking the opportunity to host more new applications in the cloud or using a vendor-hosted model. There’re lots of good reasons for doing so. These reasons include: quicker to implement, less capital expenditure, fewer specialized staff to maintain the application, and better disaster recovery facilities. So, as a result every time we put out a Request for Proposal (RFP) we put in the option of having the vendor host it. Vendors are doing a much better job than they were hosting their applications in a reliable fashion than they were doing even a decade ago. So, we’ve ended up with about 10 of these hosted applications in addition to the infrastructure, other applications, and ERP that we host in our own data center.

Our Emerging Cloud Sprawl

To illustrate how we are beginning to see the issues involving cloud sprawl, please refer to Fig. 1, a simplified version of what we are experiencing. This doesn’t include all of our applications or the complexity, but is merely a small subset to illustrate the issues. In our environment, we have hosted versions of our Learning Management System (LMS), Constituent Relationship Management System (CRM), Payment Gateway and related Marketplaces/Storefronts, and institutional website is hosted along with its Content Management System (CMS). Both the LMS and CMS have substantial integrations with the ERP and my expectation is that these will become even more tightly integrated as the LMS and CMS evolve. The substantial integrations are indicated by a heavier dotted line. Looser integrations are indicated by a lighter dotted line. Substantial integrations include product dependencies, rather than just supporting a standard interface. For example, support Lightweight Directory Access Protocol (LDAP) and integrating with our LDAP is a loose integration. Integration with our ERP and using a product-specific interface that depends on the version of ERP and interface is a substantial integration. Interestingly, many of these vendor-provided hosters actually end up using one of the large cloud providers. So, several of these systems are actually on Amazon’s cloud.

“Vendors are doing a much better job in hosting their applications in a reliable fashion which is different from what they did a decade ago.”

Our strategy has been to strongly encourage use of our authentication systems, so that we can better maintain identities and accounts across these systems. This allows us to better de-allocate or audit usage, particularly when a user leaves the institution or changes roles. Until recently, most of these integrations have been relatively loose. Recently, in order to offer more functionality, these integrations have become much more substantial. In particular, the CRM has a substantial integration with our ERP to admit new students and to share data back and forth.

Further complicating our situation is we now have a purely cloud-based integration between the payment gateway and the CRM. That is, the integration is between two vendors, but we have to make sure it works and the vendors will work together.

Issues with Cloud Sprawl

The primary issue we have is that the dependencies between these systems are becoming greater, making it more difficult to coordinate and to ensure that the overall environment works as intended. Most major systems have some dependency on the ERP, with some like the CRM, having a greater dependency on the ERP. Here are some of the issues we face:

Updates: The updates to systems are becoming difficult to coordinate, schedule, and accomplish in a timely manner. Furthermore, many of these updates are done on the vendor’s schedule—not ours. So, if we upgrade our CRM, we very likely will have to also update our ERP and sometimes have to coordinate an update with the payment gateway vendor. Occasionally, the vendors do not communicate (or worse yet, do not know) the dependencies between their system and those with which it’s integrated.
Contracts: Each of the contracts is different with every vendor-hosted application. As a result, the DR provisions are different and often, Service Level Agreements (SLAs) are very different. The contracts can also include how and when the vendor can update the system.
Technical compatibility: Besides the coordination of updates, we also have the potential issue of finding an upgrade path that works and continues to provide the level of service our customers demand. When all of these systems are under our control, it was easier to find a path to upgrade or do a forklift upgrade in a timeframe agreeable to the institution.

How to Mitigate the Risk

I do believe that it would be easy to get into a situation where it would become almost impossible to provide the service the institution requires. For example, if we had yet another cloud-based provider of an application that substantially integrates with the ERP. I can imagine a situation where that provider might not care to cooperate in order to remain technically consistent with another cloud-hosted application that is also substantially integrated with the ERP. However, there are several actions we can take to reduce the risk. Some of them follow:

Face the complexity: Recognize the issue of complexity and carefully consider the complexity implications before cloud or vendor hosting another application. This would involve asking the vendor beforehand as well as possibly stipulating constraints in the contract. These constraints could involve supporting the larger environment of applications (cloud and data center) and providing a technical path when upgrading.
Test environment: For each vendor-hosted application, make sure to have a full test environment that can be used for upgrades and testing. This environment should be also accessible for user testing and part of the contract.
Reduce cloud hosters: For many applications, it is possible to co-host in a single cloud vendor. This would likely require contracting with the cloud provider (such as Amazon) yourself, which will reduce some of the benefits of hosting with the vendor.
Use standards: Ideally, these integrations would largely depend on open standards. One example would be to require that the integration between the LMS and ERP be based on the IMS LIS (Learning Information Services) standard or to use cloud-based providers that specialize in integration.
Latest and greatest: To reduce the likelihood of needing additional upgrades and to be more likely close to the vendors’ development cycle, keeping on the latest versions as feasible of all the inter-related applications will help. It’s no guarantee either, as I’m sure some of these vendors will be slow to upgrade their application just to be compatible with the latest version of someone else’s application.