|
TECH2TECH
When worlds collide
Gaining value from converging environments
by Kimberly Stanick
Converge: verb. To come together at a point.
Consolidate: verb. To combine; to join; to unite.
Integrate: verb. To make whole by bringing parts together; to blend; to merge.
|
Efficiency is a top goal in the frenzy of our daily lives.We often want to complete multiple tasks with one action-the proverbial killing of two birds with one stone-like stopping by the dry cleaner on your way to the market. In our quest for efficiency, consumer electronics manufacturers now boast wireless telephones with built-in digital cameras and PDAs with integrated cellular/walkie-talkie/speaker phones, and the home office now enjoys the benefits of a printer that also serves as a copier, fax and scanner in one unit. The concept is described as convergence and the examples are limitless. It is so universal that convergence in our daily lives is no longer a trend; it's an assumption.
In information technology, however, the convergence trend is still emerging. Conventional wisdom has separated systems and applications by usage to remove complexity. Single applications with their individual platforms can more easily meet the needs of particular users in both function and performance. The common approach of developing stovepipe systems has more to do with the way companies organize themselves, as stovepipe business units, than with any perceived advantage of building systems this way. Often, it just feels normal.
Consolidation and integration
IT convergence brings systems or applications together. Consolidation and integration are variations on the convergence theme. Consolidation brings applications (or data marts or operational data stores) together into one system, but does not necessarily blend or integrate functionality.
Data mart re-hosting is an example of consolidation without integration. The separate physical systems (and their applications) are brought together into a larger server environment, but the data mart schemas are kept separate. This reduces some effort and cost at the server level because there are fewer separately managed systems. However, requests for applications that analyze data from multiple subject areas may not be handled as nimbly as if the data are truly integrated. Like a Swiss Army Knife, components are co-located, but they aren't integrated.
Integration is the most advanced activity because with it, you consider a data element's relationship to each of the other elements being brought together. This takes additional effort up front, but offers additional capability as the reward.
Union Pacific Railroad's Paul Evans, senior manager of data warehousing, once said that even though the transportation company had other reasons for implementing its data warehouse, the integration is now where it gets the most ROI because users are now able to ask questions and get answers that they were never able to get before.
In the report "Current Practices in Active Data Warehousing," by Bolder Technology president Richard Hackathorn, Evans explained, "Without the EDW as the integration point, we would be taking 6 to 12 months for each question, to build interfaces among applications to answer those questions. In this case, the business deal that we were trying to close had long since gone to our competition. That level of integration, with data staged and ready in the EDW, gives us the power and flexibility to react to changes in the marketplace and to respond to requests from our customers.We have landed some multimillion dollar contracts from this ability."
Integration can potentially occur without consolidation. It would take the form of a presentation-layer solution. This concept is tempting, but risky.Without bringing the components together physically, each problem will need to be solved over and over again at the application layer, where it is most expensive.
Convergence and consistency
The strong influences that integration and consolidation have had on convergence can't be ignored. Efforts at convergence have gained more than a foothold in the enterprise architecture. Enterprise resource planning (ERP) systems attempt to get the company operating consistently across its business units; middleware (Enterprise Application Integration ((EAI)), Enterprise Information Integration ((EII)), etc.) attempts to link data with the applications that may use that data. Operational data stores attempt to provide business operations with centralized access to timely operational data. And enterprise data warehouses (EDW) are intended to supply users with access to data from across the enterprise for optimized decision-making.
Strong acceptance of EDW and a rejection of hit-and-run data marts proves the convergence trend is becoming mainstream. Single, centralized EDWs, built one subject at a time from the bottom—up but architected from the top down, have helped many companies gain decision-making consistency. The decision to build a data warehouse itself brings an act of convergence inside the business-data warehouse users and developers must ultimately collaborate and agree to successfully bring forth an enterprise-wide solution that will meet ongoing needs.
Expert practitioners look not only to converge or consolidate, but also to integrate. Some have actually preempted the eventual need to integrate by adhering to a strict vision from the beginning. Here are three such examples:
> PING, Inc., a golf industry pioneer and manufacturer, never needed to integrate or consolidate because from the beginning (over a dozen years ago), they built a single-database environment using one database on one system to serve the entire corporation. From call center agents to manufacturing, a single, direct-access, centralized repository serves their information needs. Today, 80% of PING associates have access to this single source of data. The company pioneered a centralized architecture for all information before anyone knew what to call it. Today, it would likely be called an active or real-time data warehouse. ("Current Practices in Active Data Warehousing," Richard Hackathorn, Bolder Technology, Inc., 2002.)
> SBC wanted to answer "any question at any time by any user." To do this, SBC knew it would need to create a smorgasbord of data from which users could serve themselves. Although it was tempting to limit or control usage, SBC instead delivered an award-winning data warehouse that invited ad-hoc queries to be launched against any of the data without pre-tuning the query. (SBC's VLDB Best Practices award presentation, The Data Warehouse Institute Summer Conference, Boston, Mass., August 2002.)
> 3M had to go about convergence the hard way. As a very mature company with 40 business units, each with its own distinct information environment, 3M never had a holistic view of the enterprise. Yet the company knew it needed one. 3M ultimately consolidated the disparate environments into a single, integrated global enterprise data warehouse (named GEDW). The initiative was called "One Face, One Voice," and its goal was one source of data for everyone. It wasn't easy, but it was architected with care and vision, reaping hundreds of millions of dollars of ROI to date. $350 million in worldwide savings were attributed to the data warehouse in 2001 alone. ("3M: 100 Years of Processing," Patrick Helmaan, Teradata Magazine, Q3 2002.)
Build and operate
How does one proceed? Successful convergence is all about the architectural choices made when you were first building your decision-support environment.Were you resolving one unique issue, or did you see the issue as merely a symptom of a broader need for information?
Best practices have shown that once you achieve integration, you are ahead of the game and better prepared to respond to unforeseen requests. Leading data warehouse practitioners have looked beyond the current situation and given themselves a way to solve problems they know they will ultimately face.
Where do you look? Take inventory of all of the requests coming in to the IT shop-are there similarities or threads such that if you step back and look across the requests you could solve any of them with the same general solution? Once you respond to one of these requests, will there be many more along similar lines?
Experienced professionals advise that when you need to acquire new data, acquire all of the data elements from that source-even if they aren't specifically needed at the time. Users will want the additional data sooner or later, and you'll be able to respond to their requests with agility.
If you look across all of the requests, past and future, for your decision-support environment, you will likely see that data acquisition is the most frequent and most time-consuming activity for users and their data warehouse support staff. Solve this problem in a big way and you will have taken a huge step towards being ahead of the curve and anticipating your users' needs. This will make you a hero-not just for a day, but also for many days to come.
As a rule of thumb, employ the concept of reusability of data: store once, use many times. As an analogy, I like to compare it to the tenets exemplified by the triangular symbol one finds on recyclable containers (reduce, reuse, recycle). For efficiency and agility, first look to reduce the number of redundant copies of the same data. Then, as you design new applications look to reuse existing data elements. Finally, only as a last resort, recycle or copy the data into a separate physical form.
If existing systems are heavily customized and the cost to re-architect them overshadows any immediate gain from integration, it may be best to integrate over time, solving the business needs that are not currently addressed but that yield the most business value and can also leverage data already acquired. As an IT provider, understand your business and the key business indicators (KBI) by which your company is measured. Knowing which KBIs are linked to which business questions can help you identify gaps,
prioritize projects and develop systems that create a competitive advantage.
Don't be afraid to play detective in order to market your data capability. Many users may not recognize the benefit initially, but teaming with the right users can bring greater value and help you find that "killer application." Consider the experience Continental Airlines' former data warehousing director, Alicia Acebo, recently described at the BI Strategies Summit at The Data Warehouse Institute's 2004 Winter World Conference in Las Vegas. Her data warehouse team built an active data warehouse with real-time data because they knew it was the best long-term decision even though users weren't yet asking for real-time data. In seeking additional applications for the data they had harnessed, they teamed up with a tech-savvy head of operations at a hub airport to deliver a leading-edge operational dashboard capability via the data warehouse. This very important user can't imagine running the hub without it.
Integrating systems is the right thing to do, but it's not easy. It requires agreement and common vision across the enterprise. It's one of the hardest things you'll ever do in IT-I liken it to group therapy for the corporation. It's so much easier to build a separate system to solve a burning need and be a hero for a day, but doing so doesn't require cross-departmental collaboration, holistic metadata or rigid architectural adherence. Those who prefer this method admit it's because they can fly under the radar and solve small problems swiftly-it makes them feel useful. However, it's like fighting a viral disease by treating only the afflicted. A disease spreads rapidly, before symptoms appear. By the time you diagnose it, it has already spread. Therefore, a proper solution combines eradication and prevention. In the case of enterprise data warehousing, for long-term value and agility, you need to support consolidation with integration and be vigilant in preventing the propagation of hit-and-run systems.
Kimberly Stanick, Technical Marketing Strategy director of Teradata Warehouse Marketing, is focused on promoting the technical fit of Teradata for active and enterprise data warehouse solutions. Previously she was an application and system programmer in the aerospace sector.
© Teradata Magazine-June 2004
 RELATED ARTICLES: |
|
|
|
|
|
Printable version
Send to a colleague
