Tag Archives: big data

WhereScape at BBBT: Another Intriguing Product Without a Clear Message

2 Replies

Last Friday’s BBBT presentation was by Michael Whitehead, CEO, WhereScape. The company seems to have a very interesting and useful product, but there’s a huge communications gap that needs to be addressed.

What They Do

One marketing issue to start was that I got most of this section from my own experience and WhereScape’s web site, not from Michael’s presentation. When someone begins a presentation by proudly announcing it is ““guaranteed there’s no corporate marketing in the presentation at all” while you’re presenting to a group of analysts, there’s a disconnect and it shows.

WhereScape has two products, Red and 3D, to help build and maintain data structures. The message is focused on data warehouses, but I’ll discuss that more in the next section. One issue was that their demonstration didn’t work as there seemed to be a problem connecting between their tablet and the BBBT display system, so much of what I’m saying is theory rather than anything demonstrated.

Red is their tool to build data warehouses. Other tools exist and have been around for decades, Informatica being just one competing firm.

3D is where the differentiation comes in. Everyone in IT understands that nightmare that is upgrading major software installations such as ERP, CRM and EDW systems. Even migrating from one version to the next of a single vendor can involve months of planning, testing and building, followed by more months of parallel runs to be safe. A better way of analyzing and modifying data structures that can compress the time frame can have a large positive impact upon a corporation. That’s what WhereScape is attempting.

What They Say

However, their message is all “Automation! Automation! Automation!” and the short part of the demo that worked showed some automated analysis but a lot of clicks necessary to accomplish the task. From what I saw, it will definitely speed up the tasks, if as advertised, with clear time and money savings, but it’s not as automated as implied and I think a better message is needed.

In addition, their message is focused on data warehouses while Michael said “We’re in the automation business not the data warehouse business,” which really doesn’t say anything.

Michael did talk for a bit about the bigger data picture that includes data warehouses as part of the full solution, but again there’s no clear message. While saying that he doesn’t like the term Data Lake, he’s another that can’t admit that it’s just the ODS. There’s also a discussion of the logical data warehouse, also not something new.

One critical and important thing Mr. Whitehead mentioned was something I’ve heard from a few people recently, the point that Hadoop and other “unstructured databases” aren’t really unstructured, they support late binding, the ability to not have to define a structure a priori but to get the data and then understand and define a useable structure for analysis.

What They Need to Say

This is the tough one and not something I’m going to solve in a short column. The company is targeting a sweet spot. Data access has exploded and that includes EDW’s not going away, the misnamed concept of Big Data and much more. Many products have been created to build databases to manage that data but the business intelligence industry is still in the place packaged, back-end systems were in the 1990s. Building is easier than maintaining and upgrading. A firm that can help IT manage those tasks in an efficient, affordable and accurate way will do well.

WhereScape seems to be aimed at that. However, their existing two-fold focus on automation and data warehousing is wrong. First, it doesn’t seem all that automated yet and, even if it was, automation is the tool rather than the benefit. They need to focus on the ROI that the automation presents IT. Second, from what was discussed the application has wider applicability than just EDW’s. It can address data management issues for a wider area of business intelligence sources and the message needs to include that.

Summary

Though the presentation was very disjointed, WhereScape seems to have focused on a clearly relevant and necessary niche in the market: How to better maintain and upgrade the major data sources needed to gain business understanding.

Right now, while there is a marketing staff at the company, WhereScape’s message seems to be solely coming from the co-founder and CEO. While that was ok in the very early days, they have some good customer stories, having led with Tesco’s success in this presentation, and it’s time to leverage a stronger and clearer core message to the market.

Where the issue seems to be is the problem I’ve repeatedly seen about messaging. The speed of the industry has increased and business intelligence is, on a whole, crossing Jeffrey Moore’s chasm. That means even younger firms need to transition from a startup, technically focused, message to a broader one much more rapidly than vendors needed to do so in the past.

While WhereScape has what seems to be the strong underpinnings of a successful product, they need to do some seriously brainstorming in order to clarify and incorporate a business oriented messaged throughout their communications channels – including in presentations by founders.

An ODS by any other name still smells like data

Leave a reply

Data warehouse theory originally posited extracting data from systems, performing transformations on them and loading the resulting schemas into the data warehouse. It was a straight flow of information. However, the difference between theory and practice quickly reared its head. Today, people are talking about Data Lakes and Data Swamps. They’re not new, they’re just the ODS updated for modern data.

Data Warehouses and the ODS

Academics don’t have to deal with operational systems. In the 1980s and 1990s, those systems were growing, with ERP, CRM and other systems increasing the complexity and volume of data. Those mission critical systems, however, weren’t designed for extraction of information. They were primarily running on RDBMS systems that had locking schemas that could grind process and transactional systems to a halt while and extraction program kept open large blocks of records while transforming basic data in star schemas. Something needed to be done.

There was also a secondary effect that was very important to some people. IT, just as with ever other department in a large enterprise, isn’t monolithic. The people managing the operational systems knew their systems were mission critical and also knew how, in reality, those systems were big but fragile. They weren’t happy with opening their operational systems to other IT folks who were interested in non-operational things. Those folks answering other business problems? They were viewed as intruders, getting in the way of the “real work.”

For both reasons, intrusions into the operational systems were something to be kept to a minimum. IT organizations began using an Operational Data Store (ODS) to quickly open the operational systems, suck all the data out, willy-nilly (yes, I decided to use that term in a tech article…), and then go back to prime performance in an isolated system.  ODS 1

It was then the ODS that was the source of the data warehouse ETL process. On a tangent, this is why the people now arguing about ETL v ELT amuse me. It’s been ELETL for decade, if we want to be honest; but who cares? I’d rather have a BLT than spend so many cycles over slightly different acronyms for concepts that ETL handily describes, even in permutations.

The ODS comes into its own

The IT folks who were working to provide reports for mid- and high-level managers were always trying to tweak enterprise software reports, trying to extract nuggets of value. The data warehouse was a step forward and helped build a bigger picture. However, the creation of star schemas and other DW techniques aggregated data and lots a lot of detail. A manager would see an issue and want to backtrack, to drill-down into the data to know more.

The ODS became the way to do so. Very quickly, the focus changed from ODS in front of the data warehouse to both working side-by-side. Having all that raw data available gave the business analysts a way of providing much more detail and information to the business user. The first big BI companies, those such as Cognos, Business Objects and more, leveraged the two data stores to provide an ability to drill down past the aggregate information into the more detailed data.ODS 2

Having that large volume of data from multiple operational systems also intrigued people who weren’t data warehouse focused. They wanted to sift the raw data for technical or performance trends, things that weren’t of interest to the typical DW designers and users, but were important to mid-level management in manufacturing, marketing and other departments. Business analysts supporting those people began to turn to more and more analysis directly on the ODS data

The ODS comes to the fore – by another name

That was happening in the 1990s, at the same time another key phenomenon was growing: The Web. The growth of the web meant a lot more data about a lot more things. Web sites are operational systems to marketing in just as critical a way as an assembly line is to manufacturing. People became interested in ensuring that what visitors to web sites did was captured and available for analysis. However, as the volume of web traffic grew exponentially, new issues had to be looked at to handle that data.

Columnar databases were one solution, a way to speed up analysis of dimensions of information across individual records. The vastly larger amount of data also helped push emerging MPP technologies and drove creation of Hadoop and other technologies that could manage much larger data sources much faster and more cost efficiently than could individual Unix servers.

However, the web folks were new to IT and grew up in a different generation than the folks who designed and drove data warehousing. It’s natural to ODS 3want to take ownership of concepts, especially those on the edge. So the folks working with these new data sources began talking about Big Data as somehow completely different than what came before. If that was the case, they needed to think of some term for the database where they dumped all the data extracted from web sites. Data Lakes became one term. We’ve heard data swamp and other attempts to create unique terms so a company can differentiate itself from others. However, there’s already a name.

The ODS exists. It’s evolved. It’s moved forward. But it’s still the ODS.

Yes, really

“But,” you say, “an ODS is operational information and the data lake is so much more!” Well, not quite. There are two main problems with that argument.

First, times change. When the ODS was coined, the focus was on the back-end systems such as ERP, CRM, accounting and other fairly closed systems. It was before the web, before the ubiquity of mobile devices, before the wall between back-end and customer-facing systems was destroyed.

As mentioned, not just web sites are but even the internet is an operational system for your business – and not just for ecommerce companies. From lead generation, to maintenance and training, the internet is a key tool for providing operational support and generating business critical operational details.

Second, just as ETL can mean a number of things, so can ODS extend past a pure theory while still being relevant. CRM systems are considered operational but still contained sentiment and other information in comments fields. Just so, the vast volume of data from a call center’s voice recording system being dumped into the ODS have two components. There are basic details about the operation of the call center, things such as number of calls, call length and other details that are purely operational. There are also additional details about customers that can be distilled for strategy purposes, including the ability to provide sentiment analysis. Just because an operational system captures data that can be used for more than purely operational decision making doesn’t obviate that the information extracted resided in an ODS.

Summary

It’s a need of information technologists from all generations to realize that things change but retain context. The ODS isn’t what it was thirty years ago, but the data lake also isn’t some new creation born full blown from the web. There are few truly revolutionary technologies. You can be a brilliant person and contribute much to technology and business and still not be a revolutionary.

The ability to manage the vastly larger amounts of data than we had twenty years ago is critical. There are many innovative things being done. However, I consider the first expert systems, the first MPP algorithms and other similar technologies to be revolutionary. The fact that what is being done to allow business to gain insight combining more and more data from even more diverse sources is no less valuable to the industry because it is instead an evolutionary change.

The ODS has evolved. It doesn’t need a new name, just a tad more respect.

SQL v Hadoop: The Wrong Conversation

Leave a reply

“No SQL!”

“Hadoop doesn’t require you to work in SQL!”

The claims are everywhere, but do they mean anything? To ruin the suspense: No.

There seems to be a big misunderstanding or a big lack of communications in the realm of big data. I keep hearing company after company compare Hadoop to SQL, claiming the former is somehow better than the later. Sadly, that’s comparing apples to screwdrivers.

Hadoop is a database technology. It’s based on MPP architecture for the Cloud. Hadoop compares to flat files, relational databases and other methods for storing information in structures.

SQL is an query language. It’s similar to an API in that it’s just a way to communicate with the data source. Long ago, in the dawn of time, SQL was tightly tied to DB2 and the relational environment that spawned the syntax. However, along came the 1980s, Unix servers and PCs, and the need to access lots of different data sources and an unwillingness to have to have very separate query languages for each data source.

Along came ODBC to the rescue. It standardized core query syntax using the SQL paradigm and allowed, under the covers, the ODBC developer to use an API to translate almost standard queries into the language of each data source. It extended SQL to access new things.

In the meantime, as RDBMS technologies began to try to find ways around the basic limitations of relational databases, the companies added extra features such as stored procedures that extended SQL even further from the origins of basic definition and query of relational structures.

So now we have a mass of coders who have only worked with large, primarily Web oriented databases using non-RDBMS technology. No surprise, they had to code their own interfaces and queries, getting into the details of the newer systems. At the same time, they probably brushed through and overview of RDBMS and SQL in school and then never used it again.

That meant a misunderstanding of the difference between database and query. Therefore, the message of No SQL will retard their progress in integrating their solutions with the existing IT data infrastructure.

There’s a large need for people who can work with Hadoop and other younger data sources. There’s also a vast pool of people who know SQL. Yes, there will always be a need for Hadoop gurus just as there is for every technology, but the folks wanting to get information out of data sources don’t need to know the data sources, they need to get the information – and they know SQL.

A number of vendors have figured that out and are now offering SQL as a means to access Hadoop. It’s a natural fit, an extension of what the people pushing Hadoop are hoping to achieve. Hadoop and other distributed, non-row based architectures are there to expand knowledge. They’re great ways to better understand the vast body of data coming in from many new sources. However, until you can get that data to the business knowledge worker, it’s not information. SQL is the clearest way to quickly bridge that gap.

The people who realize that it’s not an either/or decision, who understand that Hadoop and SQL not only can but should work together are the people who will drive their companies forward by quickly addressing real business needs.

SQL v Hadoop is the wrong conversation. SQL and Hadoop is the right one.

TDWI, Claudia Imhoff and SAP: Data Architecture Matters

Leave a reply

In a busy week for TDWI webinars, today’s presentation by Claudia Imhoff, Intelligent Solutions, and Lother Henkes, SAP, was about how the continuing discussion of the place in the data world for the data warehouse.

While many younger techies think the latest technology is a panacea and many older techies are far too skeptical for too long, the reality is that while the data warehouse is going nowhere, it has to integrate with the newer technologies to continue improving the information being provided to business knowledge workers.

One of Claudia’s early slides talked about data sources. While most people are focused on both the standard packaged software and the rush of non-structured data from the Web, call centers, etc, Claudia makes clear the item that companies are just beginning to realize and address: Sensor data is just as important as the rest and also driving data volumes. Business information continues to come from further afield and a wider variety of sources and all must be integrated.

Much of her talk, she mentioned, has come out of a couple of years of work between herself and Colin White, in formalizing the changing data architecture environment. Data warehouses are still the place for production reports and analytics, where data provenance and clarity are absolutely necessary while the techniques used on early stage data such as in streaming, Hadoop analytics, etc, are more exploratory and investigative. The duo posit that the combination of data integration, data management (including EDWs), data analysis and decision management are the “glue in the middle,” those things that bind sources, deployment and distribution technologies, and reporting and analytics options into a real system that provides value.

The picture they put together is good and Claudia Imhoff’s presentation should be looked at for a better understanding of where we are; but I wouldn’t be me if I didn’t have a couple of issues.

The first is a that she is a bit too enamored of mobile technology. It’s here and must be addressed, but statements such as “nobody has a desktop, everything is mobile” must be corrected. A JD Power survey last year showed that only 20% of tablets are used for work. On the other side, Forrester Research has pointed out a strong majority of business people are now using two devices for their information.

The issue for business intelligence is not that people are switching from desktops (including laptops in docking stations) but that smart providers of information need to build UIs that address the needs of large monitors, tablets and smartphones, addressing each device’s uniqueness while ensuring a similarity of user experience.

The second issue is a new term thrown out during the presentation. It’s “data refinery” and, as Claudia mentioned in her presentation, it’s the same thing others are calling a data swamp, data lake or numerous other terms. There’s an easy term everyone has used for years: Operational Data Store (ODS). I’m a marketing guy and I understand the urge for everyone to try to coin a term that will catch on, but it’s not needed in this case.

While it’s a separate topic (yeah, another concept for a column!), I’ll briefly point out my objections here. Even back in the late 1990s, during my brief sojourn at Informatica, we were talking about how the ODS can be used for more than only a place to use in order to quickly extract information from operational system so as not to stress them by doing transformations directly from such systems. They’ve always been a place to take an initial look at data before beginning transformations into star schemas and the like. The ODS hasn’t changed. What’s changed is the underlying technologies that support larger data stores and the higher level analytics that let us better analyze what’s in the ODS.

That brings us to one main point Claudia Imhoff made during her wrap-up, the section on business considerations. She points out that people really need to understand the importance of each data source and the data within it. Just because we can extract everything doesn’t mean we need to save everything. Her example was with customer sampling. Yes, you can get all the customer data, but only that which you need to narrow cast. For higher level decision making, those who understand confidence levels know that sampling can get to very high levels of certainty so sampling can still speed decision making and save costs. Disk space might be less expensive in the Cloud, but it’s not free. We’re in the job of helping businesses improve themselves, so we need to look at the bigger picture.

Her presentation was clearly strategic: We need to rethink, not reinvent, data modeling. Traditional techniques aren’t going away and neither are many of the new ones. Data management people need to understand how they combine.

No surprise, that was a great transition to Lother Henkes’ presentation. His key point is that SAP BW now can run on SAP HANA. It’s important even if all the capital letters look like shouting. HANA is SAP’s in memory, columnar database that’s their entry into the Cloud market to manage the high volumes of modern data. It’s a move to bridge the gap between the ODS and relational database arenas with one underlying infrastructure.

In such a brief webinar, it’s hard to see more than the theory, but it’s a clear move by SAP to do what Claudia Imhoff suggested, to take a fresh look at data models in order to understand how to better support the full range of data now being incorporated into business decision making.

Datawatch at BBBT: Another contender and another question of message

1 Reply

Yesterday’s presentation to the BBBT was by Datawatch personnel Ben Plummer, CMO, and Jon Pilkington, VP Products. As they readily admit, they’re a company with a long history about which most people in the industry have never heard. They were founded in the 1980s and went public in the 1990s. Their focus is data visualization, but much of their business has been reseller and OEM agreements with companies including SAP, IBM and Tibco.

The core of their past success was with basic presentation of flat file information through their Monarch product. It was only with the acquisition of and initial integration with Panopticon in 2013, providing access to far more unstructured data that they rebranded as data visualization and began to push strongly into the BI space.

The demo was very standard. Everyone wants to show their design interface and how easy it is to build dashboards. Their demonstration was in the middle of the pack. The issue I had was the messaging. It’s no surprise that everyone claiming to be a visualization company needs to show visualization, but if you’re not one of the very flashy companies, your message about building your visualization should be different.

Datawatch’s strengths seem to be two-fold:

  • Access a very wide variety of data sources.
  • Access in motion data.
  • Full service from data access to presentation.

While Ben’s presentation talked about the importance of the Internet of Things and that real-time data is transactional, Jon’s presentation didn’t support those points. Datawatch is another company working to integrate structured and non-structured data and they seem to have a good focus on real-time, those need to be messages throughout their marketing, and that means in the demo.

Back from that tangent to the mainline. The third point is a major key. Major ETL and data warehouse vendors aren’t going away, but for basic BI, it adds costs and time to have to look at both and ETL and a data visualization tool which may not work together as the demoware indicates (A surprise, I know…). The companies who can get the full stream data supply chain from source to visualization can much more quickly and affordably add value for the business managers wanted better BI. I know it’s a fine line in messaging that and still working with vendors who overlap somewhat, but that’s why Coopetition was coined.

They seem to have a good vision but they haven’t worked to create a consistent and differentiated message. That could be because of resources and hopefully that will change. In February of this year Datawatch issued a common stock offering that netted them more cash. Hopefully some of that will be spent to focus on created strong and consistent marketing. That also includes such simple things as changing press releases to be visible from the PR link as html, not just pdfs.

Summary

I know you’re getting tired of hearing the following refrain, but here it is again. The issue is that I’ve heard this message before. The market is getting crowded with companies trying to support modern BI that’s a blend of structured and unstructured data. Technologists love to tweak products and think that minor, or even major technical issues that aren’t visibly relevant to the market should sell the product all by themselves. Just throw some key market points on top of them and claim you have no competitors because your technology is so cool.

BI and big data are cool right now and there are a large number of firms attempting to fill a need. Datawatch seems to have the foundations for a good, integrated platform from heterogeneous data access to visual presentation of actionable information. That message needs to quickly become stronger and clearer. This is a race. Being in shape isn’t enough, you have to have the right strategy and tactics to win the race. Datawatch has a chance, will they stumble or end up on the podium?

MapR and Skytree Webinar Shows the Need for Product Marketing

Leave a reply

Yesterday I listened to a webinar by MapR and Skytree supposedly on Hadoop and machine learning. As someone with a background in artificial intelligence (from way back in the 1980s…), I was interested in the topic title. However, to be very sadly blunt, I came away not having learned anything.

The Presentation

There seemed to be two major problems:

1)    They didn’t know who was their target audience.

2)    They don’t know presentations.

I couldn’t tell if they were focused on a technical or business audience.  After all, they didn’t start the presentation by explaining either predictive analytics or machine learning. The MapR guy who opened mentioned he was going to describe machine learning and then only showed a table showing how machine learning can be used in multiple use cases. The table did didn’t differ between historical and predictive analytics nor did it emphasize predictive analysis. However, he talked about MapR as if everyone should understand what it is and how it works, so that might have been aimed at a technical audience but without technical details.

After a bit more blather, he turned the presentation over to the Skytree presenter who opened with the statement that the company exists to “translate big data into actionable intelligence.” That is some differentiator…

While he also failed to give a good explanation for machine learning and how it differs from any other type of analytics, he at least had one good slide about his company’s focus.

Skytree market slide

Skytree for High-Value Problems

How they’re going to do that and how they’re different than their competitors? Well, as the old statement from textbooks says, that’s an exercise left to the student.

The Need for Product Marketing

The entire webinar failed and I, being the humble sort I am, know why. It was not vaguely technical enough for a technical audience nor specific enough for a business audience. They never clearly differentiated their products, sticking to very generic messages. That’s often a clear symptom of something missing from companies: Product marketing.

What they had was one technical guy from MapR and one supposedly marcom guy from Skytree, neither of whom understood how to position a solution in clear terms. The key job of product marketing is inherent in the two halves of the name, understand product and create accurate messages for the market. Unfortunately, smaller companies have founders working closely with development and sales, using marketing just to create basic collateral and presentations.

There doesn’t seem to be someone who knows the market the companies were really trying to hit or how to explain their differentiators to that market. That’s why the presentation spent lots of time on platitudes and almost none of a focused message to communicate differentiators.

There may be a good solution hidden in the partnership, but this presentation did nothing to show it.

Teradata Aster at the BBBT. Is a technology message sufficient?

Leave a reply

Last Friday’s visitors to the BBBT were from Teradata Aster. As you’ve noticed, I tend to focus on the business aspects of BI. Because of that, this blog entry will be a bit shorter than usual.

That’s because the Teradata Aster folks reminded me strongly of my old days before I moved to the dark side: They were very technical. The presenters were Chris Twogood, VP, Product and Services Marketing, and Dan Graham, Technical Marketing.

Chris began with a short presentation about Aster. As far as it got into marketing was pointing to the real problem concerning the proliferation of analytic tools and that, as with all platform products, Aster is an attempt to find a way to address a way to better integrate a heterogeneous marketplace.

As with others who have presented to the BBBT, Chris Twogood also pointed out the R and other open source solutions aren’t any more sufficient for a full BI solution managing big data and analytics that are pure RDBMS solutions, so that a platform has to work with the old and the new.

The presentation was then handed over to Dan Graham, that rare combination of a very technical person who can speak clearly to a mixed level audience. His first point was a continuation of Chris’, speaking to the need integrate SQL and Map Reduce technologies. In support of that, he showed a SQL statement he said could be managed by business analysts, not the magical data scientist. There will have to be some training for business analysts, but that’s always the case in a fast moving industry such as ours.

Most of the rest of the presentation was about his love of graphing. BI is focused on providing more visual reporting of highly complex information, so it wasn’t anything new. Still, what he showed Teradata focusing upon is good and his enthusiasm made it an enjoyable presentation even if it was more technical than I prefer. It also didn’t hurt that the examples were primarily focused on marketing issues.

The one about which I will take issue is the wall he tried to set between graph databases and the graph routines Aster is leveraging. He claimed they’re not really competing with graph databases which was, Dan posited, because they are somehow different.

I pointed out that whether graphs are created in a database, in routines layered on top of SQL or in Java, or were part of a BI vendor’s client tools only mattered in a performance standpoint, that they were all providing graphical representations to the business customer. That means they all compete in the same market. Technical distinctions do not make for business market distinction other than as technical components of cost and performance that impact the organization. There wasn’t a clear response that showed they were thinking at a higher level than technological differences.

Summary

Teradata has a long and storied history with large data. They are a respected company. The question is whether or not they’re going to adapt to the new environments facing companies with the explosion of data that’s primarily non-structured and having a marketing focus. Will they be able to either compete or partner with newer companies in the space.

Teradata is a company who has long focused on large data, high performance database solutions. They seem to clearly be on the right path with their technology and the implications are that they are in their strategic and marketing focus. They built their name focused on large databases for the few companies that really needed their solutions. Technology came first and marketing was almost totally technically focused on the people who understood the issue.

The proliferation of customer service and Web data mean that the BI market is addressing a much wider audience for solutions managing large amounts of data. I trust that Teradata will build good technology, but will they realize that marketing has to become more prominent to address a much larger and less technical audience? Only time will tell.

EXASOL at the BBBT: Big Data, fast database. Didn’t I just hear this?

Leave a reply

Friday’s EXASOL presentation to the BBBT brought a strong feeling of déjà vu. I’ve already blogged about the Tuesday Actian presentation and, to be honest, there were technical differences but I came to the same conclusion about the business model. But first, a thanks to Microsoft for the autocorrect feature. Otherwise typing EXASOL in all caps each time would have been bothersome.

The EXASOL presenters were Aaron Auld (@AaronAuldDE), CEO, and Kevin Cox (@KJCox), Director Sales and Marketing.

I mentioned technical differences. First, and foremost, they didn’t start with hardware but with an initial algorithm for massively parallel processing (MPP). They figured it was a great way to speed up database performance and stuck with columnar oriented relational technology. That’s allowed them to work on multi-terabyte systems with fast performance.

They have published some great TPC-H benchmark numbers, often being two orders of magnitude better than the competitors. While admitting that TPC stats are questionable since they’ve been defined by the big vendors to benefit their performance, often don’t reflect real life queries and often don’t use typical hardware, the numbers were still impressive. In addition, it was a smart business move as a small company blowing away the big vendors’ benchmarks helps elevate visibility and get them into doors.

However, let’s look back at Actian. They also talked about TPC, but they used the TPC-DS benchmark. How do you compare? Well, you can’t.

One other TPC factoid is, just like their competitor, there’s no clear information on true multi-user performance in today’s mobile age. No large numbers of connected clients was mentioned.

So results are great, but how do they fight the Hadoop bandwagon? They understand that open source is cheaper from a license standpoint, but also point out their performance saves in direct comparison when you total all costs for an implementation. People forget that while hardware prices have dropped, servers aren’t free.

Unfortunately, from a business model, it looks like they’re making the typical startup mistake of focusing on their product rather than business needs. They understand that ROI matters, but it seems to be too far down the list in their corporate messaging.

Another major advantage they have in common with the previous presenters is the sticking with SQL involves an easier build of ecosystem to include the existing vendors from ETL through visualization. However, they seem to be a bit further behind the curve in building those partnerships. While they have a strong strategic understanding of that, they need to bubble it up the priority list.

Exasol platform offering

One critical business success they have is their inclusion in the Dell Founders Club 50. That means advice and cooperation from Dell to help improve their performance and expand their presence. For a small company to have access not only to Dell at the technical level but also to bring customers to Dell Solution Centers for demonstrations is a great thing.

While they have been focused on MPP and large customers, the industry move to the Cloud also means they are looking at smaller licensing including a potential one-node free trial.

However, as mentioned in the lead, they seem to have the same business model issue as their competitors: They’re focused on the bleeding edge market who think the main message is performance. While they know there are other aspects to the buying decision, they went back, again and again, to performance. They have the whole picture in mind, but they’re not yet thinking of the mass market.

Organizations such as TDWI, Gartner and Forrester have all reported the high percentage of organizations that are considering big data and how to get a handle on the vast volume of information coming from heterogeneous sources. There’s clearly demand building up behind the dam. The problem seems to be they’re trying, as major IT organizations always do, to understand how best to integrate new technologies and capabilities with as little pain as possible. Meanwhile, the vendors seem to still be focused on the early adopters with their messaging. That leaves dollars on the table and slows adoption of new technology.

Summary

EXASOL seems to have a strongly performing and highly scalable database technology to work with large data sets. Yet, like many companies in the business intelligence space it comes back to audience. Are they still aiming at early adopters or will they focus on the mass market?

Have BI and big data advanced to the point where people need to think about the chasm and how to better address business needs not just technical issues. I think so, and I hope they adjust their business focus.

The company seems to have great potential, but will they turn that into reality? As the great Yogi Berra said, “It’s like deja vu all over again.”