Die Entwicklung der Datenintegration

Inmon Consulting Services The Evolution of Integration by W. H. Inmon WHITE PAPER A White Paper by W. H. Inmon The Evolution of Integration Table of Contents Table of Contents ............................................................. 2 The Dilemma of Changing Requirements .................................. 3 The Advent of Multiple Databases across the Organization Fuels the Need for Data Integration............................................... 4 Data Movement Technology ................................................. 6 Evolving Data Integration Needs ............................................ 8 The Cost Factor............................................................... 10 Open Source Changes the Economics of Data Integration ............. 10 Conclusion ..................................................................... 11 Page 2 of 12 A White Paper by W. H. Inmon The Evolution of Integration Once upon a time life and information systems were simple. There were small information systems that produced their output in simple and plain language. These early systems were standalone systems that served a limited set of purposes. The requirements were well defined and straightforward. Then one day somebody let Pandora out of her box. Someone said – can’t we add new requirements to these systems? Can’t we have some- thing more sophisticated and elegant than this small system? The answer was – of course we can. So new requirements and new fields of data were added, and a whole new class of information systems appeared. One of the immediate consequences of the advent of new requirements was the need for scalability. What once was small now grew large. And with the growth came a whole new set of problems. The advent of new requirements generated its own requirement – the need for scalability The need for scalability appeared in many different forms – in the need for scalability of management of volumes of data, and in the need for management of volumes of transactions. And there was another need for scalability – the need for scalability of data integration. Scalability of in- tegration includes the need for processing from many different sources and many different targets. Scalable integration includes the need for handling data that is structured in many different ways. Scalable inte- gration includes the need for handling different kinds of logic, and so forth. The Dilemma of Changing Requirements At first, all was well. The addition of new requirements seemed like a simple thing to do. But soon, someone noticed that there was a sort of competition to get processing done. With the addition of the new re- Page 3 of 12 A White Paper by W. H. Inmon The Evolution of Integration quirements, all sorts of people want to do all sorts of things with the system and its data. One person wants to do online processing. Online processing precludes many users getting at the data during online proc- essing hours. Another person wants to continually redefine the data. The subsequent reorganizations of data effectively make the data disabled for long periods of time. Another person wants to do statistical process- ing. The problem is that once statistical processing begins to run, no one else can use the system. Fig 1 shows that as the volumes of data grow and, as the functions that shaped the system evolve, that more and more demands are being placed on the system. It is as if the system (which was once simple) is being pulled in different directions by powerful forces. Unfortunately, the system cannot accommodate this disparate set of forces. The ea rly notion of a single da ta ba se serving a ll purposes simply did not work Fig 1 The Advent of Multiple Databases across the Organization Fuels the Need for Data Integration One result of this terrific pull by opposing forces is the advent of multi- ple data bases. The pull of the opposing forces is so strong that it is eas- ier to create separate stores of data than it is to try to make the single source of data serve many masters all at the same time. Thus born is the multiple data base environment. Things may be all right if these multiple databases were created under a master plan that has been carefully thought out. But these multiple data bases are created in a random, willy nilly manner, where every user does their own thing with no regard for any other user. Across the many databases is redundant data. There are unsynchronized definitions. There are different structures of data. There are individualized refer- Page 4 of 12 A White Paper by W. H. Inmon The Evolution of Integration ence tables. In short, there is absolutely no coordination or discipline of data whatsoever across these many different data bases that are built. Fig 2 shows that multiple databases are built everywhere. Soon there were multiple da ta ba ses everywhere Fig 2 In a short amount of time, the end user wakes up to find that data is scattered all over the landscape. The only way the end user has to try to make sense of data that is found in many places is to start to ship data from one environment to the next in the hope that by shipping the data to another database, there might be some rational basis for making cor- porate decisions. This discomfort with multiple occurrences of data in many places is the very first evidence that the user needed to have integrated data. Intui- tively, the end user knows that something isn’t right with having the same data occur with different values all over the corporation. As soon as a bad decision is made, the discomfort with lack of integration turns into a real case of agony. When there are many occurrences of the same element of data – each with differing values, basic decision-making is greatly impaired. What is needed is discipline of access and update of data. This discipline is achieved through integration. The need for integration mandates a need for a well-defined and rigorously enforced system of record. There needs to be update that occurred in only one place for a given data element. The many systems of the corporation need to act in harmony as one sys- tem, not a collection of separate systems. What is needed is integration of data. Page 5 of 12 A White Paper by W. H. Inmon The Evolution of Integration Data Movement Technology From a technology standpoint, some technology is designed to move data from one system to the next. This data movement software is the very first manifestation of the need for software that integrated data. It is noted however that data movement software satisfies only a few needs of the corporation. It is like offering a starving man soda crackers. You may quell a little bit of the starving man’s hunger, but a diet of nothing more than soda crackers is not going to go far in satisfying a real hunger. Fig 3 shows that software and technology for the movement of data from one database to another appears.