Making the Insurance Policyholder Experience Better

How AOK Niedersachsen leverages IBM’s Cognos BI reporting and PureData System for Analytics  for improving policyholder service

AOK Niedersachsen, a German health insurance provider, was facing increased competition, a stricter regulatory environment, and the need for more transparency. With members numbering 2.4 million in 2013 and over 40,000 health care provider partners, AOK Niedersachsen realized they had both a Big Data problem and an opportunity to improve service. Their realization was that corporate data has to be accurate, delivered more quickly, and easily accessible to a wider range of corporate decision makers.

How AOK changed their business practices

AOK Niedersachsen aligned with an IBM business partner, novem business applications GmbH (novem), to reorganize AOK Niedersachsen’s data infrastructure to build a one-version-of-the truth data repository. The requirements included utilizing the existing corporate performance metrics for continuity, while extending graphical and visualization capabilities for the reporting system. The analytics and reporting also needed to be rolled out to more than 700 AOK Niedersachsen decision makers. To implement these requirements, the designers decided that IBM Cognos for Business Intelligence reporting, and IBM’s PureData System for Analytics for the advanced analytical data warehouse were the right combination.

Technology Solution Description

Before sorting through the solution details, it is interesting to note that AOK Niedersachsen utilized a video podcast to educate its user base on the new applications. This enablement tactic promoted a high degree of user acceptance for the new system. The 750 decision-making users (up to and including the CEO) query a database of over 500 data tables and roughly 1.5 billion records. IBM Cognos manufactures the dashboards that transform the raw numbers into effective visualizations. These graphical representations reflect high level aggregations which can then be drilled into for lower level, component data by the inquisitive business person. Simulation algorithms show possible outcomes prior to a manager’s decision choice. IBM Cognos Mobile is another platform option via an employee’s Apple iPad.

The resulting installation delivered these business benefits: queries 100 times faster than from the previous system, significantly decreased operational costs, and more informed, fact based decisions. And the best part is optimized treatment services for AOK Niedersachsen’s policyholders.

Much faster performance delivered by the PureData appliance, helps in many ways, including acceptance by the line-of-business user. There’s nothing like dropping one query from 25 hours down to three minutes elapsed time (500X faster) to get buy-in. Adding more details is AOK Niedersachsen’s Elke Stump, “With the IBM PureData System for Analytics, we finally have the right degree of performance for our IBM Cognos Business Intelligence system. We have even been able to reduce 
the time taken for administration tasks significantly. Performance optimization is no longer an issue.” 1

Summary

Reducing risk and playing the odds are sound business practices in the insurance industry. Keeping customers satisfied with good products and thoughtful services works well in any industry. AOK Niedersachsen contracted with IT partner novem, to design and install a Business Intelligence (Cognos) and Data Warehouse (PureData System for Analytics) based on IBM technology. The resulting installation delivered these business benefits: queries 100 times faster than from the previous system, significantly decreased operational costs, and more informed, fact based decisions. And the best part is optimized treatment services for AOK Niedersachsen’s policyholders.

 

Please share your thoughts or questions in the comments.

For more details in German, visit: AOK German PDF
For more details in English, visit: AOK English PDF

About Rich,

Rich HughesRich Hughes is an IBM Marketing Program Manager for Data Warehousing.  Hughes has worked in a variety of Information Technology, Data Warehousing, and Big Data jobs, and has been with IBM since 2004.  Hughes earned a Bachelor’s degree from Kansas University, and a Master’s degree in Computer Science from Kansas State University.  Writing about the original Dream Team, Hughes authored a book on the 1936 US Olympic basketball team, a squad composed of oil refinery laborers and film industry stage hands.


1 “AOK Niedersachsen significantly improves policyholder service” by IBM Staff, April, 2015.

IBM DB2 Analytics Accelerator: OLTP and OLAP in the same system at last! (Part one)

By Isaac Moreno Navarro

With the advent of the data warehouse, the possibility of using the same infrastructure for online transaction processing (OLTP) as well as for online analytical processing (OLAP) has become a controversial subject. You will find that different database vendors have different points of view.

Let’s explore this topic by starting with a brief explanation of OLTP and OLAP.

Online transaction processing (OLTP)

This is the traditional way databases used to work – by placing small queries against a low number of rows and retrieving information. For instance, when you buy an airplane ticket, you check the open seats in a given flight and the price. To achieve this, several small queries are served by the database in a short period of time, and the data involved in the answer is a small set of the data stored.

Online analytical processing (OLAP)

In the case of OLAP, you send very heavy queries that need to process a huge amount of data in comparison to the total size of the database. You send fewer queries to your system, but very heavy ones. In our airline example, if you were working in marketing you might want to know how many people between 20 and 35 years old traveled from New York to Madrid during 2014, grouped by fares and describing how far in advance they purchased their tickets.

So, we have different uses for the same set of data. In this scenario, some database vendors offer a one size fits all solution, suggesting that just one machine is able to address such different workloads at the same time.

IBM Hybrid Approach to Transactional processing and analytics

Through IBM DB2 Analytics Accelerator, IBM supports a different approach. This DB2 Analytics Accelerator, together with DB2 for z/OS, form a self-managing, hybrid workload-optimized database management system that runs each query workload in the most efficient way. With this approach, you avoid the headaches involved with the configuration of a database designed for OLTP that is also trying to serve OLAP workloads. This is the main reason why many data warehouses are difficult to manage, expensive to maintain and require many people to tune them—while still producing frustrated end-users.

IBM DB2 Analytics Accelerator turns DB2 for z/OS into a universal database management system, capable of handling both transactional and analytical workloads.

 IBM DB2 Analytics Accelerator

IBM proposes the use of a hybrid environment where each query workload is executed in the most optimal environment for maximum speed, execution and cost efficiency. This hybrid infrastructure blends the best attributes of symmetric multiprocessing (SMP) leveraging DB2 for z/OS with the best attributes of the hardware-accelerated massively parallel processing (MPP) architecture delivered by Netezza technology.

The hybrid environment is enabled by the addition of the DB2 Analytics Accelerator, a high-performance appliance that integrates the z Systems infrastructure with PureData System for Analytics, powered by IBM Netezza technology.

And yes, it is only for DB2 for z/OS, at least for now.

This solution generally works as if you just added another access path  that is specialized for processing analytic queries to your mainframe. Because it is just like an additional access path, query processing happens transparently so that users and applications can send the very same DB2 query requests to the system, unchanged.

The interface for the end-user does not change at all. And when I talk about an “additional access path”, what I really mean is that we add the DB2 Analytics Accelerator to complement DB2 for z/OS, which is built for transactional workloads. The Accelerator provides a cost-effective high-speed query engine to run complex analytics workload. Therefore, IBM DB2 Analytics Accelerator turns DB2 for z/OS into a universal database management system, capable of handling both transactional and analytical workloads.

IBM DB2 Analytics Accelerator_image
Diagram of DB2 for z/OS and DB2 Analytics Accelerator for z/OS

 

As you can see, there are two different machines, each one solving different workload needs working as one system. As part of its unique design, the DB2 Analytics Accelerator includes breakthrough technologies to reroute complex, data-intensive queries to the integrated IBM PureData System for Analytics appliance. But the key point is that nothing has changed for the end user when compared to their traditional DB2 database, except that suddenly the analytical queries run much faster than before, with MIPS consumption decreasing. So, although you have two machines, they compound into a single system for the end users. And from the point of view of the administrators, there is no added complexity either.

DB2 Analytics Accelerator includes breakthrough technologies to reroute complex, data-intensive queries to the integrated IBM PureData System for Analytics appliance. But the key point is that nothing has changed for the end user when compared to their traditional DB2 database, except that suddenly the analytical queries run much faster than before . . .

In the words of one of our customers: “We are surprised how easy it is to manage such a system, it is really ‘plug-and-play’ and the results are awesome”.
This concludes my introduction. In following posts I’ll explain how DB2 Analytics Accelerator works, as well as real life experiences with it. To learn more, visit the DB2 Analytics Accelerator page on ibm.com.

Meanwhile, you can leave your comments, share your experience or join me on a conversation on Twitter.

See additional posts

IBM DB2 Analytics Accelerator: OLTP and OLAP in the same system at last! (part two)

About Isaac,

Isaac Moreno NavarroIsaac is working as a data warehouse and Big Data technical pre-sales professional for IBM, covering customers in Spain and Portugal, where his special focus is on PureData for Analytics. He joined IBM in 2011, through the Netezza acquisition. Before that, he has held several positions in pre-sales and professional services in companies such as Oracle, Sun Microsystems, Netezza and other Spanish companies. During the years previous to working at IBM, he has acquired a diverse experience with different software tools (databases, identity management products, geographical information systems, manufacturing systems…) in a very diverse set of projects. He also holds a Master of Science Degree in Computer Science.

What is the fundamental difference between “ETL” and “ELT” in the world of big data?

By Ralf Goetz

Initially,  it seems like  just a different sequence of the two characters “T” and “L”. But this difference often separates successful big data projects from failed ones. Why is that? And how can you avoid falling into the most common data management traps around mastering big data? Let’s examine this topic in more detail.

Why are big data projects different from traditional data warehouse projects?

Big data projects are mostly characterized as one or a combination of these 4 (or 5) data requirements:

  • Volume: the volume of (raw) data
  • Variety: the variety (e.g. structured, unstructured, semi-structured) of data
  • Velocity: the speed of data processing, consummation or analytics of data
  • Veracity: the level of trust in the data
  • (Value): the value behind the data

For big data, each of the “V”s is bigger in terms of order of magnitudes of its classification. For example, a traditional data warehouse data volume is usually around several hundred gigabytes or a low number of terabytes, while big data projects typically handle data volumes of hundreds or even thousands of terabytes. Another example would be that traditional data warehouse systems only manage and process structured data, whereas typical big data projects need to manage and process both structured and unstructured data.

Having this in mind, it is obvious that traditional technologies or methodologies for data warehousing may not be sufficient to handle these big data requirements.

Mastering the data and information supply chain using traditional ETL

This brings us to a widely adapted methodology for data integration called “Extraction, Transformation and Load” (ETL). ETL is a very common methodology in data warehousing and business analytics projects and can be performed by custom programming (e.g. scripts, or custom ETL applications) or with the help of state-of-the-art ETL platforms  such as IBM InfoSphere Information Server.

Extract Transform Load Big Data

 

The fundamental concept behind most ETL implementations is the restriction of the data in the supply chain. Only data, which is presumably important will be identified, extracted and loaded into a staging area inside a database, and later, into the data warehouse. “Presumably” is the weakness in this concept. Who really knows which data is required for which analytic insight and requirement as of now and tomorrow? Who knows which legal or regulatory requirements must be followed in the months and years to come?

Each change in the definition and scope of the information and data supply chain requires a considerable amount of effort, time and budget and is a risk for any production system. There must be a resolution for this dilemma – and here it comes.

A new “must follow” paradigm for big data: ELT

Just a little change in the sequence of two letters will mean everything to the success of your big data project: ELT (Extraction, Load and Transform). This change seems small, but the difference lies in the overall concept of data management.  Instead of restricting the data sources to only “presumably” important data (and all the steps this entails), what if we take all available data, and put it into a flexible, powerful big data platform such as the Hadoop-based IBM InfoSphere BigInsights system?

graphic 2

Data storage in Hadoop is flexible, powerful, almost unlimited, and cost efficient since it can use commodity hardware and scales across many computing nodes and local storage.

Hadoop is a schema-on-read system. It allows the storage of all kinds of data without knowing its format or definition (e.g. JSON, images, movies, text files, spreadsheets, log files and many more). Without the previously discussed limitation in the amount of data which will be extracted in the ETL methodology, we can be sure that we have all data we need today and may need in the future. This also reduces the required effort for the identification of “important” data – this step can literally be skipped: we take all we can get and keep it!

Without the previously discussed limitation in the amount of data which will be extracted in the ETL methodology, we can be sure that we have all data we need today and may need in the future.

Since Hadoop offers a scalable data storage and processing platform, we can utilize these features as a replacement for the traditional staging area inside a database. From here we can take only the data that is required today and analyze it either directly with a business intelligence platform such as IBM Cognos  or IBM SPSS, or use an intermediate layer with deep and powerful analytic capabilities such as IBM PureData System for Analytics.

Refining raw data and gaining valuable insights

Hadoop is great for storage and processing of raw data, but applying powerful and lightning fast complex analytic queries is not its strength, and so another analytics layer makes sense.  PureData System for Analytics is the perfect place for the subsequent in-database analytic processing for “valued” data because of it’s massive parallel processing (MPP) architecture and it’s rich set of analytics functions. PureData can resolve even the most complex analytic queries in only a fraction of the time compared to traditional relational databases. And it scales – from a big data starter project with only a couple of terabytes of data to a petabyte-sized PureData cluster.

 PureData System for Analytics is the perfect place for the subsequent in-database analytic processing for “valued” data because of it’s massive parallel processing architecture (MPP) and it’s rich set of analytic functions.

IBM offers everything you need to master your big data challenges. You can start very small and scale with your growing requirements. Big data projects can be fun with the right technology and services!

About Ralf Goetz 
Ralf GoetzRalf is an Expert Level Certified IT Specialist in the IBM Software Group. Ralf joined IBM trough the Netezza acquisition in early 2011. For several years, he led the Informatica tech-sales team in DACH region and the Mahindra Satyam BI competency team in Germany. He then became part of the technical pre-sales representative for Netezza and later for the PureData System for Analytics. Ralf is still focusing on PDA but is also supporting the technical sales of all IBM BigData products. Ralf holds a Master degree in computer science.