• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
  • paul wheaton
  • Tim Cooke
  • Devaka Cooray
  • Rob Spoor
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin

Top 10 Technical requirements for In-Memory Reporting

Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 would 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 is 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, modeling 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 is 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.

Further Information:

Download publications (Click Link or Cut into Browser, No signup or Email required)

In-Memory Brochure

In-Memory Whitepaper

About Yellowfin

Yellowfin is passionate about making Business Intelligence easy. Recently recognized among 25 rising companies that CIOs must know about, Yellowfin is a leading web-based BI solution that can be easily integrated into any third-party application or delivered as a stand-alone enterprise platform. Yellowfin is an innovative, fast and flexible solution for reporting and analytics, providing a full range of data access, presentation and information delivery capabilities. www.yellowfin.bi

For further information / interviews please contact:
Catriona McGauchie
Marketing & Communications Manager, Yellowfin
Direct line: +61 3 9090 0454 Mobile: +61 (0)428 368 371 Email: catriona.mcgauchie@yellowfin.bi
Curse your sudden but inevitable betrayal! And this tiny ad too!
a bit of art, as a gift, that will fit in a stocking
    Bookmark Topic Watch Topic
  • New Topic