Welcome to the first article in The Friday Night Project series, where we'll starting with a background on the nature and role of the Enterprise Data Warehouse.

The Evolution of the Enterprise Data Warehouse (EDW)

The traditional Enterprise Data Warehouse (EDW) is often seen only in terms of the Strategic Reporting environment, which leads to a misconception as to the ability of the EDW to also be used as an Active Data Warehouse (ADW).

The line between EDW and ADW continues to dissolve as the EDW, with it’s single version of all of the data about a given enterprise, becoming the Data Source of choice behind applications that are used 9 to 5 by Subject matter Experts, which starts to make it part of the Daily Operations of the business and quite possibly Mission Critical whether that be through actual lost revenue or just lost opportunity.

The Evolution of the EDW User

Ultimately any Data in a Database is useless if no one uses it, so it is appropriate to put the different “users” of the EDW/ADW in perspective. As suggested above the application environment within which the EDW/ADW exists is changing, moving beyond the traditional, generic, BI tools into the world of Subject Matter Experts whose time is spent exclusively using an application that relies upon the EDW data. Beyond them we start moving towards an increasing number of Tactical, Operational, Opportunistic, Device and System users as illustrated below.


So we need to support Single Expert Users like a TRM Campaign Designer or a DCM Forecast Modeller that uses their application 100% of their time through 10s of Tactical users like Campaign Owners or Retailer Buyers who might only dip into results or forecasts 10% of their time into hundreds of Opportunistic users like Call Centre operatives, Point of Sales systems and enterprise Systems that only query the Application 1% of their time and beyond to the thousands of Devices like ATM’s, Kiosks and Delivery Vehicle GPS systems whose lowly 0.1% usage of the application multiplies up significantly due to their sheer volume.

Why: #1 Reuse of Algorithms and Data

Many ADW Applications are typically an adjunct to or a reuse of existing algorithms and data. So taking Demand Chain Management (DCM) as an example, we would already have the Inventory and Shipment Data plus algorithms like allocation, forecasting and shipment available as part of the EDW Database/Tables associated with DCM.

Now Lets think about how in a Web 2.0 World we might create a Delivery Manager Portlet as a “Mashup” integrating external data like Google Maps with ADW information from the same DCM Data in order to provide a Portlet interface to the Dispatch Manager tied directly to the GPS tracking systems on the delivery vehicles.

Say there’s an accident or traffic situation that incapacitates a delivery vehicle, a simple click on a map within a Portlet could deploy the power of Teradata and the DCM Shipment algorithm to find the Next Best Routing and delivery schedule for the remaining vehicles. Through the reuse of Algorithms and Data it is possible for anyone within the organization to activate the power of Teradata to satisfy their immediate business need.

Why: #2 Customer Retention

Clearly everyone wants to improve customer service and retention (it is always cheaper to retain than acquire). What if you have a Call Center agent resolving a customer issue, perhaps incorrect Telco Billing or a disputed Credit Card transaction?

Call Center integration

In addition to the agent’s primary display could we develop Portlets that can be triggered from their main screen? So if triggered by Incorrect Billing the Portlet would interrogate the EDW/ADW for customer history (does this happen a lot to this customer or is it the first time). Perhaps like the DCM example above it might be possible to run a restricted Customer Relationship Management (CRM) algorithm against just the current customer in order to find and present the top 3 retention offers to the agent, so we can put them back “in the loop” and let them decide the best way to deal with each situation.

Why: #3 Customer / Business Integration

Integration across the whole business, across all the points of interaction is a fundamental desire for all businesses. As the point of Customer Integration with the Business becomes increasingly virtual the need for Active Integration from these “Points of Presence” with the underlying EDW/ADW becomes more important.

Consider the 600 Billion seconds of “Please Wait while I process your transaction” shown on ATM’s each year.

What if you could use that time to communicate 1 to 1 with your customer?

Can you develop; say a Web service interface that based on the Account ID from the Bank Card could execute a “Tactical” Offer table lookup or a “Next Best Offer” calculation against the EDW / ADW?

Note: this isn’t a one way conversation, the customer can respond, through the ATM, to accept or reject the offer presented which means you need to be able to write responses back into the EDW / ADW.

Toto, I've a feeling we're not in Kansas anymore.

So clearly we have moved on from the traditional EDW environment and are heading for a much more Active environment where Enterprise Applications wish to become much more integrated with the underlying “Persistence Mechanism” and currently do not understand the implications for Enterprise Application of Teradata as an Active Data Warehouse.

In the next Friday Night Project article we will start to define “How” to build the Solid Architecture required to address the previous Active Integration “What” and “Why”.

dmg 5 comments Joined 05/09
28 May 2009

Writing back to the EDW everytime for every user on the ATM!! This sounds like using Teradata as a transactional database. I really have felt Teradata's speed in joins, aggregations of millions or rows. But this is something interesting!
But, how good is Teradata at this ? Is there a fact sheet about doubling Teradata's usage also like a transactional system?

Mikec 21 comments Joined 03/09
15 Jun 2009

Sorry dmg, didn't spot this comment from a couple of weeks back. The ATM Application is an interesting case in that we are using Teradata in a Tactical Read approach. The belief is that there may be active offers available for something like 3 in a 1000 customers, some smaller proportion of whom might actively accept or reject a given offer, resulting in a write operation. So we are not operating like a Transactional Host in this case (performing Account Debit transactions), however, with advanced workload management approaches Teradata can certainly support traditional EDW along side this new ADW workload.

You must sign in to leave a comment.