February 14, 2016 / Dennis Holinka
Topic 3 – Information Architecture layer
This week's posts go over the Information Architecture layer, the various perspectives, and related reflections in the blog.
Post 1 - Enterprise Information Integration is now the Data Virtualization Fabric
Enterprise Information Integration (EII) is an attempt of integrating Enterprise Information in a similar way in which services are integration in an Enterprise Service Bus (ESB). In other words, it is an ESB for Information except that ESB uses WS-* for its main standard integration stack. In traditional client/server and N-Tier architectures, the standard integration is point to point integration between application consumers and the Information Service provider using SQL as the means to intermediation (e.g. ODBC, JDBC, CLI, etc.) and continues to use this defacto standard as the standard intergration between caller and callee service particpants. Since 2006, EII has evolved into a full suite of Data Integration capabilities that allow for an extensive set of protocols beyond SOA WS-* SOAP based service calls. This extensive set of Information Services based capabilities has been named Data Virtualization Fabric by the Industry. This approach to data integration in the form of a Data Integration Platform has combined key information integration techniques akin to the way Enterprise Integration Platforms have combined ESBs, EAI, SOA Mediation Gateways, and UDDI. The Data Virtualization Fabric has expanded beyond native SQL integration to other protocols in a form of EAI for Data using many new invocation techniques but for data.
Enterprise Information Integration (EII) is an attempt of integrating Enterprise Information in a similar way in which services are integration in an Enterprise Service Bus (ESB). In other words, it is an ESB for Information except that ESB uses WS-* for its main standard integration stack. In traditional client/server and N-Tier architectures, the standard integration is point to point integration between application consumers and the Information Service provider using SQL as the means to intermediation (e.g. ODBC, JDBC, CLI, etc.) and continues to use this defacto standard as the standard intergration between caller and callee service particpants. Since 2006, EII has evolved into a full suite of Data Integration capabilities that allow for an extensive set of protocols beyond SOA WS-* SOAP based service calls. This extensive set of Information Services based capabilities has been named Data Virtualization Fabric by the Industry. This approach to data integration in the form of a Data Integration Platform has combined key information integration techniques akin to the way Enterprise Integration Platforms have combined ESBs, EAI, SOA Mediation Gateways, and UDDI. The Data Virtualization Fabric has expanded beyond native SQL integration to other protocols in a form of EAI for Data using many new invocation techniques but for data.
Figure: Cisco Data Virtualization Platform
The importance of the Data Virtualization Platform is found in its ability to abstract the underlying sources and locations of data and to honor the original contracts (e.g. interfaces) that are utilized by existing application code. The biggest reasons that underlying data service engines become obsolete and are not modernized is because the calling applications are tightly coupled to the engine providing the data service. The intermediation abstraction layer allows for information architects to continue to honor existing interfaces including updated versions of those interfaces (e.g. Oracle 8i to 11g, etc) while allowing for an expansion of the existing services for added features that is required by a nexus of forces applicaiton using data analytics and big data. Recently, I have encounted disruptive issues arising from the deprecation of old technology, the need to honor existing interfaces, and the need to update to newer versions or new technology that can break existing interfaces. This technology approach to data integration can minimize disruption by allowing the data integration layer to act as a mediatior to a plug and play paradigm using large data services engines as parts while honoring the most primitive of protocols used by the engines. The minimization of disruption of interfaces leads to vast sums of savings on implementation and / or testing from upgrades, migrations, and data services replacements.
No comments:
Post a Comment