I’ve written elsewhere about how important data transformation mapping is to all kinds of e-business integration, and how mapping dominates integration lifecycle costs, overall. Mapping is fundamental to Business-to-Business (B2B) integration (e.g., using EDI), application integration, data integration, and many cloud application and service integration cases, as well.
Although drag-and-drop mapping is a data transformation mapping mainstay, assisted (“automated”) mapping, map reuse, and other strategies can be far more efficient and cost-effective, under the right circumstances. But IT professionals and project leaders seeking more efficient ways to create and maintain transformation maps face a conundrum – no single mapping strategy works in all cases.
For example, most integration vendors (including EXTOL) offer off-the-shelf base map libraries that provide a starting point for maps that integrate with popular commercial applications using standard document types. But such off-the-shelf resources don’t apply to integration with in-house applications, internal data stores, partner-defined interfaces, and specialized commercial applications that lack widespread third party support.
Similarly, map reuse based on internally-developed base maps is more efficient and addresses a wider variety of mapping cases than vendor-provided libraries. But they are useful only when an internally-developed map exists (and is locatable) that uses the same (or similar) source and target documents needed for a new mapping case.
Assisted mapping driven by pattern-matching heuristics can accelerate mapping even for new and unfamiliar source / target document combinations, by inferring associations based on element naming, comments, data types, and other attributes. But pattern-matching lacks the transformation rule details and best practices contained in base maps. So it serves best as a complement to history-driven mapping methods.
Mapping driven by history patterns straddles the line between map reuse and assisted mapping. History patterns, derived from previously built maps, combine source / target element matching with transformation rules, and are designed for use with an assisted mapping tool. Unlike base maps, history patterns are independent of specific map instances, so they can be recombined to suit the unique requirements of each new mapping case. But like map reuse, history patterns help only if they are available from a vendor, from an external mapping community, or from previous internal mapping efforts.
Frequently, the best mapping strategy is to combine multiple mapping methods. The fastest way to map an EDI document to an ERP interface, for example, might be to:
- Start with a base map that covers 70% of the transformation rules you need
- Generate additional rules based on history patterns contributed by other organizations that have previously mapped the same document types
- Create the remaining rules you need, if any, with the assistance of an automated pattern-matching method
A different situation, like mapping a new partner-defined XML document to an internal database format, might call for a combination of history patterns and heuristic pattern matching, without starting from a base map. The decision tree below summarizes some common mapping cases and the most efficient mapping strategy starting points:
Identifying the optimum mapping strategy for a given data transformation situation without the benefit of intelligent mapping assistance can be daunting. So if your integration needs extend beyond the cases supported by off-the-shelf base map libraries, it’s worth investigating assisted mapping tools that give you the ability to combine base maps, history patterns, dictionaries, and pattern-matching heuristics, without having to figure out which combination of methods to use in each situation.