By Dan Oliver

In today’s economy, a major factor in maintaining the competitive edge is an organization’s ability to manage and share information. The ready acceptance of the Internet by consumers, and their expectation of quicker response from organizations seeking their business, has brought this need to the forefront of most organizations’ strategic plans. In response, the technology sector has been quick to provide tools, protocols, and standards to assist organizations in sharing information.

Yet, organizations are just beginning to realize that in order to meet user expectations, they need to manage information and business processes from an enterprise perspective—rather than the traditional segmented approach in which business areas reported to a common corporate entity. While that approach was quite effective in the environment for which it was designed to function, I’ll explain why it’s now a hindrance to an organization’s competitiveness and why your organization should operate on an enterprise level.

Changing data management strategies
A first step is to establish an enterprise-level decision-making infrastructure. Once this is accomplished, you’ll need to establish strategies to standardize enterprise business and technical infrastructures so that your organization can effectively manage and share information.

Consolidating and providing mechanisms to share data is not enough. You must also establish a life cycle for the different categories of information to ensure that information that no longer holds any business or historical value does not take up valuable resources. Retaining this information increases the risk that your organization may base business decisions on out-of-date information.

Equally important is that data is consistently represented throughout the organization to ensure data integrity. It is a rare exception, when an organization starts looking at integrating its business systems or establishing an enterprisewide decision-support system, that it does not find that:

  • The tag associated with the same type of data differs between business units.
  • The same tag is used to refer to different types of data. In one system, “name” may refer to a person, and in another, it may refer to a promotion initiative.
  • The format used in representing the same piece of data differs between business units. Dates, for example, may be expressed in different formats.
  • No one can determine why particular data is being collected.

These data inconsistencies can mislead decision makers, which can result in poor, uninformed, and potentially damaging decisions. Establishing an enterprise data architecture is a major step for organizations wishing to address data integrity concerns.

Examining an enterprise data architecture
An enterprise data architecture reflects how an enterprise conducts business and is indispensable to an organization seeking a high degree of data integrity. Such an architecture:

  • Identifies the major business areas and their relationships with one another.
  • Identifies the major business objects within each business area, how these objects relate to one another, and how each object is virtually represented in terms of data.
  • Identifies the enterprise business processes contained within each business area and their relationships with one another.
  • Defines the major tasks of each business process and its relationship to other processes.
  • Identifies the individual pieces of data that are used in support of the execution of a business process and measures the process’ efficiency.
  • Defines what each piece of data represents, with which business areas/processes it is associated, the format in which the data is to be expressed, and how the data is named (tagged). Ensuring that the same type of data is consistently named and represented is an essential element in maintaining data integrity.

A documented and enforced enterprise data architecture not only will improve an organization’s data integrity but also will assist in assessing the impacts of modifying or adding business processes to the organization.

Building the framework
As we traverse the four primary steps in implementing and building an enterprise data architecture, it is important to remember that the enterprise data architecture supports the business’ processes and not vice versa.

1. Standardize business processes
The first step in establishing an architecture is to standardize and document the enterprisewide business processes. Business processes defined at the enterprise level identify the standard tasks needed to achieve the desired outcome without consideration of technology or how it is implemented.

Many organizations will assert that their business processes have already been thoroughly documented, but oftentimes, it’s actually the business solution implementation that has been documented—not the core business process. When this is the scenario, it’s hard to change technologies, as there are no steps predefined regarding the process.

2. Identify business objects
The next step is identifying all of the business objects that are used or supported by the business processes.

For each business object, identify what data needs to be associated with that object in order to distinguish it from another business object. To do this, assign each object a unique identifier and a description of exactly what the business object represents.

For each piece of data tied to an object, you must assign an identifier—a description of what the data represents, an example of the data, the special format desired, and a statement why it needs to be collected.

3. Identify business data
You must identify data that needs to be collected in order to obtain the desired business outcome. This data identification effort will also allow the organization to assess the effectiveness of a particular business process.

The initial step is identifying how data needs to be processed within the business process. The data or group of data to be communicated between business processes and tasks, within common business processes, should be documented. Essentially, you are establishing the common transactions that are to be supported by the business processes.

For example, when adding a new employee, you need to change employee information. So, each time employee info changes, the identifying data should also be exchanged.

4. Develop the architecture
At this point, you have gathered all of the information needed to develop an enterprise data architecture model. This model should accurately reflect how your organization conducts business.

Now, you must build the relationship models within the architecture to ensure that new systems and major upgrades to existing systems’ design will support the data standards and processes. The completed architecture can significantly increase an organization’s data integrity through consistent implementation of business processes and depiction of how data is represented across the enterprise.

Project tips and insight
It’s clear that I’ve provided a very simple view of a very complex process. It is costly and time-consuming to establish an effective enterprise data architecture and implement it with the necessary supporting infrastructure.

The effort requires experienced and skilled staff and the full commitment and active support of key decision makers.

As with any major enterprise endeavor, this initiative takes up front planning, and devising a strategy along with detailed implementation plans is critical.

When it’s done right, implementing an enterprise data architecture will provide a return on investment that significantly exceeds the initial and future maintenance costs, and one that will steadily increase as the organization adapts to changes within the economy.

There are alternative options
While the approach I’ve described in this article provides the best results, some organizations discover that they need a quicker solution when, for instance, competitors are gaining ground. These organizations have data integrity problems that must be mitigated in order to modify business processes or allow exchange of data with partnerships that have to be established to meet the expectations of its customers. To delay could result in the loss of current and potential customers to their competitors.

There are numerous ways to modify the best practice approach I’ve described in this article. For example, an organization can simply focus on one business unit and develop an architecture specific to its needs.

One last word of caution
Too often, organizations get so focused on defining data models and architectures that they forget that the purpose of the architecture is to support the business processes and not the other way around. This results in a lot of time wasted in defining business objects and data elements that are never used, missing essential data that is used by business processes, or collecting data that provides no value to the organization’s business processes.

Following the steps above, however, should ensure that your organization has completed the necessary preparation required to establish an effective and consistent data architecture.

Dan Oliver is a technical manager based out of the Washington, D.C., office of Headstrong, a global consultancy that transforms established companies into digital businesses that generate added customer and shareholder value. Oliver focuses on the challenges of deploying enterprise solutions involving multiple partners using a wide variety of disparate infrastructures and legacy systems. He has more than 28 years of experience in assisting enterprises in establishing sound business solutions to enable realization of their strategic goals.