With Gartner’s Business Intelligence group listing In-Memory analytics at the top of their recommended Business Intelligence requirements for enterprise; No wonder In-memory has become a trending topic in BI and a new addition to executive shopping lists.
We thought we’d share with you our top 10 technical requirements, you should be asking from an in-memory analytics vendor:
[10] Be open – allow other applications to connect to it (other than the in-memory database provider)
It’s important to source a non-proprietary database, in-memory databases are usually bundled with a visualization tool and it’s important that the provider allows other tools to connect to the database so that you can maximize your investment in the technology, rather than being tied to a proprietary solution.
[9] Minimal administration overhead
In-memory analytic tools often introduce some of the same concerns that OLAP stores create: namely, they usually create another data source, with its own calculations and business definitions. This is where tools such as Yellowfin differ from other in-memory approaches: existing queries, reports and dashboards automatically take advantage of an in-memory database, seamless to users. Administrators are not adding calculations and business logic within another layer; they reside within the existing meta-data layer for reporting that is already built.
[8] Enterprise scalability
It is critical to select enterprise class infrastructure that enables you to scale your deployment as your users grow.
All BI solutions must include enterprise administrative features, such as usage monitoring, single sign-on and change management; and this is just as true for in-memory solutions. It is therefore, critical that you choose solutions that can provide enterprise class infrastructure that enable you to scale your deployment as your users grow.
[7] Platform independent
It’s important when selecting an in-memory database that it be platform independent. It should run on any hardware platform (PC, Mac, SunSparc, etc.) or software platform (Linux, MacOS, Unix, Windows, etc.).
[6] Data Serialized to disk to enable rapid recovery
An image of the in-memory database is saved to disk, allowing the system to quickly reload the image should the system need to be restarted. This means that data can be loaded into your in-memory database without the need to place additional strain on your production or transactional servers.
[5] Integration with your existing data warehouse and OLAP cubes
While some vendors tout in-memory as a way of avoiding building a data warehouse, this option usually applies to smaller organizations that may only have a single source system. For larger companies that have multiple source systems, the data warehouse continues to be the ideal place to transform, model and cleanse the data for analysis.
Look for tools that are designed to integrate with and leverage existing BI environments. An in-memory solution that is tightly integrated into the visualization tool is critical. However, it is equally important that the visualization tool can also access your OLAP cubes and data warehouse tables without the need for an in-memory middle-layer. Without this option a purely stand-alone in-memory solution can lead to yet another version of the truth, adding complexity to your BI environment.
[4] Web-based GUI development and deployment.
Some in-memory tools are not nearly as web enabled as their conventional BI counterparts. This seems to reflect both technology immaturity and a tendency to be a niche deployment. However, for successful adoption with minimal administrative overhead web based development and deployment is critical. Both the visualization tool and in-memory database need to be server based deployments to ensure that data access security and application upgrades can be easily managed. Solutions such as Yellowfin provide a single web based platform for delivering your Business Intelligence needs. From connection through to design, modelling and visualization, your users work within a fully integrated browser application that encourages collaboration and an iterative approach to report development – leading to analytical applications that meet the needs of your end users.
[3] Server side rather than Client side
Consider a scenario where users are able to conduct complex queries by downloading up to 100 million rows of data to their desktop from many data sources, or data feeds from the web. Sure the information can then be sliced and diced into reports or users can create BI applications on their desktops and share them with colleagues. This sounds great in theory but is fraught with danger in practice. Not only does this have a massive potential to create data silos but with this level of data stored on a laptop, it is free to leave your premises and get lost or stolen in the worst case or published without any form of governance at best.
[2] Ensure real time data refresh – incrementally loaded
Because reporting data is extracted from a source system or a data warehouse and then loaded into memory, data latency can be a concern. Front-line workers in a customer service centre, for example, need near-real-time highly granular (detailed) data. If an in-memory tool contains last week’s product inventory data, it’s probably not of use to customer service reps. Thus, the suitability of an in-memory tool and the success of the deployment may hinge on the degree to which the solution can automate scheduled incremental data loads.
[1] Data security must be of paramount concern
In memory applications have the potential to expose significantly more data to end-users then ever before. This raises security issues regarding how data is accessed, where it is stored and who has access to that data.
In determining the best strategy for your in-memory deployment, security needs to be foremost in your selection criteria. There are two aspects of security. Firstly, where is your data stored and is that storage secure? And secondly, who has access to that data store? Transactional applications go to great lengths to embed data security and access rules – ensure your in-memory database inherits these and is not simply a data access free for all.
