Business Objects

When working on data migration, it's common to focus solely on transforming the source data to the target data. This is a crucial task at hand, but it often leads to the project becoming purely a technical exercise. Data is moved through migration steps based on technical requirements, without a clear connection to the business concepts represented by the data being migrated.

However, if we maintain the connection to key business concepts throughout the mapping and execution of the data migration, we can leverage the valuable knowledge of individuals with deep business-related expertise throughout the project's lifespan.

All components of Hopp revolve around Business Objects, which represent the data about specific items within the business being migrated. The actual business objects will vary depending on the nature of the business, such as Customer, Account, Policy, Patent, Mortgage, etc. These Business Objects are organized in hierarchies, with a set of root business objects and recursive sub-business objects.

The first illustration below demonstrates the core concept that underpins our migration tool and sets it apart from other solutions, which are more ETL-based.

We observe data sets within a data model structure in the illustration, although the specific structure is not crucial. There are multiple boxes representing various data sets, which are typically organized into domains or networks that are more closely related to each other than to other elements.

In the example below, the green elements represent customer-related data, the red elements are account-related, and the blue elements are portfolio-related. Naturally, there are interrelationships as well, such as a customer owning an account, and an account being tied to a portfolio. However, these elements naturally group themselves into domains or networks.

Now, let's take a different approach. We observe the same data sets but view them as hierarchies. In this hierarchy, the green section represents the customer, which is a hierarchical structure. Within the customer entity, you can access all related information connected to that specific customer.

Therefore, when we migrate a customer, we don't just migrate the rows in the customer table. We migrate the customer and all the associated data linked to that customer. The same principle applies to the account and portfolio.

The red lines indicate these connections. Additionally, these hierarchies have relationships between them, as mentioned earlier. This is the scope of our migration. These are the units we migrate. We treat each account as a complete unit with all its dependencies, and then we move on to the next account with its respective dependencies. We refer to these units of migration as Business Objects.

So again, what exactly is a Business Object? In essence, it can represent anything, depending on the business being migrated. For example, if we are migrating a bank, the Business Objects may encompass customer accounts, statements, and similar entities. However, they could also encompass invoices, patient records, insurance policies, or anything relevant to the specific system or business being migrated.

Consider an example where we have a Business Object called "account." An account could have one or more associated statements, and each statement can comprise one or more lines. Hence, a Business Object forms a hierarchy of interconnected Business Objects, potentially branching out infinitely.

Another Business Object could be a customer, which is likewise a hierarchy of child Business Objects. For each Business Object in the target map, we define a list of interface fields. Essentially, every Business Object in the hierarchy possesses a set of interface fields. By defining the Customer Business Object hierarchy and its associated interfaces, we effectively establish the target interface for the Customer.

Business Objects serve as the foundation for mapping, actual iterations of migration executions, and the presentation of migration iteration results and events. During execution, each business object undergoes the migration steps as a single unit.

The concept of Business Objects is entirely fundamental for how our tool works.