Information disparity occurs when a company stores the same information in multiple databases within the corporation. JP Morgan recognized this problem when it was implementing its STP (Straight Through Processing) initiative. JP had seventeen data feeds coming into the bank. The feeds carried information about industry assets such as equities, trusts and bonds. The assets would flow to ten different divisions. When an asset reached a division, business rules validated and filtered the data before storing it into databases. These business objects were stored throughout the bank. While they were essentially the same, they also differed. This is because not all divisions got all of the feeds, and different divisions stored different information about the assets. The bank needed to consolidate these 4.5 million assets to reduce the risk of basing business decisions on bad information.

The situation described above is the “Market Reference Data” problem, which is the entry point to the financial industry’s STP initiative. To start any kind of business transaction, you must have good data, data that you’ve validated and which is consistent throughout the organization. The following figure shows the old system, with department applications and databases. The trouble is that each division only processed a subset of the feeds, and each had its own business rules. Therefore, information disparity often occurred.

Any solution must have a seamless transition plan that does not disrupt business operations. At JP Morgan, each division is a multi-billion dollar institution in its own right, and they are not going to allow anyone to re-architect their data. Moreover, any new centralized implementation must have auditing and disaster recovery.

Because of the complexity of this problem, and the number of parties involved, there needed to be a complete design before any programming began. This was achieved by building a model of the project. The modeling process involved describing all of the business objects, relations, and types contained in the distributed databases. The JPMorgan/Chase project was modeled in four weeks because all of the silos contained the same security objects, and the system and data architects were dedicated to the task of defining business objects. Business objects encapsulate all of the data tables and fields into a single model for the enterprise. The model can be printed and reviewed for accuracy by all divisions.

Once the model has been finalized, you have essentially captured the reference data problem. The ObjectRiver master model compiler can now generate a centralized repository and a programmatic infrastructure that includes auditing, replication, and downstream event processing for synchronizing disparate databases.

The ObjectRiver approach centralizes the business objects, while keeping distributed databases synchronized. Business rules are consolidated on the front-end, and exception conditions are handled by workstation scrubbers before the objects are stored. All objects contain an audit history, so an analyst can look at what has changed on any individual object, when the change was made and who initiated it. In addition, all of the applications for reporting and decision-making are left untouched.

The market reference data problem is the most obvious form of information disparity. ObjectRiver MDM provides a non-intrusive solution to centralize and synchronize distributed databases. All information is currently derived from the centralized master version. Any change to the master initiates a business event that updates remote databases. All existing applications for reporting and decision support are unchanged.

The following is a description from JPMorgan Investor Services, 2003 Securities Processing Spotlight describing the GMRD application.

Home