Featured Image

Untangling the IT Landscape

Data Science and AI

By Dan Rose  |  December 28, 2016

Financial firms rely on a mind-boggling array of data and technological processes to get the intelligence they need to make decisions. But with the transition to today’s advanced technology environments occurring almost overnight, many organizations are relying on data architectures, software, and workflows that have not been optimized to fit their needs. As a result, inefficiencies and overspending abound, while untangling the network of legacy systems and processes becomes ever more difficult as new technologies are added.

Firms have begun to ask how technology is used across the business, and in many cases they’re realizing that while they’re paying for multiple systems, they lack ways to determine if those systems are working well together. For example, where do multiple platforms exist to solve the same business process? And where is the architecture outside the industry standard?

Answering these questions may not only reduce the operational costs associated with licensing software and technology solutions and maintaining them, but also lower operational risk by highlighting inefficiencies. While the IT department has become an increasingly critical stakeholder at most investment firms, however, it is often unprepared or understaffed to address the monumental task of mapping the IT landscape.

With decades spent implementing and integrating financial solutions for firms, FactSet has developed a four-phase method of mapping these workflows that helps organizations better understand what’s under the hood of their firm’s investment process.

ITL_Template _CompanyX_PM_AC.jpg

Step One: Catalog the Existing Ecosystem

The first task is understanding the components of your IT ecosystem, with the goal of cataloging vendors, technologies, and data types, and determining how those components interact. The exchange of information between systems is the fundamental building blocks of any workflow, and you want to ensure every transaction is documented.

Suppose your firm relies on multiple fixed income attribution systems, but has only one with data flows to and from others. The consistency of content within systems may not be obvious during day-to-day operations especially when they are assigned and maintained by isolated teams, but can result in inconsistencies when multiple data flows (with potential formatting differences) feed one system.  Circumstances like this demonstrate the nuances that can be uncovered during the cataloguing phase and expose system dependencies across the organization that may not be explicit otherwise.

Step Two: Match System Components to Their Business Objectives

After mapping and cataloguing the components of the system, we recommend looking at the business objectives they’re associated with. Your goal is not to replicate a traditional system diagram but to identify and catalog each system against a taxonomy that is based on business needs and technical references.

Without aligning systems to their objectives, you risk introducing misdirected effort. Recently, I worked with a large U.S.-based asset manager with global affiliates that had made the strategic decision to migrate a number of its distributed data warehouses to a central platform, with the goal of ensuring global consistency and single source of security reference data.

When I came to the project, the product choice roadmap had already been laid out by the technology teams and implementation had progressed to the point where over half of the deprecated systems were migrated or on target to be. But upon closer inspection, we identified sources of conflict that manifested themselves through data reconciliation tasks the operations teams was performing on behalf of performance teams and others.

As a result, there was an inherent misalignment between vendor sources on common items and questions about the products selected to meet the organization’s goals. Ultimately this required the organization to discuss alternatives to the products they had already selected, including the selection of a new security reference data feed. 

Step Three: Isolate Workflows to Reveal Overlap

Once you’ve tagged these systems and their relationships to one another, you’ll be better prepared to draw out your firm’s system architecture and overlay the taxonomy you’ve developed so you can isolate specific workflows. This exercise should reveal overlaps of effort, where multiple systems are working to accomplish the same task.

Using this type of mapping process, another firm I worked with was able to identify the inefficiencies of sending five separate accounting system’s holdings data to its vendors, which could potentially effect data quality and consistency. By standardizing the data through a central portfolio store with cleaner architecture, the organization was able to inoculate itself to such quality issues.

Step Four: Identify and Document Needed Modifications

Once you’ve successfully mapped out the architecture of your information technology ecosystem, you’ll need to create action items that address the inefficiencies that have been uncovered, document workflow adjustments that need to occur, and communicate new requirements to stakeholders.

At this point, it may be advisable to contact a third party to confirm that both the map and the action items conform to industry standards and bring the most efficiency possible to your workflows.

In our process, after delivering a IT landscape map for clients, FactSet provides documentation that creates comprehensive and actionable feedback with unbiased observations and commentary, focused on answering questions like those outlined above.

While tackling this problem is daunting, as the minimum bar for investment technology continues to rise, it’s one that financial firms will need to address. Doing so as soon as possible may not only save you money, but can instill technology best practices at a firm that can facilitate the integration of even better tools and solutions.

Subscribe to FactSet Insight

Dan Rose

Vice President, Director, Technology Solutions Engineering

Comments

The information contained in this article is not investment advice. FactSet does not endorse or recommend any investments and assumes no liability for any consequence relating directly or indirectly to any action or inaction taken based on the information contained in this article.