Compatible Data Architecture Components
Major data architecture components, such as transactional data systems, data warehouses, master data management systems, data integration hubs, and operational data stores for example, are used to construct disparate data architectures. Since each of these data architecture components is designed using established data modeling methods, each component is an incompatible disparate data system that is often characterized as an information silo.
Whenever a business requires data from two or more information silos to be combined, that data needs to be moved and transformed from the source data systems to a single information silo where the data is consolidated. This is the essence of the data integration problem. It is the incompatibility of these information silos that requires highly-customized, point-to-point ETL (Extract, Transform and Load) computer programs to move disparate data and to make that data compatible with the data environment of the target information silo. The disparate data architecture components combined with the ETL data flows is often characterized as the “integration hairball”. Of course, the more disparate data architecture components in the data architecture, the more ETL programs required and the more complex your headaches. These ETL-based, disparate data architectures are usually extremely complex, very inefficient, and certainly are not agile. Designing and implementing ETL-based data flows currently consumes a major portion of many IT department budgets.
Data Integration by Design methods are used to implement an integrated data architecture that is based upon integrated data architecture components. Integrated data architectural components are based upon a data architecture standard designed for that data architecture. When a data architecture component complies with the data integration standards, that data architecture component is compatible with all other compliant data architecture components. Any data from any compliant database may be dynamically joined with data from any other compliant databases in real-time. Integrated data architecture components are designed and developed with the premise of dynamic and open interoperability among distributed integrated data systems. When one integrated data architecture component is added, it enriches the entire data architecture. With the addition of a new integrated data architecture component, no special programming is required. Integrated data architectures are effective, inexpensive, and agile when compared to the “integration hairball” that is the disparate data architecture.
Transitioning from a disparate data architecture to an integrated data architecture is supported by the Data Reintegration Methodology, which is a Data Integration by Design method to remediate disparate data architecture components. Re-integrating data sets is achieved by complying with the data integration standards of that integrated data architecture.
Once the data modeling deficiency responsible for information silos was uncovered, it was clear that a more holistic approach to developing data systems and to integrating existing data systems was required. That holistic approach results in the development of integrated data architectures. This Data Integration by Design approach has yielded results that are monumental to the data architectural world. We are proud to share some of these discoveries with you.