With more mission-critical applications such as CRMs and ERPs moving to the Cloud, the integration landscape is changing. But what’s the degree of change? Is it really changing that much or have the mediations (services that connect the internal and external processes) simply changed to support different data packaging, communication protocols and activation methods while continuing to perform the same functionality? If your integration toolset can’t adapt to these changes, you’ll have to rebuild your integrations.
Let’s consider current real-world use cases: integration using a premise-to-Cloud implementation and integration within the Cloud such as Cloud-to-on-premise or Cloud-to-Cloud. Even though the endpoints are different and cross system boundaries, the base mediation involved is simple: Continue reading
Some of the most difficult challenges that integration projects face are what I like to refer to as “artifacts of black-box implementations.” These artifacts include incomplete specifications (both from external sources such as vendor specification or internal sources due to a lack of understanding of the interrelationships between systems), opaque processes from lack of visibility and undocumented integrations. Opaque processes and undocumented integrations present the greatest challenge because necessary information is not available due to ineffective communication, absence of the original source (often a single person) or integrations with legacy systems where there is no more vendor support. Most processes enabled by commercial applications are opaque. If you can’t determine (because it’s undocumented) (a) the identities and locations of all data that is added or updated by the process; (b) the rules under which data changes and additions occur; and (c) the identities and locations of all downstream applications, modules, and services that are invoked, then the process can be considered, to some degree, opaque. Continue reading
Why does this take place?
While new projects often get the most visibility, you also know that maintaining what is already in place is as essential as the new projects. Delays in responding to customer changes or adapting to new versions of software can be a serious impact to your business. ERP cut-overs, changing customer/vendor document formats and industry-mandated document changes (e.g. HIPAA) cause changes to our stable integrations. These changes can cause business disruption or penalties if they cannot be dealt with effectively and efficiently.
How has it been dealt with in the past?
The brute-force way to deal with changing document requirements is to clone your maps and make the (hopefully) minor adjustments. This approach works, but does not scale. Consider a company with 10 trading partners. Occasionally, a partner will upgrade their EDI maps to a new version. This rate of change can be incorporated into the work schedule with relatively little impact. Now, consider the company with 1000 or 5000 trading partners and an industry-wide mandate (such as HIPAA) is coming to bear. Very quickly, the company could be faced with updating thousands of maps. This effort would be measured in multiples of person-months. Continue reading
From tactical to practical – leveraging design-time automation to master change
While lofty strategic goals drive most business integration plans when dealing with major events such as on-boarding a new business, a merger, or an ERP cut-over, dealing with the inevitable day-to-day changes – the normal lifecycle of existing integrations, that often takes a back seat. Managing existing integrations is the unsung hero of a successful business integration shop. The key areas where change occurs are the data formats, the communications technologies and the business processes that bind everything together.
Automation and leveraging history
Let’s take a look at how to best leverage design-time automation to address each of these with minimum disruption and maximum accuracy. Managing changes in data formats, whether new fields, restructured records, or substituting an entirely new syntax – think moving from a flat file interface to XML – requires a toolset that reduces the impact of the change on the existing integration. Such a toolset could use instance data to identify deviations from the original specification and assist the user in rapidly updating their integration project, concentrating only on the differences. Once the changes to the data format have been updated, the mappings that have been affected require updating. Intelligent mapping technologies that use heuristics to identify possible candidates between the source and target data dramatically reduce the time necessary to update the integration, increase the accuracy, and assist in conforming to accepted internal standards for data placement. Continue reading
As data exchange grows at an explosive rate, moving data between formats and systems occurs in many ways. Common data transformations involve data format conversions between EDI, XML, flat files, databases and more recently spreadsheets. In an application-to-application (A2A) environment, data typically is converted between interface files and back-end databases such as ERP systems. In the EXTOL Business Integrator, we call the objects that facilitate these movements Rulesets. Continue reading