GISVs that are embarking on creating a software plus services offering by building software as a service components to complement their on-premises applications are usually faced with an interesting dichotomy. On one hand, their solutions are typically the most capable, feature-rich software products available (because ‘global’ ISVs usually target medium to large enterprises), which would suggest they have a lot of great IP that many smaller enterprises would love, and could be leveraged into an S+S offering. But the dichotomy is that, because of this traditional customer base, the entire product architecture and deployment approach is usually fundamentally geared toward an on-premise model. As I’ll describe below, there are some key differences between on-premise and S+S solutions that GISVs need to be aware of when contemplating a move to S+S.
There are some key solution aspects which are markedly different between on-premise and S+S solution approaches. These are worth highlighting, in order to help you understand what may be involved in moving to an S+S offering.
S+S solutions are fundamentally based on the notion of supporting multiple customers (tenants) within a shared set of resources (e.g. multiple customers running on one hosted web server, database, code version, etc). On-premise solutions, however, have (by definition) one ‘tenant’, and typically allow significant customized code, DB schema, UI elements, etc. Support for multi-tenancy is typically one of the most significant aspects that must be considered and supported in GISV solutions moving to S+S. There are a number of different approaches to multi-tenancy at the data tier, application tier, etc. Fundamentally, there are two key dimensions to multi-tenancy:
For on-premise solutions, application performance and scaling is a function of the customers own hardware, resources, etc, and it impacts them only if/when issues arise. Dedicated hardware, DB servers, etc are usually the norm for enterprise solutions. Also, the # of concurrent users and processing is usually considerably less than in a hosted solution that is being accessed/used by 100’s or 1000’s of tenants and their users. In an S+S scenario, there can be many tenants (100’s, 1000’s) sharing machine resources, which may take the GISV on-premise solution into a whole new realm of net new scale and perf considerations. Thus, S+S solutions have to be typically instrumented and monitored/managed better (to provide scale and perf details per tenant, and support per-tenant changes, throttling, etc).
GISVs that today produce on-premise solutions are usually in brand new territory regarding hosting, and often initially suggest that they will ‘self host’. I guess this seems easier in a way (not having to select, and pay a hosting partner)… but, hosting is an entire discipline in itself, requiring specific skill sets, tooling, and of course, infrastructure to host on. There is a great white paper on ISVs and hosting – “ISVs are from Mars and Hosters are from Venus” which outlines SaaS-specific hosting, and ISV-specific considerations.
On-premise software can usually be customized extensively, including modifying or extending source code, database schemas, user interface components, etc. In a multi-tenant hosting situation, all tenants usually run on the same implementation (code base), thus limiting the kinds of customization possible. In the move to an S+S offering, a GISV usually needs to modify their solution to reduce/eliminate code-level customizations, and instead support this via meta-data or configuration. ‘Customization’ by a particular tenant then means modifying or extending their metadata (e.g. extended DB schema, new workflows in XAML, etc). Of course this usually means severely constraining customization capabilities (there are some requirements which will not be supported by the configurability options)
Microsoft provides some great technical resources to assist in understanding these aspects in detail:
These are just a few of the key areas to consider. There are of course lots of other considerations, and details to follow in future posts. But this is probably a good start.
Kevin Wittkopf - Lead Solutions Architect