It seems to me that here’s still quite a lot of confusion swirling around what, exactly, constitutes a “cloud model” for software. We know that Gmail is cloud-based. But when we start to get into large scale enterprise software, it all gets fuzzier. If I take a traditional enterprise app, host it on my server, and rent it to you by the month, is it cloud-based? I think the answer comes down to what you care about, mostly – if you’re a CIO and you care about the maintenance costs and pricing model, it’s cloud-based. If you’re a developer and you care about continuous release and multi-tenant architecture, then that system probably looks to you like on-premise installed software—just in a different building. But one of the intriguing things that is starting to emerge is a new enterprise application architecture that we’re calling “cloud-hybrid”, in which a single application combines both installed and cloud-delivered elements.
At the end of the day, the browser doesn’t care where it’s serving a page from, and the user certainly doesn’t need to know. Thus, you can build an app that seamlessly combines elements from servers running inside a company’s firewall with elements served across the Internet. This isn’t exactly new – Amazon’s front page is the product of hundreds of different systems, each serving up a small piece of functionality. And there are zillions of Google Maps mash-ups out there. But it is new in the context of enterprise software.
Why would you want to do this?
In our case, we’re very interested in mixing elements from our Guidewire Live cloud-based services into our on-premise, installed applications. For example, we want to use anonymized information from our shared customer data warehouse to help drive business workflow. At the same time, our customers entrust us with that data, and we have to normalize and protect it from being improperly disclosed. To do this, we control and process the data at our site, but then the value comes from applying that information to operational tasks happening in each carrier’s installed core systems.
We want to drive work to users of those systems based on analysis that we do on our side. For example, if we find that the weather (which we pull from a third party provider) doesn’t match the reported cause of loss on a claim, we can push an activity to an individual user to look into the mismatch. And sometimes, we want the flow to go the other way: for a user to be able to call out to get specific data or maybe an analytics visualization, all from within the context of the application they use for their daily work.
In the coming years, I think we’ll see a growing number of new capabilities being served directly by us in the cloud. This will definitely be true for features that depend on shared data that we need to maintain centrally. It also makes sense for features that involve multiple parties, where we can coordinate the external interactions on behalf of our customers (for example, the integration to the weather data provider I mentioned before). In principle, anything that doesn’t involve a lot of customer configuration or integration within the enterprise is a good candidate for this model. But I also don’t expect our installed InsuranceSuite applications to become any less important: customers still need to have direct control and access to their core transactional data -- for security, legal, and reporting reasons, among other things. They still need to be able to deeply configure the systems to their needs and to be able to integrate them to dozens of other enterprise systems.
This is why I think this cloud-hybrid model is going to be a long-term winner. It mixes the best characteristics of these different delivery technologies, as appropriate, on a feature-by-feature basis.