Hourglass - Maps and Interface

Our two separate maps - the Target and the Source Map are key features in the architecture of our software. The idea is that we specify two separate maps. One represents the requirements of the target system (Target Map), and the other represents one of the source systems (Source Map). The link between the two maps is the interface fields that the Target Maps expose, and the Source map needs to fulfill.

The fact that the maps are completely separate implies a clear structure, allowing for reuse. This is a huge benefit in any repeated migration into any target system, as much work has already been done from the start.

In other words, we're migrating from a source system to a target system. We build a Target Map that is solely concerned with the target system. The Target Map does not have any knowledge whatsoever of the source system.

The first step is to build a Target Map that contains the data requirements of the target system, namely, the data we need exposed by the interface. This is a way for the Target Maps to say, 'If you give me this data, I can sort out the rest of it.'

The Hourglass illustrates the thinking where the target system, at the bottom, is represented by the Target Map, which the Interface again represents. The Interface requirements are then fulfilled by the Source Map, which gets its data from the source system.

This structure implies that the Target Map can derive, calculate, and produce the values for the data sets in the target system solely based on the interface fields. Provide the Target Map with the data that corresponds to this interface. It will produce the data and, almost more importantly, introduce validation to ensure that the data flowing into the target system can do so without errors at both the point of insertion and the point of delivery.

The Target Map does not in any way need to know anything about where the data comes from at the start of the day, and which source system is irrelevant for the target map.

Next, we create a Source Map. The Source Map knows the interface of the Target Map. The task of the Source Map is to figure out how we get from the data in the source system to something that conforms to the interface and can flow into the Target Map.

In the end, we have two completely different entities, or Maps, and an Interface, which is our Business Objects, organized as hierarchies. If we look at the example above, a Business Object on this interface is simply a description of the nodes in the hierarchy.

For each node, the interface clarifies the set of fields we need to receive for this node. That's all in this interface; it's very lean, and there's no functionality whatsoever. It's simply just a description of these hierarchies.

With this separation, the benefits are that if you are migrating into the same target system multiple times, as is common in the ERP space, such as Dynamics, Oracle, or SAP, you will be reusing the same target system repeatedly. So, you have one Target Map, and then you have a separate Source Map for each project.

Of course, if you find yourself migrating from the same source system into the same Target Map, then you can get some reuse out of the Source Map as well. With this separation, you achieve a very high degree of reuse of your Target Map, which will improve in quality over time across multiple projects.