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