Wednesday, May 15, 2013

Multi tenant architectures in On-premise settings

When discussing cloud computing, one often hears the term "Multi Tenant Architecture". The term is seen as "the standard" by which one should judge whether a software is truly a cloud solution or simply a software hosted on a remote data center. The expression implies the ability of an enterprise software to be effectively used by multiple enterprises at the same time, without the knowledge of one another.

As mentioned, Multi tenant architectures are supposedly one of the underpinnings of modern SaaS (Software as a Service) or cloud architectures. However multi-tenant architectures are increasingly being asked for in many on-premise deployments.

The reasons for this ask, ranges from convincing to the absurd. This trend is particularly noticeable in organizations where:

1. After an era where Corporate IT had no say  (for good reason), in business departments running their own mini-IT shops, IT has now become "a strategic expense". IT is trying to consolidate various home-grown systems, but the requirements have become so divergent that completely different functional and non-functional requirements are being sought.

2. Alternatively, in other cases, IT departments in large Organizations have bought multi-tenant software products without real business analysis. Here the promise was that client departments would utilize their own resources to understand the processes they would want to automate and then go about implementing such solutions in a self-service model.

3. Finally, are organizations where Multi-million dollar data centres have been sold to large organizations with the promise of virtualization without having a real business case for it.

Regardless of the mechanism, reality is that IT departments would like to look for applications that can be rolled out in this self-service way.

For our purposes, on-premise multi-tenant architectures are being desired by organizations wherever there is a self service software delivery model. Where multiple groups or departments or even organizations are using a shared environment and would like to sandbox their interactions and system configurations to their own use scenarios.

Multi tenant as the name implies multiple distinct uses. A good metric to validate if the architecture is truly multi tenant is to Of course ask the question "How many user groups are using distinct configurations, their own databases as well as configuration policies and yet are on the latest release of the software?"

To achieve multi-tenancy is a whole different ball game together. The first step is what is called virtualized multi tenancy where multiple environments and associated user groups are having their own configurations but in sandboxed virtual environments.

The next level is to allow multiple deployments within the same environment, but completely isolated by having dedicated instances of run time environments.

True multi-tenant architectures would imply that its the same run time process but allows completely isolated operations. The way to achieve it is perhaps through configurations that can be altered and spawned at any time. Perhaps resource constraints can be set to prevent monopolization of resources by a single instance/ configuration. Software based memory architecture would allow completely sand-boxed operations. All this requires a lot of hard work in upfront planning and designing and building.

Given these above requirements, I would think that to be functionally complete multi-tenant architectures would require the following:

1. A Configuration driven administration model
2. An ability to spawn and kill configuration based instances that are completely sand-boxed from one another.
3. An ability to set resource constraints on usage
4. A configuration authoring tool
5. A set of policies that dictates what can be done and not done
6. A starting persistence and object model that can be tweaked to a degree.
7. A standardized higher level SDK that can be developed against without having to accessing lower level APIs
8. Ability to monitor and report on usage and optionally get billed for it.

Based on the above, some conventional platforms are evolving to support multi-tenant models. Others, have a long way to go....

Wednesday, May 1, 2013

Design principles of google dashboards

Google analytics is one of the most heavily used BI dashboards on the planet. The design principles used by Analytics are straightforward but can provide a very rich user experience.

At the highest level, the dashboard is made up of metrics, dimensions and visualizations (widgets).

Google analytics collects various metrics about a visit to an enabled site. This includes site usage (new visit, visit duration, bounce flag, page visit), E commerce goals that the user may have set up, Adsense metrics in terms of revenue, CPM, CTR, and others.

The dimensions are grouped under headings of Audience, Traffic Sources, Content and Conversions.

Visualizations are provided as widgets which could be Standard or Real time. Standard widgets could be the metric value reported as a number, Timeline that shows trends over time, Geomap showing locations, Tables, Pie or Bar.

Each widget is optionally predisposed towards a primary dimension. Metric has no primary dimension, Timeline has time dimension hierarchy, map has location hierarchy, Table has a slew of dimensions and allows a cross tabulation between two metrics, Pie uses a grouping dimension and bar can plot one metric grouped by a primary dimension and optionally pivoted by an optional dimension.