Hourglas - 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 one of the source system (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 and reuse can be achieved. 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 the rest of it out.

Figure 1: The Hourglass

The Hourglass illustrates the thinking where the target system, at the bottom, is represented by the Target Map, which is again represented by the Interface. 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. If you give me the data that corresponds to this interface that I expose, it will produce the data and almost more importantly, it will introduce validation to ensure that the data that flows into the target system can do so without any errors at 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 come 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, here and an Interface, that is our Business Objects, that is these hierarchies. If we look at the example above, like the account from before, 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, like common in the ERP space, like Dynamics, Oracle, or SAP you will be reusing the same target system over and over again. So you have one Target Map and then you have a Source Map per 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 get a very high degree of reuse of your Target Map that will grow in quality over time from project to project. 

Like to view this article as a video: