Enterprise Wide Data Modeling

NETMATION

Home

Welcome

Newsletter

Job Openings

Press Releases

BUSINESS
Resumes
Computer Store

CONSULTING
Consulting
Justify
Full Time
Temps
Management
Experience
White Papers
Quote
FAQ

SOFTWARE
NCAP
Partnership
Features
Screenshots
Download
Quote
FAQ

HELP
Contact
Coming Soon
Legal
Site Map

Enterprise Wide Data Modeling

Introduction
Enterprise data modeling has become subject to a crossfire of criticism. Critics say, a centralized approach to data modeling cannot reflect modern requirements for decentralized structures and rapid organizational change as forced by global markets. Most of the criticism stems from real bad experiences with data modeling. But the conclusion should not be to condemn data modeling, but to do it right. Netmation consultants have had experience with various methods in quickly and efficiently gathering critical business data and constructing a data model to accurately reflect the business ignored to develop and implement mission critical information systems.

Arguments Against Enterprise Wide Data Models Enterprise data modeling has been in the crossfire of several articles recently. These name many shortcomings of data modeling and quote lots of negative experiences. This leads some authors to the final statement, that Enterprise Data modeling is completely useless.

Most critics say, that an inflexible, top-down and centralist approach like enterprise wide data modeling is not fitted to deal with problems like ever faster changing environments, pressure from global markets and decentralization. A central data model is said to be a contradiction to a decentralized organization. That rapid change, the critics say, will make the data model outdated before the data analysts can bring it to the market.

We hope you can avoid some typical errors, when you take the time, to evaluate the process of data modeling in your company. After all the criticism one thing should not be forgotten. Data modeling has been invented with a purpose. The purpose to avoid the problems with isolated, non integrated systems, we all still know from the stoneage of data processing. So by going back to the roots because we have some difficulties with the better technique, some of them caused by our own faults in using the method is not the way to improve things.

As we want to provide a checklist, we should start with the criticism and all the things that can go wrong. We will quote a whole list of criticism first, to derive a list of questions that should help you to detect some very common problems with data modeling, that can be easily avoided.

The following is a list of common arguments against data modeling.

Information processing systems of financial institutions have to be adapted to change very quickly. This is caused by the globalization of markets, new needs for customer service above all and ever faster product innovations. Data modeling is not able to keep the pace with those developments.

New financial instruments require fast adaptation of MIS capabilities. Data modeling is not able to provide a bank with information systems that can be adapted with the speed of innovation.

Systems have to be developed ever faster. Data modeling is a brake and not a booster.

Using data modeling means promoting structures that should not be changed. Change is the normal case in systems development. This adds to the character of data modeling as a brake.

Enterprise data models create additional complexity in the process of software development. The application development is impaired by the urge to use top-down data modeling practices.

Integration of systems can lead to the violation of normalization rules, such forcing the integrated systems to be adapted - valuable time elapses for formal matters.

Data modeling has to incorporate all possible future options of a systems. This slows it down to inoperabilty. The level of abstraction is tending to become higher and higher until nobody is able to understand the results of the process.

Buying prefabricated data models off the shelf is naive. Prefabricated data models are useless.

Despite all criticism the following basic requirements are acknowledged as essentials of any process of software development.

There is no way without integrated systems - integrated systems are a prerequisite for the survival of a financial institution, to manage complexity and to master interdependencies.

The single systems of an enterprise have to use consistent terms in order to provide a consistent processing of data over the borders of several systems.

Integration of old and new-built systems is the normal case of systems development.

Basic structures or invariants of a business are the starting point and the anchor for all systems development.

Proper Enterprise Data Modeling
The following arguments will show, that most of the problems mentioned can be fixed by a data modeling process. We will use the arguments against data modeling to show, that data modeling is considerably better than the critics argue.

Rapid Change
It should not be tried to model fast changing facts in a data model. Hard wired organization schemes are not subject of data modeling. But the core of business activities and business rules is subject to data modeling, such as a bank account or an external partner will stay very much the same for years. These objects are not subject to rapid change. Data modeling should concentrate on those core entities. The so called reference models take this as their objective.

Accelerates Projects
Data modeling can accelerate projects by being a service function for projects. You visit your data modeling group and they tell you about other peoples efforts going on, about entities, that already exist an about how other people solved the same problem in a reference model. A data administration department that does reviews only, after it's to late is indeed a slow down. A data administration that helps projects in the above way is a very important step towards reuse and reusable objects.

Right Amount Of Detail
There is no law that says: "You have to work top down when practicing data modeling. There should indeed be a framework, called a top level data model. But it should not be assumed that you need to expand the model to the 3rd and 4th level of detail. This detailed analysis should be part of the individual project data models and should not be included in the enterprise data model.

Summary
The question, most of the critics leave unanswered is, what do we do if we don't do data modeling. The first alternative is to build island solutions like in the stone age of data processing. These are connected via interfaces. The lack of common terminology will lead to some problems and considerable effort. The negative experiences with this solutions led to an approach to fix those problems - "data modeling".

netmation.com | netmation.net | netmation.org | netmation.tv