This week, Semarchy has announced the general availability of Convergence 1.3. The response to our announcement has been enormously positive.
This general availability follows a six months cycle during which we have added a brand new set of features to extend the reach of the Convergence platform, cover new customer requirements and use cases.
In this Semarchy Convergence 1.3 blog series, you will discover these new features from a different perspective. Instead of throwing a bucket of marketing concepts that would make no sense even to MDM and Data Governance experts, I will focus on facts.
Using use cases, screenshots and diagrams, I will try to help you understand the value of the improvements made to our Evolutionary MDM platform.
Convergence 1.3 vs. 1.2
Convergence 1.2 is a platform to design and generate Multi Domain Data Consolidation MDM hubs. In such a hub:
- Operational applications push - using a middleware such as Semarchy Convergence for Data Integration - master data (Customers, Products, Employees, etc.) in the MDM hub designed and generated with Convergence for MDM.
- The hub implements the data structures to host this master data, as well as the data certification processes to create Golden Data from the Master Data.
- This data can be consumed by users using a generated UI or by applications via various APIs (database access, web services, etc.).
The core idea here is Data Convergence. Master data flows from the operational systems into which it is naturally authored (your usual CRM, ERP, etc.) and converges into Golden Data. Master data is cleansed, de-duplicated (matched), consolidated, validated and version-controlled to create Golden Data. Some people call this golden data the "Single Version of The Truth" or "360° Customer View".
In Convergence 1.3, we simply added the capability for users to access and contribute to the MDM hub in a business-friendly way. Here is how...
Accessing the Hub Using Applications
One of the challenges in an MDM initiative is to be able to demonstrate the value of MDM to the business on short timeframes. Business users not only want to get involved in the MDM initiative at the specification/design stage (and they must be involved for the initiative to succeed); they also want to get results ASAP not to get frustrated!
This is a valid demand as golden data shows its true value only when it is accessible and used by a broad community of users. Providing simple, intuitive and business-friendly access to the hub is an important step in delivering to the business the value it expects.
This is done in Semarchy through Applications. In an application, users can access data in the base entities of the hub, and can also access data via Business Objects. For example (See the Application Structure in Figure 1):
- For Sales : The customers with their attached contacts,
- For Sales Management: The employees from the sales department with the customers they manage,
- For Finance: The hierarchy of cost centers with the attached employees,
- For HR: The hierarchy of managers and employees.
These business objects address different business needs from the same multi-domain hub. The tables and forms layout, hyperlink navigation and expandable hierarchies that you see on figure 1 are part of the design of the application. Data access is secured using privileges down to the attribute-level.
Contributing to the Hub through Workflows
Data consolidation in Semarchy Convergence 1.2 involved source operational applications. In Convergence 1.3, users can also contribute to the hub through Data Entry Workflows. They can also override the behavior of the matching process through Duplicate Management Workflows.
Data Entry Workflows
Data Entry workflows are dedicated to users who author master data in the hub, or want to contribute to the data converging from the source applications. In these workflows, users can enter or update existing hub data.
Each workflow instance (called an Activity) carries along a Transaction. This transaction isolates the ongoing changes from the hub content. During an activity, several users can interact to fill in specific fields, review and validate the data. In the example (Figure 2), a sales rep. inputs or modifies customer/contact data and then sends it for validation to a data steward.
When the workflow completes, the transaction is submitted to the hub. To guarantee the highest consistency and quality of the hub data, such a transaction goes through the whole cleansing, matching, consolidation and validation process as if it was pushed from an operational application.
Duplicate Management Workflows
Matching and merging similar records is a cumbersome process if executed manually. Convergence 1.2 provided matchers and consolidators to automate this process on large data volumes. Although automated matchers cover most cases, in specific cases, a human action is needed.
In the example below, only a user can tell whether the first name is a typo or these two contacts are husband and wife.
|Denis||Smith||Male||125 North 10th Street - Brooklyn, NY email@example.com|
|Denise||Smith||Female||125 North 10th Street - Brooklyn, NY firstname.lastname@example.org|
Duplicates management workflows allow users to override the matchers' decisions. Users can create matching groups, split false matches and validate automatically-detected matches.
Similarly to the data entry workflows, duplicates management workflows support user collaboration and transactions.
Enough for today! The next posts in this series will explain how to use and design the applications and workflows.