Recent Tweets
join our mailing list
* indicates required

About Ambleside

Ambleside Logic is led by Aaron Rosenbaum. Father of 3, Programming since 7, DevOps since 11 (hacking RSTS), exIngres, exCTP, exCohera. Sold two companies to Oracle, one to HP. Research + Strategy for NoSQL/BigData ecosystem implementors, vendors and investors.

« Selling Big Data applications | Main | A taxonomy of Big Data »
Tuesday
Aug092011

What is a "Big Data" Application?

Big data is all the rage.  Lots and lots of companies are busy prototyping and building analytics applications that leverage this infrastructure.  Many of the last generation of analytics apps were more of a toolkit than an actual application.  That isn't going to cut it this time - the customers have infrastructure in place and if they just want infrastructure, they have free options to start with. What makes it an application instead of a demo of infastructure?  Several key feature areas work together to reduce time-to-value and risk vs. infastructure + labor.

Answer a question

First and foremost, you must answer a question.  And you really need to commit to that question or questions in advance - you will not be able to position to answer every question.  How should my products be priced? Which customers are most valuable? Which divisions are growing fastest? Where do I have the most currency risk?  You need to pick a set of questions to answer. Of course, the answer must matter - it must drive profitability, growth or quality. The focus on a particular area will reduce time-to-value vs. a specific focus on the customers own question.

Show a great looking single page answer to that question

The magic report must capture the imagination of your buyer and you buyers boss.  With this single page of information, the must perceieve that they have more confidence and guideness over this question than they ever had before.  It must not be dry. The visualization should really be quite daunting and non-generic to engage people with the shortest attention spans (which sometimes are the economic sponsors of the project.)

 

Pre-built data connectors

Your application should include connections to common systems in the industry.  Build a set of easy ones and one or two more propietary ones.  First, you don't want to concede business to the operational system provider (SAP, Oracle, etc) because the users imagine that the integration will be smoother with those systems - it may or may not actually be smoother.  So you at least need parity if not actuall reduced integration risk.

External/Syndicated Data

It would be good to include some reference data - mappings, industry standards - anything that puts the customers data in perspective and makes buying the app more compelling than building it internally. Certainly there shouldn't be burden on the customer to write these integrations if the application needs it.

Data Cleansing

There should be a set of known data quality problems that your team has already solved.  It's okay if these are solved in an expensive way via services - just knowing the solutions will put you ahead of solutions that require clean data or solutions that don't have ready specifics around typical issues.  Even if the data is fairly clean, include a standard and some tools to validate it.  It's not hard to get buy-in from customers that their data is suspect.

Reference Implementation Model

You should have a map of stakeholders, deployment, change management process for you app.  You are the expert in organizing an organization to take advantage of these new answers and you will make the process smooth for the client and their consultants.

 


PrintView Printer Friendly Version