There are still a lot of people that integration architecture the data sounds strange to you. Almost like a contradiction. They do not agree that data integration should have its own architecture.
Nowadays, many data integration specialists still create separate interfaces. A bad practice that is also simply anti-architectural. Another common misconception is that when using the product provided by a vendor for data integration, we already have automatically guaranteed the integration architecture.
And what is the problem with all this? Good, if we do not assume the existence of a data integration architecture, we will not be able to address how that architecture affects the scalability of the integration, costs, personal, real-time support capability, data management, SOA, etc.
Let's see a little more broken down what are some objectives of a integration architecture of data. How is it able to impose an order within the complexity.
Most of the components of a data integration solution fall into one of three categories: servers, interfaces and items for data transformation. Taking this into account, we could say that a integration architecture the data is nothing more than the modeling of servers that are related by means of interfaces.
The ideal point of this architecture model is that they provide a comprehensive vision of the infrastructure and all the development that is implemented on it. In this way everyone will be clear about what is there, and everyone will have a common vision to collaborate on developments.
At the same time, if these development rules are always followed and the integration architecture has adapted well to them, a later job that even has to be inherited by other people, it will be much faster.
How these development standards and architectural models can be applied to multiple data integration projects, the result will be simplicity by driving code reuse while increasing consistency in data handling.
The kind of integration architecture preferred for most integration solutions is known as hub and spoke. In this architecture, communication and data transfer between servers goes through a center central, where an integration server manages communications and performs data transformations. If the data integration response is created with a vendor's tool, that server in the center usually the data integration server for that provider. If you use your own solutions, the server center it can be your own database management system or a collection of programming routines made by your own team. You can select and everything still makes sense.
- Recognize that the data integration architecture exists. Even though it overlaps with the data storage architecture and interacts with the rest of the business intelligence infrastructure, data integration architecture is a self-contained framework that needs a self-contained solution.
- It incorporates specialized personnel in data integration. Instead of hiring data integration specialists from your data warehousing team, consider the opportunity to create a specialized data integration department.
- Embrace the architecture hub and spoke for your data integration implementations. The center Reduce the number of must-have interfaces and provide a model that everyone can understand and be productive with. It is also an ideal architecture to guarantee reuse, the productivity, collaboration and consistent development standards.
- Don't upload all your work to that central hub. If you don't distribute the workload a bit, soon the center will collapse. When you need to handle large volumes of data, it is better to spread the workload beyond the hub by means of various pre-processing and post-processing modules.
