Software + Services - Opportunities and Challenges for Global ISVs

  • Article

ISV Challenges with S+S

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.

Key Differences between On-Premise and S+S Hosted Solutions

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.

Multi-Tenancy

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:

  • Approach. Multi-tenancy can be fundamentally implemented in two ways:
    • Within. Implementation within the solution can be changed to be made multi-tenant aware (e.g. DB tables may have a ‘tenant’ column added, or middle tier services may be modified to load tenant-specific meta-data to allow for tenant-specific processing). The advantage to this approach is efficiency and reuse of implementation and resources – the same code, DB tables, UI components, etc. are shared across all tenants. One disadvantage is that it may take considerable modifications to applications, DBs, etc. to incorporate multi-tenancy. Additionally, per-tenant customization approaches usually need to be changed. Code-based customization needs to be severely limited (shared code base across tenants), and per-tenant customization usually needs to be modified to be more meta-data (configuration) driven.
    • Around. Implementation is isolated or ‘wrapped’ to be made multi-tenant supportive (e.g. virtualization used to create per-tenant images). The advantage to this approach is that it doesn’t require modification of existing single-tenant code – the multi-tenancy is managed by ‘wrapping’ it inside an isolation boundary (the virtualization image). The disadvantages to this approach are that virtualization may not provide the best performance for high # of concurrent tenants/users/processes, and virtualization introduces additional technologies around creation of images, deployment, tooling, monitoring, etc. The other thing to mention is that, while virtualization would allow for code-level customizations on a per-tenant basis, implementing and managing N-versions of custom applications in this case could lead to a maintenance nightmare… so it’s still ultimately better to try and reduce code-level customization and instead move to more a configuration/meta-data based approach.
  • Tier. Different tiers can take different multi-tenancy approaches.  For instance, the middle ‘business process’ tier can be multi-tenant aware (as above), while the data tier might have separate DB’s for each tenant (and not require any adjustment of DB table schemas).
Scale

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

Hosting

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.

Configuration and Customization

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. 

Thank you,

Kevin Wittkopf - Lead Solutions Architect