The Invisible Database

In my previous post, I identified several challenges that ISVs face when considering a cloud offering for their software. Many of the ISV partners I have spoken with are looking for options that allow them to continue to offer their existing on-premise solution for customers, while creating additional cloud based offerings. To reiterate, some of the challenges we have observed are:

1. How to continue to support customers who prefer an on-premise solution?
2. How to support new requests for a hosted/cloud offering with a full featured solution?
3. How to provide migration between the two offerings (on-premise to cloud, or cloud to on-premise)?
4. How to minimize development effort?

In some ways, the challenges in thinking about ISV applications that run both on-premise or in the cloud are similar to the challenges faced by mobile ISV applications. In fact, I observed this previously: Good Design for SaaS Eases Move to Mobility / Good Design for Mobility Eases Move to SaaS. I am reminded of our recommended approach for the design and development of mobile database applications described in a series of previous blog postings. ( Step 1, Step 2, Step 3, Step 4 )

In particular, I feel that the first best practice step in developing a mobile application mirrors the first step an ISV should consider when thinking about adding a hosted / cloud offering into their product mix:

Step 1: Choose your Database Infrastructure

Each of the challenges I outlined above are made easier with an appropriate database infrastructure.

1. ISVs with existing on-premise customers continue to need an easy-to-use, self-managing database system that provides the out-of-box performance and functionality required for robust database applications. It turns out that those same attributes are also valuable in cloud/SaaS database environments designed to service the needs of many tenants/customers.
2. A database system that provides robust functionality will allow a full featured application to be developed. Many ISVs embed significant business logic inside the DBMS using stored procedures, triggers, and other schema functionality. A big step in enabling the creation of a full featured hosted/cloud offering is taken when all this business logic can simply be reused, without having to be redeveloped.
3. Migration back and forth between on-premise and cloud is a topic that is never mentioned in any discussion I have seen on the web or elsewhere. This is a surprise to me because this requirement is mentioned in almost every discussion I have had with ISVs over the last year. I believe this migration effort can be eliminated or minimized if you choose a database system that enables easy movement of database files. I plan to explore this specific point in a future blog post.
4. An axiom of our Waterloo based engineering team, and perhaps most engineering teams, is to take advantage of previously solved problems. This minimizes effort and reduces the time and cost to develop new functionality. As I described above, choosing a common database infrastructure for both on-premise as well as a hosted/cloud applications will reduce or minimize a significant portion of the effort needed to create new applications.