## 4 Conclusions and Future Work  
The approach presented in this article aimed to define, design, and implement an architectural proposal utilizing a Dynamic Canonical Data Model (DCDM) representation through Agnostic Messages. The approach was constructed to improve the low coupling directed to the data and external levels in integrating software units. This objective was covered with the proposed design and implemented through design patterns that sup  
Figure 13: Entity _Items_ with the data integrated after the execution of the test case applying the DCDM architecture including _sku_ and _kop_ fields. ported the architecture presented, thus creating an intermediate layer between the various existing platforms. The purpose of this intermediate layer is that, through its traveling of the information to be integrated, as well as in a fragment of the representation of the data model (structure), its entities and relationships are represented in a universal message. This was managed and interpreted using algorithms designed for such a purpose; in this case, two of the algorithms were proposed. However, other algorithms can be created according to the need for integration. With this, redesigning or rebuilding the WSDL contract that was already implemented in the various integrated platforms was avoided, so that, when there is a change in any of the platforms, the integration can be scalable, easy to maintain, and, therefore, low cost in development and maintenance by reusing the component. The DCDM architecture introduced in this article was created to address the integration requirements of Paquetexpress, a Mexican logistics company specializing in national and international parcel delivery across more than 240 countries worldwide. This initiative arose from the necessity to integrate software components, particularly concerning shipment validation with online stores Amazon and Mercadolibre. The design of the DCDM architecture was informed by the limitations identified in previous research on Enterprise Application Integration (EAI) outlined in reference [1]. These limitations significantly impacted the company as integration costs per year had become a substantial expense. An advantage of the architecture presented in this article, over others detailed in Section 2, lies in the scenarios that have a large number of clients connected to the WSDL service contract, and for those that need to add new information (new data). In this regard, the change would not impact the rest of the systems already connected because only one of them requires the new data, which would be added to the structure of the message with its information. In this form, they will usually continue working without any inconvenience. A disadvantage could be at the moment of generating the message assembly and declaring the transaction section because, in addition to the information, the fields belonging to the entities are specified; however, the assembly of these sections could be built as part of a framework, and it could be more straightforward when implementing this part of the architecture. Finally, in the architecture presented in this article, an essential part of the tree structure was not included regarding the relationships between entities, an essential part of the dynamic data canonization, where primary keys and foreign keys are represented together with their restrictions. This improvement is considered future work for better architectural functioning. In addition, it will be integrated into a framework with a user interface for simple and fast management. Lastly, there is a consideration to expand the data representation choices by incorporating JSON (JavaScript Object Notation) within service architectures, like REST (Representational State Transfer), that operate over the HTTP (Hypertext Transfer Protocol) protocol. Conceptualization, J.A.R.-C., J.A.A.-C. and C.T.-B. ; methodology, J.A.R.-C., J.A.A.-C., C.T.-B. and A.Z.-C.; investigation, J.A.R.-C., J.A.A.-C., C.T.-B.