Русская версия
+7(343) call:2 110 256

Comparing Business Semantics to MDM and Enterprise Service Bus concepts

MDM

Business Semantics Server can solve integration tasks in environments, for which usage of MDM of ESB (Enterprise Service Bus) is a common practice.

MDM (Master Data Management) solutions are using a "gold" dataset, containing aggregated information on commonly used objects (such as: customers, products etc). This dataset is synthesized from some applications, using customizable rules (these rules may be very complex and may require manual confirmations etc). For example, CRM application may have the most actual information on customer's contacts, docflow application - its postal address, accounting application - on customer's bank accounts. All this info is gathered together and placed into single master data record in the MDM. So, MDM is still keeping a relational database. All the applications can request and use this record's information from MDM.

Business Semantics, like MDM, is intended to solve data exhcange task. In contrast with MDM, Business Semantics Server does not create and keep master data records. It works like a Enterprise Service Bus (discussed below). This bus is used by various applications for notifying each other about changes in the data they are keeping. All the applications are "listening" to this bus, and may interpret and use information contained in the messages by their own ways. Data exchange with Business Semantics Server is fully transparent for the user, and automatical. It does not require any manual intervention after exchange rules are set up.

Business Semantics can be used to exchange much larger and various types of data, than it makes sense with MDM. We are talking about frequently changing data, monitoring and activity logging, and data representing business operations (sales, money movements etc). Usually there is a huge amount of such data, that cannot be effectively managed in MDM. For Business Semantics, there is no problem in transferring such data, because server does not any complex data processing, but only forwards it to interested parties. In MDM, we need to create and configure storages (tables) for each data type, while in Business Semantics we are dealing only with ontology configuration.

Enterprise Service Bus

Another kind of software used in complex IT infrastructures for interfacing, are Enterprise Service Bus (or Message Queue) solutions. They are serving as mediators, allowing applications to exchange messages. Usually ESB are providing routing and delivery guarantee, without any logical processing of the data. It means that data processing logic must be defines manually at each connection point (at application side). In most cases, it implies writing custom code. ESB cannot guarantee data integrity, because it is only transferring messages, without knowing anything about data contained inside. ESB is providing only a transport level of communication.

Business Semantics Server has all advantages of ESB, because in fact it is acting by the same way; but Business Semantics also determines a logical layer of the transfer. Our software uses Semantic Web technologies to encode data which is in transit. So, server may check it for consistency, and repair if it is necessary (and also send a copy of the data to SPARQL server, to maintain a corporate semantic-oriented database for analytical purposes). Business Semantics has standard client modules, which are performing data translation and mapping to local database structures, along with ability to involve custom handlers. Business Semantics offers access right control and setup. Due to all these features, setting up and running integration with Business Semantis is really fast and easy; and there is always a possibility to customize something, if necessary.

Business Semantics provides optimal balance between strictly data structure-bound MDM, and only transport level-focused ESB. It has a key opportunities of both, without having their major drawbacks. And anyway, it is much more simple and user-friendly than both.