Managing the Complexity of Data Management and Distribution
Cliff Cunningham and John Randles
The challenge of controlling Trade and Reference Data Management and Distribution is often underestimated. It can be a highly complex equation to manage multiple data vendors for multiple asset classes with differing identifiers and data formats, the complexity and interdependency of downstream systems and multiple trading clients with client specific trade format requirements.This paper addresses the:
- Complexity associated with Reference Data Management and Distribution
- Difficulties with Data Models and RDBMS based solutions
- Driver to turn Reference Data Management and Distribution into a competitive advantage
Highly complex all encompassing data models mapping all possible fields and relationships have been tried but with very patchy results. Point-to-point integrations of data feeds are easily created but they can quickly become un-maintainable. Business users tend to say: “Take that piece of information from there in all cases, except if it is this asset class and therefore not for these operations.” Or “It’s the same message structure as for Equities with these fields added and these other fields being populated from different sources”. This is very difficult to achieve with point-to-point integration.
The dimensions for the business rules can be arbitrary, such as client, client segment, asset type, geography, market, application version, application interface, operation type. The real challenge is to enable rules to grow in an ordered and manageable way as the complexity of your Data Management and Distribution requirements grows.
Managing The Complexity of Data Management and Distribution has been read by over five hundred executives across buy side and sell side firms. To receive a copy of this paper, please email info@polarlake.com.
The ROI – PolarLake RDD and Enterprise Application Integration (EAI)
John Randles
This paper compares the experience of using PolarLake RDD in a real world project against the customer’s estimates to do the same project that were based on traditional EAI technologies. All measures are based on the IT implementation effort and do not take into account consequential business benefits such as higher STP rates, operational efficiencies etc.
Also it does not take into account the possibly exponentially higher build costs required when each individual line of business is responsible for the integration of their own pieces of Reference Data from a generic message to all systems.
In order to understand the metrics presented in this report it is important to understand the scale of the undertaking involved. The table below is a summary of the complexity measures that drove effort involved in the implementation.
| Complexity Measure | Number |
|---|---|
| Number of downstream systems | 3 |
| Number of asset types | 10 |
| Number of issue components per DSS | 12 |
| Number of issuer components per DSS | 3 |
| Number of potential integration maps: (10x3x12)+(3x3) | 369 |
| Average number of business rules per mapping | 25 |
| Total number of possible business rules | 9,225 |
| Variations within asset class, geography, market, language, etc | Potentially significant, but not factored into above calculation |
| Operations: insert, update (selective), delete, refresh | Potentially significant, but not factored into above calculation |
| Transactionality, cardinality, dependencies, sequencing, exceptions management | Potentially significant, but not factored into above calculation |
To receive a copy of this paper, please email info@polarlake.com.
PolarLake and XML Technical Paper
Unlocking the value of financial research with XML. This paper provides an overview of the benefits and challenges for firms wishing to implement XML-based systems and explores how PolarLake can be used to address these challenges.
PolarLake Financial Services Technical Paper
Standards-based integration in financial services. A paper that looks at the promise of XML, Web Services and the Enterprise Service Bus as well as the various XML standards being developed for and used in the Financial Services industry.
Solving the Mediation Challenge: The Heart of an ESB
What mediation is, why we need it, and how to implement it. Although some may regard mediation as simply the most recent addition to the SOA and Enterprise Service Bus jargon, its emergence is in fact hugely significant: it is now apparent that mediation is the fundamental issue that any viable ESB product or solution must address.
Incremental Integration In Action
PolarLake use cases from around the world. The desire to integrate IT systems is nothing new. And although various technologies designed to resolve the issues associated with integration have come and gone over the past few years, what has not changed is the central understanding that the integration of IT infrastructure can deliver key benefits in terms of improved efficiency and consequent competitive advantage.
Understanding the ESB
What it is, Why it matters, and How to choose one. The Enterprise Service Bus (ESB) is no longer a new technology with 'potential'; it is already delivering return on investment and providing the foundations for the integration architectures of the future. Perhaps because of the ESB's obvious benefits, it already enjoys multiple definitions– so many, in fact, that potential adopters need to approach the technology with caution if they are not to be sold old technology in new clothing. This whitepaper attempts to outline the capabilities required in an ESB in order to handle the most complex integration challenges in an open, scalable and flexible manner.
Automating Business Process Management with BPEL and XML
A new architecture for business collaboration. This paper looks at the business and technical drivers behind Business Process Management (BPM) and Business Activity Monitoring (BAM). It describes how the development of the Business Process Execution Language (BPEL) has made it easier for business to define, orchestrate and deploy business processes both within and between organizations.
© 
2012