Whilst the media heaps plenty of hype on the latest developments from major software and platform vendors it is important to remember that many businesses run on software packages tailor made to run a particular kind of industry operation. Often this software has been evolving over an extending period of time.
As the industry shifts to an increasingly cloud-enabled and mobile-focused future many of the independent software vendors (ISVs) who create these applications need to figure out how to remain relevant to customers who are now placing very different demands on the way that their software is deployed.
The kinds of challenges that ISVs are facing are (at least) threefold:
- The software is designed to run on a desktop and the UI would need to be completely re-written for a web or mobile experience.
- The software evolved organically and much of the business logic is scattered throughout the UI code within the previously mentioned desktop application.
- The software deployment topology uses traditional client/server database connectivity and may not be suitable for Internet deployments.
Attempts by ISVs to re-work their application architectures, or even entirely re-write their solutions have been mixed. Part of the problem is that these applications are literally the work of team decades and even if the code is less than ideal, it is still quite detailed in its implementation. In any code base you will find the tell-tale signs of inexperience as the founder of the business cut their teeth with programming for the first time, and at other times you will find that a code has been through so many hands that the foundational elements of the architecture have been worn away.
So how to move forward? Well there is no silver bullet for the code itself. At some point that crusty VB6/.NET hybrid monster is going to need to be put out the pasture, but perhaps you can get a little bit more mileage out of it yet by some shrewd use of cloud technology.
Priming for Cloud Enablement
One of the mistakes that many ISVs make when re-platforming is cutting off an upgrade path from their current customers to the new solution. Nothing encourages a customer to look at other offerings than their vendor telling them there is no upgrade path. The problem with the cloud is that not only do you have to provide an upgrade path but you also need to consolidate all customer data into one location.
It would be a mistake to leave this step until the end of your cloud enablement project. Instead I recommend that ISVs begin shipping an opt-in “Cloud Disaster Recovery” feature in their own software which replicates their customer databases to the cloud. Many ISV solutions are poorly managed by customers and so an offering like this would not only provide a benefit to the customer but also set things up for future offerings.
Another benefit of this approach is that for minimal investment you’ll clearly identity customers that “have problems with thems there cloud stuff”. If they won’t avail themselves of your applications cloud DR service then you’ve got some work to do ahead of your cloud cut-over.
Once the customer is backing-up their data to the cloud it is possible for the ISV to use that admittedly stale data to provide a read-only view accessible on mobile devices. Once again this would be an additional feature that the ISV could charge for. Behind the scenes the Cloud Disaster Recovery component of the desktop software would become more of a “connector” allowing for more frequent updates to the back/cloud replica.
This step requires that you begin exposing your customer data via a RESTful API and appropriately securing it (probably via an OAuth 2.0 mechanism). This API would be deployed exclusively in the cloud which means your mobile applications would require minimal configuration after downloaded from the major mobile vendor app marketplaces. You might even enable cloud identity providers such as Azure Active Directory or Google Apps.
Having satisfied some of the customer demands by achieving a read-only mobile solution the next step is to remove the need for the customer to manage infrastructure just for your application by uplifting the application and shifting it to the cloud. At this point the primary read-write usage of the application is still through a desktop application and so you would need to leverage technology such as Azure RemoteApp or Amazon WorkSpaces to provide a remotely hosted version of your application.
The critical thing to remember here is that you can leverage your existing DR/connector feature to make this transition as smooth as possible. In fact you can embed the components necessary in your desktop software to detect that a cloud migration has taken place and automatically cut over to the remoted experience.
This step still has its challenges. Before you can take on this responsibility (or indeed the DR responsibility) you need to move your team beyond just writing software and shipping and installer to a team capable of managing a sophisticated cloud infrastructure complete with the tooling and processes to manage upgrades on behalf of clients. This is actually the hardest part.
Another challenge at this phase is pricing the service. Most successful ISVs transitioned to a subscription model long ago. But the price of that subscription only covered the maintenance on the software, not a full blown hosting infrastructure. So you’ll probably need to add a hosted subscription option which includes the maintenance, hosting fees and perhaps bundle the DR fee (which is now redundant anyway) and the mobile access.
At this point step back and consider what you would have achieved. First, you have got all of your customer data securely stored in the cloud (probably with way better redundancy than they could ever afford). Secondly the customers are using that data live via a remote desktop experience. You now have got everything you need to start enabling specific read-write mobility scenarios against your application.
As part of the read-only mobility implementation you exposed a RESTful API. In this phase that API is extended and more features are built into the mobile applications. As the number of features increased certain classes of users cut across to using the mobile applications exclusively and you can start spinning down maintenance on the desktop application screens.
I would strongly recommend instrumenting your code at this point with something like Application Insights to get a good idea of how your software is being used to help prioritise this work.
Congratulations! You now have a SaaS application, but you aren’t done yet. One of the things that you probably didn’t do when you migrated your customers over was optimise your application to run more efficiently in a centralised computing model. For example can you work your schema so that multiple logical tenants can share a single database to reduce your database hosting costs? Are there any background processes that the desktop software used to perform that you now need to shift off to dedicated compute instances, and can multiple tenants share that single instance – and finally, when can you shut off the remote desktop access entirely?
If you have read this far then it probably means that you have seen first hand the challenges that ISVs face responding to customer demands for cloud/mobile capabilities in your software. I hope that the above gives you some creative ideas for taking your first steps or continuing on your journey. If you have any thoughts, feedback or want to share some of your challenges feel free to share below.