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 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.
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.
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.
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?
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.
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.
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”.