This is the third instalment of a post examining the rather gushing and uncritical – not to mention re-cycled - coverage of the SAP HANA “in-memory” database technology in Scott M Fulton’s recent article entitled: “SAP's HANA: Accelerating Your Apps by 6 Orders of Magnitude”. In the first and second instalments I reviewed some of the challenges concerned with the development of in-memory database technology and briefly discussed the economics of storing all data in-memory. In this third and final instalment I will discuss SAP’s apparent lack of commitment to Enterprise – rather than departmental – analytics, and the likely consequences for the way that HANA will be deployed in practice.

How do you like your redundancy? Macro - or micro?

Fulton quotes SAP’s Global Solutions President, Sanjay Poonen, as claiming that data warehouses built on Teradata database technology result in the storage and movement of large volumes of redundant data. By contrast, SAP’s claim is that because memory accesses are (a) fast and (b) consistent - and because HANA will be at the centre of a vertically integrated SAP application stack - there will be no need for indexes and summary / aggregate tables, so that redundancy will be eliminated. However, in the very few benchmark situations where we have seen HANA head-to-head, our customers have reported to us that SAP consultants have extensively optimised the physical data model – often deploying between five and ten indexes on each table - and in some cases have had to pre-join tables just to get queries to run. Despite this extensive tuning, those same customers have reported to us that performance of complex, ad-hoc queries in particular has been (a) poor and (b) variable, with HANA unable to meet the Service Level Goals (SLG) specified in the benchmark tests (in all cases, we have run those same tests on Teradata 2690 Data Warehouse Appliance systems and successfully met or bettered those same SLG requirements). It turns out that faster storage access cannot compensate for weak cost-based optimisation and poor query planning.
 

(This is why, incidentally, the very selective “benchmark” details that SAP has put into the public domain all refer to star schemas – because a simple physical data model in which data are pre-joined and complex relationships are simplified is kinder to an unsophisticated DBMS optimiser. Of course, this pre-joining of data can also make more complex queries less efficient, or even impossible, which is why SAP architected it’s own flagship Data Warehouse solution – Business Warehouse (BW) - to include an integrated data layer, as well as the extended “InfoCube” star schemas. Star Schemas are great for providing a simplified view of complex data for end-users doing basic reporting and for optimising the performance of basic reports, where access paths are known in advance - but they have serious limitations for other important forms of analysis.)
 

In fact, Poonen’s assertion is anyway essentially inaccurate, precisely because we have worked very hard over the course of the last 10-15 years – with the support of partners like SAP BusinessObjects – to move both data integration and data manipulation processing into the database, wherever this is possible.
 

This was not always the case. Back in 1999 when I was a jobbing Data Warehouse manager trying to deliver a new report that required the derivation of a moderately complex metric based on data stored in three separate tables, BusinessObjects would try and copy all three tables to the client and try to join them there, ignoring the fact that the Teradata data warehouse platform where the data was stored was a sophisticated parallel computing platform designed for the very purpose of joining and combining data – and that the client was a Windows98 PC at the end of a mediocre Local Area Network. These days, any BI tool worth its salt – including BusinessObjects – instead creates a derived temporary table in the database to join the data from the three tables and calculate the derived metric “in database”. The only things that move across the LAN or WAN, mediocre or otherwise, are an SQL request in one direction – and an answer set in the other. There may be some “micro redundancy” of data in the Teradata database in the form of indexes and “semantic layer” summary and aggregate tables (we call these “raw data extensions”), but these constructs are typically used only sparingly in Teradata systems. And because they make the Data Warehouse data structures more comprehensible - so that more end-users are able to make sense of and explore the data - they are a price well worth paying.
 

By contrast I would contend that SAP has arguably the industry’s worst record on analytic data redundancy, bar none. Not only is data stored redundantly in each Business Warehouse instance in the form of multiple, overlapping InfoCube objects - an attempt to try and alleviate BW’s performance and scalability issues, which ironically results in the load performance issues that I discussed in the first instalment of this post – but SAP customers are typically also forced to deploy multiple, overlapping BW systems. In some cases this is because they are driven to partition their analytic data in an attempt to address the aforementioned BW performance and scalability issues; in other cases this is a consequence of the fact that some SAP applications require the deployment of specific BW instances. The reality is that BW is not so much an Enterprise Data Warehouse solution; rather it is a platform for the deployment of multiple, application-specific Data Marts.
 

As an example of how BW is typically actually deployed in practice, I spoke to an analyst from a leading research and consultancy firm recently who told me about an organization that had found it necessary to deploy seventy-five separate, customised BW instances. Yes, you read that correctly. Seventy-five. This is “macro redundancy”. On steroids. And next to it, a 25% raw data extension overhead is nothing, zip, nada.
 

In the same article, Poonen is quoted as claiming that SAP can migrate a 15,000 object BW physical data model from Oracle to HANA in only a few weeks – but what he doesn’t say is how many of those objects are redundant, the legacy of SAP’s attempts to mitigate BW’s historic scalability and performance problems. And since in the next breath he apparently talks about migrating all of those objects to HANA without modification, it’s very clear that migrating a BW installation from an Oracle DBMS platform to HANA will mean migrating, maintaining - and continuing to pay for - all of that complex legacy.
 

We can all agree that data redundancy is the problem: the redundant infrastructure and Systems Integration costs that result exponentially increase TCO; multiple, overlapping data sets, stored in multiple target data models on multiple analytic platforms and maintained by multiple ETL processes are invariably fatal for data quality and consistency; and without integration at the data model level, the cross-functional analysis that makes end-to-end optimisation (and re-engineering) of business processes simply isn’t possible. But it’s much harder to see any of SAP’s current products as part of the solution – and it’s not at all clear that SAP even recognises or acknowledges the extent of the micro- and macro-redundancy problems that it has.

It’s the culture, stupid

Why would SAP require its customers to deploy multiple, redundant, overlapping BW instances, just to deploy multiple analytical applications? After all, isn’t the whole point of building an Enterprise Data Warehouse (EDW) – a repository of integrated data so support Business Intelligence and Analytics – to store one, or close to one copy of the data, and to bring the applications to the data, and not the other way around?
 

The answer, I think, is that SAP is an applications company. Enterprise applications are the company’s heritage and culture; they are its DNA. SAP – despite its acquisition of BusinessObjects - simply isn’t an information management company, focussed on analytics – and it has never really understood Enterprise Data Warehousing in the way that the leaders in the industry do.
 

And apparently it still doesn’t. Even before it has demonstrated that HANA is a credible platform for large-scale Enterprise Analytics, SAP appears to be claiming that HANA will be The One Database To Rule Them All, able simultaneously to support all of an organization’s operational and analytical applications - despite the fact that if data are to be analysed as captured, without any transformation or modification to address data quality issues, it will require organizations to revolutionize their approach to information management and governance.
 

From a technology perspective, all of this would require mixed-workload management even more sophisticated than that found in Teradata’s industry-leading implementation – and HANA appears to lack any such capability. This technology issue aside, this level of Enterprise - rather than Departmental – integration is simply not possible without the sort of very robust industry logical data models that SAP apparently lacks. Instead, SAP will almost certainly default to the model it knows best – distributed deployment of multiple, overlapping analytical databases – and HANA will probably principally be deployed as an an analytic application acceleration technology. This market segment – Data Mart, and principally BW Data Mart performance acceleration - is the one that SAP’s management is really targeting with HANA; because simple, small-scale deployments of in-memory database technology will only be very – rather then extremely - expensive for its customers to deploy; and because they will not expose HANA’s technological shortcomings. SAP’s rhetoric about creating an affordable, scalable, high-performance platform for Enterprise Analytics is, at least for now, just that.

The song remains the same

So, as I explained in the first installment of this post, building a high-performance, scalable in-memory DBMS as a platform for Enterprise Data Warehousing presents SAP with some significant technological challenges - and as we discussed in the second installment, significant economic ones, too. And as we have seen in this third instalment, if SAP is serious about enabling Enterprise, rather than just departmental, analytics then it will need to fundamentally re-architect Business Warehouse so that it becomes a genuinely application-neutral Enterprise Data Warehouse.
 

Against that backdrop, Fulton’s article might have been interesting and timely had he examined SAP’s approach to overcoming these issues; had he assessed their progress in doing so; and had he identified any production references for HANA, complete with corroborated details.
 

Sadly, all Fulton has to share with us is a string of platitudes (“dramatic”, “revolutionary”, “turbocharger”) - and the uncorroborated claim that HANA has improved performance by a factor of 400,000 at one customer, which, we are told, represents an improvement of “six orders of magnitude”. Quite apart from the fact that these sorts of statistics are utterly meaningless when quoted without any context like this – indeed, as I have explained here before, are deliberately disingenuous and intended to obfuscate – an improvement of 400,000 represents, of course, five orders of magnitude, not six.
 

SAP’s marketing department is to be congratulated for generating so much hype around HANA that some journalists have got into the habit of repeating it verbatim, without apparently doing any even basic fact checking. Whether SAP’s Engineers deserve as much credit still remains to be seen - but on the evidence that is available thus far, HANA looks - to me at least - like an another Business Warehouse acceleration technology, rather than a credible Enterprise Data Warehouse platform. And given SAP’s historic approach to Business Intelligence – simple report-oriented and based on functional data silos - that should probably surprise no one.

Martin Willcox
Director of Platform & Solutions Marketing
Teradata (EMEA)
 

This is the second instalment of a post examining the rather gushing and uncritical – not to mention re-cycled - coverage of the SAP HANA “in-memory” database technology in Scott M Fulton’s recent article entitled: “SAP's HANA: Accelerating Your Apps by 6 Orders of Magnitude”. In the first installment I reviewed some of the challenges concerned with the development of in-memory database technology. In this second instalment I will discuss the economics of storing Enterprise Data Warehouse (EDW) scale data sets in memory.

Is memory getting cheaper faster than Data Warehouses are getting bigger?

Analyst firm Gartner reported at it’s January BI Summit in London this year that the unit cost of memory is falling by 30% every 18 months. However, the unit cost of memory is still an order of magnitude greater than the unit cost of magnetic storage – and the gap between these two costs shows no sign of closing. Not only that, but data volumes continue to increase exponentially. Reliable, industry-wide metrics for average growth rates of data warehouses are hard to come by, but the consensus amongst the practitioners that I speak to is that data warehouse growth rates are approximately 40% per annum, so that a data warehouse that was 10 TB in size at the end of 2011 is likely to be 20 TB in size at the end of 2013. In the face of these sorts of growth rates, Teradata CTO Stephen Brobst has described it as “economically irrational” for organizations to attempt to store all of their analytic data in-memory - especially since, as we have discussed, a copy of those same data will also then have to be stored on high-performance, persistent storage. And note that since “high-performance storage” increasingly means Solid State Storage (SSD) - cheaper than memory, but considerably more expensive than magnetic storage – this strategy means storing all of the data redundantly on the two most expensive storage tiers available to the system designer. 

A sure sign that SAP understands the economic implications of its in-memory strategy is the recent attempt made by Global Solutions President, Sanjay Poonen, to divert attention from the relatively high costs of HANA systems by instead labelling Teradata systems as expensive. In his article, Fulton quotes Poonen as suggesting that Teradata systems typically cost “$5 to $10 Million”. In fact, $10 Million in today’s money buys you a lot of Teradata Data Warehouse Appliance – enough at list price to comfortably store 300 TB of customer data - and the vast majority of our Hardware-and-Software sales come with a considerably lower price tag than this.
 

The 80/20 rule applies to storage access, too

So the first economic challenge for an in-memory Data Warehouse platform is that Data Warehouses appear to be getting bigger much faster than the unit cost of memory is getting smaller. And there is a second economic challenge, too, because it turns out that the “Paretto” or “80/20” rule applies to storage access, too.

What that means in practice is that 80% of the time, users are accessing just 20% of the data in the Data Warehouse. This 20% of the data is “hot” – meaning accessed frequently. Storing this sub-set of the data on a high-performance and relatively expensive storage medium makes perfect sense; it’s storing the balance of the data in the same high-performance and relatively expensive storage medium that is “economically irrational”.

The catch in all of this is that the temperature of data are changing continuously. Some of the changes in the temperature of the data are entirely predictable; in general newer data are hotter than older data. Some of the variation is more complex, but also somewhat predictable; financial data, for example, get progressively warmer at month- and quarter-end. And some of the variation is entirely unpredictable - for example, if your CEO suddenly decides to buy your closest rival and as a consequence you need to undertake a detailed analysis of the overlap between your current operations and theirs, this sub-set of your data will warm very rapidly indeed.

Which is why our own Teradata Virtual Storage (TVS) sub-system enables Teradata systems to automatically measure how frequently data are accessed at a very fine level of granularity - and to automatically migrate just the hottest data to high-performance Solid State Storage (SSD). Precisely because all data are not created equal, applying relatively expensive, high-performance storage technologies selectively and where they can deliver the most bang-for-the-buck is the economically rational approach to exploiting them.
 

Losing bet?

SAP appears to be betting on the unit cost of memory falling faster than the rate at which analytic data sets are getting larger. And as we have seen, at least as far as Enterprise Data Warehousing is concerned, that looks like a losing bet. Since SAP is a well managed company, probably its management know this to be the case. All of which means that appearances are probably deceptive - and that SAP’s management is actually targeting an altogether different market opportunity. More on this next time.

Martin Willcox
Director of Platform & Solutions Marketing
Teradata (EMEA)


 

No one can accuse Scott M Fulton, author of a recent article entitled “SAP's HANA: Accelerating Your Apps by 6 Orders of Magnitude” of not having a sense of humour; his own profile states that “many of the world's recycled goods and paper products, from packing containers to park benches, are made from Scott's manuscripts from the 1990s.” His latest article takes this gag to its logical extreme; it isn’t so much that it is destined to be re-cycled - more that it consists almost entirely of re-cycled SAP quotes. Which is a shame, because there is an interesting debate about how best to exploit the latest advances in computing hardware - so that organizations can “do more with their data” - that Fulton’s article fails to examine critically. Or even at all.

To do what Fulton doesn’t, we need to introduce some physics. But stay with me, I’ll go slowly!

 
All modern computing systems are based on the “von Neumann” or “stored instruction” computing model. Instructions - and the data on which they operate - are stored in persistent storage and both follow the same path to the processor (the component where the computation is actually performed); off the storage; across an interconnect or “bus”; into memory; back out across the bus; and, finally, into the memory registers on the processor.

The genius of the Von Neumann architecture is its flexibility; the “stored instructions” are software - and we can change the functionality of the machine just by replacing or changing the software. Once upon a time, computers were hard-wired - and computer scientists had to set switches and insert patch leads to make them do different things between “runs”. This is not a programming model that plays well outside secret code-cracking facilities and atomic weapon research labs stuffed full of highly-trained scientists and engineers. By contrast, the “stored-program” model pioneered by von Neumann and friends gave birth to the whole modern ICT industry in which we are all employed today. And this flexibility is arguably nowhere more important than in data warehousing and analytics where, by definition, the questions that we ask - and hence the queries that we run against the database – evolve and change continuously.

There is a catch, however. Whilst processor speeds have increased by a factor of five million over the course of the last 30 years, disk access speeds have increased only by a factor of five. Persistent storage, has, historically at least, consisted of magnetized spinning platters – and making them spin faster whilst ensuring that we can still read the data encoded on them accurately turns out to be much harder than the semiconductor physics that has driven the improvements in processor performance and memory latency. 

The consequence of all of this is that when a von Neumann processor is asked to perform relatively simple calculations on large volumes of data, the processors are often sat idle, waiting for the data that they need to continue working. Which is why, of course, Massively Parallel Processing (MPP) systems like Teradata systems spread those large volumes of data across multiple disks attached to multiple computers (“nodes”). If you engineer an MPP system well enough to remove the other bottlenecks, then the “I/O bandwidth” (the rate at which you can get data off the storage) available to each computing node is a function of the number of disk spindles attached to it; and in this way you can make sure that there are sufficient disk spindles available to “saturate” the computing node so that it can get the data it needs just as fast as the bus connecting the storage, memory and processor - and the physical separation between them - will allow.

But what if you could just bust the storage bottleneck? Existing database management systems do, of course, exploit memory by “caching” frequently accessed data in memory – but if you could just take the persistent storage completely out of the equation by storing all the data in memory, then you could potentially improve performance by several orders of magnitude where there is a “cache miss”. This is the promise of in-memory database technology – and SAP’s new HANA product is the poster-child for in-memory database technology.

Weighing the in-memory technology trade-offs

Engineering is, of course, fundamentally about trade-offs – and there are a couple of important trade-offs that have to be taken into consideration where in-memory technology is concerned.

The first issue we have to consider is persistence. Memory is not persistent; if there is a system failure, the data in memory are lost. So if we are going to build an “in-memory database”, we also have to keep an additional copy of the data on persistent storage; and if we want to be able to recover data quickly after a system failure, then the redundant data will need to be stored on an expensive, high-performance, high-availability storage sub-system. Not only that, but we cannot ever really consider that data are “stored” until they are written to the persistent storage layer, so in-memory architectures don’t by themselves do anything to improve load performance, which has traditionally been a very significant issue for organizations that have deployed SAP’s flagship Data Warehouse solution, “Business Warehouse” (BW), as most of the industry still refers to it. (We’ll discuss whether BW should actually be considered a Data Warehouse solution in part 3 of this post. 

The second issue that we have to consider is the nature of the problem that we are trying to solve. Remember that the “von Neumann bottleneck” is acute where we are performing relatively simple calculations on large volumes of data (an “I/O bound” workload) – but if the rate limiting factor is the not the time it takes us to access the data, but rather the complexity of the calculations that we then perform on them (a “CPU-bound” workload), then storing the data in-memory to reduce “access latency” doesn’t help. And since data warehousing is increasingly about sophisticated, predictive analytics, rather than just basic reporting, data warehouse workloads are becoming increasingly computationally intensive.

The third issue that we need to consider is how to scale the computing system. There are essentially two ways that we can add compute power: we can “scale-up” by adding more CPUs to the system that share the same memory-space and storage (a “multi-processor” architecture); or we can “scale-out”, by adding more CPUs that don’t share computing resources (a “shared nothing multi-computer” architecture). Because sharing computing resources results in contention for those resources, scale-out architectures scale very, very much better than scale-up architectures - particularly for workloads, like complex queries running over large data sets that are not localized and cannot easily be confined to execute in a discrete partition. For this reason, just about all of the data warehouse platform vendors have adopted some variation of the multi-computer architecture.

Moving intermediate result-sets around the multiple computing units of a shared nothing system requires us to ship data across a network, introducing a new potential bottleneck. In Teradata systems, this challenge is addressed by carefully managing – and minimising – the amount of inter-process communication and by avoiding the requirement to perform all sort / merge processing on a “co-ordinator” node. But since networks run slower than memory, if the designer of a parallel computing system doesn't go to the (significant) lengths that Teradata’s original designers did to avoid unnecessary data shipping, the performance of complex workloads on a scale-out, multi-computer architecture are ultimately limited by the performance of the interconnect. In this scenario, storing the data in memory does not remove the bottleneck - it just moves it to another part of the computing system. 

And because CPUs are getting faster more quickly than memory is getting faster, a fourth technology challenge looms just over the horizon for in-memory database technology, as a rapidly widening gap between the performance of processors and the performance of memory opens up. Those commentators that claim that “memory is the new disk” should perhaps be more careful what they wish for.

There is an even more immediate hurdle to the widespread deployment of in-memory database technology for analytics: cost. More on that issue in the next installment of this post.

And in part 3, we will discuss whether HANA enables SAP to address the micro and macro data redundancy issues that plague many BW deployments.

Martin Willcox
Director of Platform & Solutions Marketing
Teradata (EMEA)

 

This is a very special day for Teradata and especially for Teradata here in Europe. We have some exciting news to share: We just signed a definitive agreement to acquire eCircle, the European leader in cloud-based digital marketing. This is very exciting for both companies and it is a strategic step for Teradata. After acquiring Aprimo, a global leader in cloud-based integrated marketing software last year, we continue to invest in marketing applications.

First of all I am thrilled to welcome great knowledge, experience and consulting power to our Teradata and Aprimo team. Together with eCircle we will more than triple our Aprimo team in Europe creating the largest marketing applications provider in Europe. 

The digital marketing space is an exciting space to be in. It is growing quickly in both the US and Europe. Digital Marketing which includes social, mobile, web and email is an essential focus for marketers. Forrester¹ estimates the digital marketing market to be a $6 billion market opportunity today, growing to $16 billion by 2016. 

I am convinced that the great combination of Teradata’s analytical capabilities, Aprimo’s Integrated Marketing Management and eCircle’s digital messaging solution will enable marketers worldwide to create integrated customer experiences across online and offline channels that leverage Big Data insights to grow existing customers, attract new customers, and increase revenues. For Teradata this makes a lot of sense since according to McKinsey², the world’s data is doubling every two years and digital campaigns are the source of some of the largest and most complex big data sets used by marketers. 

So, the addition of eCircle’s visionary digital marketing applications to Teradata and Aprimo enhances Teradata’s big data market opportunity. We intend to leverage Big Data Analytics to unlock the insights of these combined digital data streams, and provide marketers with the capability to perform effective digital marketing optimization in a way that is not possible with any other digital marketing technology. 

 
Today is a very special day both for Teradata and eCircle and I look forward to having our dedicated Teradata team joined by the highly skilled people from eCircle.

We will keep you posted on our joint roadmap that will continue helping our customers stay ahead of the competition.

Hermann Wimmer
 

¹Forrester Research Inc., US Interactive Marketing Forecast, 2011 To 2016, September 2011
²McKinsey Global Institute report titled Big Data: The Next Frontier for Innovation, Competition, and Productivity, June, 2011.

There was a pattern showing in yesterday’s many sessions and debates that goes a little further than my thesis that we are in the midst of the moment when data analysis is going mainstream and that it helps enterprises find key differentiators in more and more markets. Erik Brynjolfsson has shown in a study that “data-driven enterprises” generally fare significantly better than the rest. And it was him who more or less spelled out the idea that I have seen validated at this event for a few times by now: when data analysts start working in a new field, they tend to come up with good ideas, even when they have little experience or expertise in the particular industry. Sometimes these ideas lead to little improvements, sometimes they have the potential to transform the whole business. My point is, though, that many of those ideas can inspire similar solutions in other industries. This is why I said yesterday that I want our Universe conference to be the number one event for “data junkies” where our customers get the opportunity to learn from other customers.

Just to give you a striking example from Brynjolfsson’s keynote: He and his colleagues figured that house buyers reveal their purchasing interest by surfing the internet, which usually begins with searching Google or other engines. The analysts took these data and succeeded in predicting house sales more precisely than official experts – without having much knowledge of the real-estate business. Brynjolfsson also reported how Android GPS data can be used to predict traffic jams (even if they are made of pedestrians) or spot the latest in-place at the local bar scene. This is an experience shared among many customers: once you’ve got the visibility, you get the agility, too. For example, Southern California Edison (SCE) was able to respond faster to blackouts caused by a heavy storm, because they could quickly identify households that were cut off thanks to the smart meters they have deployed in millions of households.

One more example from our media roundtable: Stephen Brobst mentioned an insurance company that explored new ways to turn its data into value and found that they provided formidable input for credit risk ratings – after all, someone with loose driving habits is more likely to have loose spending habits as well. The debate during this event was quite lively. Most panellists including Michio Kaku and Mike Breitenbeker of Overstock.com agreed that statistical skills were key for careers in the age of big data, with the exception of data warehousing veteran Barry Devlin who predicted that data growth was actually approaching an inflection point simply because “it has to change”. Everyone agreed that “tools make excellent servants and poor masters”, as Martin Willcox put it, meaning that the genuine human element in analysis was indispensible. But what exactly defines this human element? No two panellists seemed to agree here. Theoretical physicist Kaku, for example, listed intuition, emotion and humour. Brobst pointed out that science without art leads to stagnation, whereas Devlin said, “we can be fascinated by moving bars – but it’s the intent that counts. How I want to run my business, how I want to live!” Maybe, in the end, it’s the diversity that creates the human added value.

Hermann Wimmer

 

Our main news today is that we have announced the Teradata Active Data Warehouse Private Cloud. This capability will allow CIOs to reap the benefits of cloud technology to a much higher extent than before and improve the availability of enterprise data for business intelligence purposes. It will do away with the typical shortcomings of alternative cloud offerings: In many companies, for example, a mere 25 percent of the processing power of virtualized servers is being utilized, according to Gartner – a huge waste of resources. This rate may be acceptable for public cloud offerings but then they lack the performance and availability to support BI workloads effectively. Teradata ADWs, on the other hand, have been providing customers with 90 to 100 percent utilization, while the consolidation of legacy data marts (some of them with a utilization rate of only 10 percent) into a single, central data warehouse has been saving companies significant amounts of capital and operating expense for many years. With today’s offering, which includes Teradata Elastic Performance on Demand, enterprises can quickly activate additional computing power when there is a sudden surge in demand based on a pay-per-use model. Teradata customer Belgacom already makes use of a Teradata capacity-on-demand offer: The Belgian market leader has recently expanded its analytics platform to accommodate data growth, enhance its customer experience management and deliver personalised campaigns. If the occurring growth exceeds the company’s predictions, it will easily get access to additional system resources.

Data analysis has become mainstream
Scalability has always been our key differentiator. And as an independent enterprise, we continue to grow in terms of scale and scope: We now have more than 1,300 customers and employ over 8,600 experts worldwide. Our revenue has grown to 2.36 billion dollars in 2011, with the strongest growth of 24 percent taking place in the EMEA region. Consulting services have significantly contributed to this growth. And then there is also Teradata Aster and Aprimo with their respective portfolios. Our CEO Mike Koehler said today that data warehousing is in our DNA – we invented the whole discipline. These days, data analysis seems to be taking centre stage. Data is being recognized as the “new oil”, its utilization is considered to be the most important growth driver for the near future. Just look at Ireland to prove this right, enjoying the highest growth rates for a decade by boosting its knowledge-based sectors. Or consider Facebook: it’s worth an estimated 100 billion dollars – but how much would it be without its data?

New growth segments: utilities and digital entertainment
The utilities are one of the industries where Teradata’s business is growing fast at the moment. Today, we announced that British utility giant Centrica (market capitalization of more than £16 billion, ranked among the top 30 of London’s FTSE100), is having an Enterprise Data Warehouse built on the Teradata Data Warehouse Appliance, using the Teradata Logical Data Model for the Utilities. Centrica, like many other players in the industry, is facing massively growing data volumes, new data types (think Smart Grid here) and the need for more detailed customer insight. Thus the company has also purchased Teradata applications for data mining and customer management.

The world’s largest online gaming company, bwin.party, has also joined the ranks of Teradata’s customers. bwin.party operates one of the world’s largest online poker networks. The company is currently working on a more widely available self-service business intelligence and strives to create a Single Customer View across all gaming verticals as well as to reduce operating costs.

Now, this has been a lot of news, while the conference has only just begun. I’ll come back to you Tuesday night with more details about on-going projects in the utilities as well as other industries that continue to find new ways of generating value from analytics year after year. For the moment, good-bye and enjoy the conference!

Hermann Wimmer