By Steve Young, CEO of Citisoft
When a new sports car is being created, the designers begin the process by conceiving their vision. When the blueprint has been created, the mechanics are brought in to provide the technical detail. If the design is changed, the mechanics then have to adapt their technical specification to the new design. Mechanics build and fix to a well-set agenda. Even if they spot problems, designers have the final say.
In the case of data management projects within the investment management industry, the process is all too often the complete reverse. The technicians generate a highly technical (sometimes almost academic) rationale for a certain configuration and then look to find a business need that justifies their plan. There is an absence of direction from truly visionary people—those who understand what it is that the business needs and who can then hand a concept to the data team to bring to life.
A lack of vision and clarity
Too many data management professionals are people who should be delivering and executing, not designing and driving. If the mechanics began the process of building a car, it would be a different beast—ugly, over-engineered, late and no one would want to drive it. Similarly, data management projects require vision, design, commercial appeal and a clear deliverable.
As a consequence, there is a danger that data management infrastructures can become overly-complex, functional monstrosities that are immobile, cumbersome, have a high cost of ownership and little tangible commercial value. Such a description sounds like an area ripe for outsourcing to custodians or other third-party administrators, yet the lack of specialist outsourcers present in the domain of data management (aside from the increasingly common reference data utility models) suggests that there is a lack of clarity over what is required.
Data management is not data governance
This lack of clarity is due in part to the fact that the discipline of data management is not the same as the discipline of data governance. As firms seek to introduce major data management initiatives, perhaps as a result of a new market opportunity, they often look to internal ‘experts’ to provide the strategic framework. These experts have very often come from a data governance or technical background (and mindset). They are generally not individuals driven by concepts such as business agility, speed to market, servicing clients or product launches.
The result is that current data management products and services tend to be toolkit-based, as there is a lack of clear and defined needs from the buyers (the asset managers). These toolkits themselves generate demand for yet more “mechanics” and IT experts, who are influential in the system selection process but perhaps lack the high level business vision required.
How will the custodians respond?
In the custodian world, some firms are offering a limited form of data management as an extension of their service package. The services include initiatives such as improving access to data across the firm. For a custodian to build a complex new service for the asset management community, there has to be a clear commercial proposition—a value add, a cost reduction and so on.
The problem is that while the “mechanics” are specifying the programs and there is no clear set of commercial requirements from the buyers, it makes it very difficult for the service providers to deliver truly transformational data management projects.
Some would argue that in such opaque circumstances, there is a danger that the service providers will design data programs that merely make themselves more “sticky” rather than delivering a tangible benefit.
Conclusion
Of course, one of the reasons why data management is so complex is that the asset management industry has a long history as a “best of breed” environment, where multiple systems have been deployed in the same firm, driven by varying market, instrument or investment strategy preferences. As a consequence, it is an environment where data silos thrive. Part of the rationale for many data management projects such as an IBOR (Investment Book of Records) should be to enable the asset manager to eradicate these silos, reduce the number of systems it runs and allow the firm to maintain a central repository for all its positions data.
In summary, the problem is that many data management projects today do not have clear business objectives and consequently become meandering journeys without any clear destination. All too often they are tactical programs with heavily over-engineered requirements, designed by the “mechanics.”
It’s time to break the mould and start again.