How to Design Data for Integration
Currently, the content, format, and security of integrations are controlled at the application level based on each particular application’s needs and capabilities. Each application has an internal model for the data it uses to fulfill business functions. We can refer to these internal models as “Application Data Objects” or “ADOs.”
Unfortunately these ADOs also describe the content of the data exchanged through interfaces, so each integration with another application requires its own dedicated interface on both ends. Any change to required functionality in either application makes necessary a change to the interface on the other end, creating ever-increasing complexity when designing and updating applications.
The first step to developing a more manageable integrations environment is to decouple the data used within any application from that exchanged across the enterprise. This can be done by introducing the idea of an “Enterprise Data Object” or “EDO.” Examples of EDOs are “Person,” “Admissions Application,” “Course,” “Financial Account,” etc. EDOs will be designed not to fulfill the needs of any particular application, but instead to encompass the whole campus’ notion of that information across all its applicable business processes. Because such notions change far less often than underlying process or technology, EDOs will serve as a stable lingua franca that all applications use externally. EDOs will be designed in close cooperation between enterprise architecture and business process owners, and published in a directory widely accessible to campus developers (see the bMeta Enterprise Metadata Repository).
A transition stage will introduce the EDOs into all newly created integrations, leaving existing auxiliary application interfaces intact as needed due to time and resource limitations. While applications will be encouraged to rebuild interface using EDOs, transformation to and from the EDOs can be implemented in the Integration Hub temporarily rather than in the applications themselves. Also introduced at this stage will be centralized authentication and authorization of access to EDOs, both implemented in the Integration Hub rather than in the applications themselves.
The eventual goal of course is to change all application interfaces to produce and consume data as EDOs, regardless of their individual ADOs. After a grace period to be established by campus governance, data transformation in the Integration Hub will no longer be supported and any integrated application will be expected to join in the use of EDOs to exchange data using modern message based methods.