|
Building intelligence
An enterprise architecture gives a business a framework for its future, with the data warehouse as a foundation.
by Bill Davis
To understand the business environment, reduce it to the basics: you have an idea,
you deliver results, you face competition, you find ways to set yourself apart. Finding that competitive edge is the key. Smart companies realize the value of historical data, not only as a means of spotting and analyzing trends but also as a tool for forecasting and, ultimately, as a method for developing process initiatives and revenue streams.
The creation of any wide-ranging IT structure connecting business components must have at its heart the enterprise data warehouse (EDW). “In business, we seek out information from each of our systems,” says Claudia Imhoff, president and founder of Intelligent Solutions. “But that information may only tell us a sliver of what you need to know from a company-wide perspective. With a data warehouse, you stitch together these slivers to get a complete picture of who this customer is or what this product is. That’s why it’s the foundation of any enterprise architecture.” The EDW becomes, in fact, not just a luxury but a necessity.
An enterprise architecture is a blueprint with guidelines and principles to help all areas of
a company interrelate. It ensures consistency within an organization, in particular confirming the compliance and accuracy of the data these departments are accessing and analyzing. It
also provides the optimal way to link an organization’s vision with its IT strategy. Underscoring its value in responding to a variety of events in real-time fashion, an enterprise architecture maps the flow of data through an organization. Over time, it can eliminate redundancies, increase efficiencies
and promote profitability.
“An enterprise architecture aligns a business’s long-term intent with key decision making, whether that means market penetration, product introduction or technology development,” says Michael Tiemann, senior associate
at Booz Allen Hamilton and the former chief enterprise architect for the U.S. Department of Energy. “The broader the architecture, the more integrated it must be with business imperatives and strategic directions.”
Laying out the blueprint
All enterprise architectures should start with a basic idea: that an organization should be able to assess its current environment, determine where it wants to be in the future and develop a roadmap for getting there. Gaining that necessary perspective involves establishing high-level principles that translate to key decision making. “From there, you need a strong definition of the various functions of the enterprise; then you break that down to subfunctions, to processes and to tasks within those processes,” Tiemann says. “That’s when you map the database to these numerous activities.”
Most enterprise architecture frameworks involve the following components:
 | Business architecture |
| Application architecture |
| Technology architecture |
| Data architecture |
| People and processes that interact among
these components
|
In practice, most enterprise architectures
do not live in one document, but consist
of a collection of artifacts from various architecture components such as business architecture documents, data architecture documents and so on.
The Zachman Framework provides one approach to enterprise architecture. The Zachman Framework is a matrix that maps views of the enterprise from a management perspective to aspects that are important to enterprise systems development. The resultant matrix can be used as a planning tool or a problem-solving tool. It can be used to evaluate tools and methods or as a means of building up an integrated architecture.
The Open Group Architectural Framework (TOGAF) provides an alternative to the Zachman Framework. From a data warehousing perspective, where a business is and where it needs to go can be determined in large part from the information that runs through the data warehouse. The Open Group Architectural Framework is a tool many businesses
find useful for breaking their organizations down into their various components. It also provides insight into how each of those components makes use of information from the data warehouse.
The six elements that make up TOGAF operate as follows:
| Transactional systems and data repositories provide a record of day-to-day activities |
| Enterprise data repositories bring together information from across all departments |
| Decision-based environments analyze data |
| Business process management automation uses the data analysis to respond proactively to a variety of situations |
|
Enterprise data transport delivers information from operational systems to enterprise data repositories and applications |
| Interfaces for corporate stakeholders provide access to the enterprise |
“You must map these various areas to the enterprise architecture, as well as to their business and intelligence needs,” Imhoff says. “But what drives it is an active data warehouse with real-time capabilities. When you contact customers, you need to understand how you have them classified, what value they hold to your business and what their future potential may be. How do you get those analytics?” she asks. “It has to flow from your data warehouse, based on transactions and other events that
are constantly taking place.”
In this role, your data warehouse is, by definition, the system of record for your business. And, as the recent scandals have clearly illustrated, if your data isn’t compliant, you’ve got problems.
Ensuring rigorous data quality is crucial for enterprises in industries such as banking and investment. There must be clear definitions for how data is received, how it’s processed and stored. Companies that fail to do that lose the confidence of their customers and, ultimately, their long-term viability. “As a result,” Tiemann says, “you’re seeing in examples like the air transportation and healthcare industries,
a commonality of broader groupings of data
in their architectures that are reused and understood industry-wide.”
For businesses in less sensitive industries, flaws in the data structure may not be fatal but could result in lost opportunities. “Building an enterprise architecture is a way to manage data consistency,” says Dan Linstedt, CTO of Myers-Holum. “If you are compromising your information in any way, such as altering the data as it’s fed to the operational systems, you will have a flawed structure.”
Getting started
Even with a strong framework and clean data, an enterprise architecture is only effective if various departments agree to give up their independent and proprietary data marts in favor of an EDW. Though it seems like an obvious solution, making the jump from data mart to EDW actually represents a significant cultural shift. “It’s the proprietary nature
of people not to give up their control of information,” Imhoff says. “A salesperson’s definition of the business will differ from the enterprise definition until he or she understands the value of the greater good. It’s an extraordinary hurdle, far harder than any technological challenges that may come up.”
The process has to begin at the top. Building an enterprise architecture not only takes patience and a full-scale commitment from all facets of an organization but also requires an uncompromising outlook from business leaders to see the process through once they’ve determined that the gains outweigh any potential risks.
The key question to consider is not the risk
of doing the project but the risk of not doing
it. The reply provides a set of concerns that management can address, given the associated costs of running their business. “You show
them a report the data warehouse would provide and ask how long it would normally take them to generate such a report,” says Linstedt. “If you can quantify the time people spend on these efforts—and with the data you have, you can—you can produce tangible results that will validate the enterprise architecture.”
It’s important to spend about three weeks
up front with the key system users establishing concrete business requirements. If you put a number on every single requirement and tie your project plan to these deliverables, you will
have an auditable trail.
No project can succeed without a strong project leader who has a clear and unwavering vision. The leader needs to do more than just understand the technology. He or she needs to understand the business issues and personalities involved, uniting the various fiefdoms that can exist in the corporate world.
“Many entities within a business feel the data warehouse only extends as far as their own data mart,” Linstedt says. “An enterprise architecture project leader must convince factions like these that sharing their information benefits them in the long run. This person must be strong-willed and not easily swayed.” One key to success is maintaining visibility with the sponsors and being ready to show, for example, why a second copy of the data is necessary for compliance purposes. “And, of course, you must illustrate how the architecture protects data,” Linstedt adds, “keeping it behind closed doors while it’s transported across the company.”
Selecting a single initiative that would make a universal impact within an organization, rather than trying to solve multiple issues at once, represents the best way to bite off manageable pieces of the pie. “You have a lot of questions to ask when starting a project of this type,” Imhoff says. “‘What are the attributes that identify a customer?’ ‘Where do I get information to identify and characterize that customer?’ And, ‘Where do I store that information?’ Answering such broad questions takes time;
it’s best to begin with a smaller scope and
build off of your findings.”
Measuring up
Gauging the success of your enterprise architecture involves making use of the various metrics available in the business intelligence (BI) environment. Has your customer response rate improved? Has your supply chain become more efficient? Are you able to carry less inventory? And, of course, the most important question of all: Has your business become
more profitable? “It’s like having a placebo
and a test group,” Tiemann says. “You look
at an enterprise devoid of the architecture, before implementation, and then with it in place, putting the metrics to use to show the value added.”
A strong enterprise architecture shows that the data warehouse can not only produce a return on investment but can, in fact, also become a profit center simply by tracking and charging for information access. For those companies that rely on data integrity to survive in their market, resolving certain compliance issues is another way to gauge success.
An enterprise architecture provides businesses with the direction they need to
move forward and make optimal use of the technological resources at their disposal.
It should work to serve the needs of the organization and be capable of evolving over time as new challenges present themselves.
“Those companies that have the fortitude
to undertake an enterprise architecture project are the ones that write the success stories,” says Imhoff. “They have the vision and foresight to plan out their future, and they ultimately reap the benefits.” T
Bill Davis is a freelance writer who has authored articles for a variety of clients.
© Teradata Magazine-June 2006
back to top
|
Quick Links
Print
Send to colleague
PDF
E-mail us
