Featured
Application Development
Cyber Security
Management Consultancy
TW
Author
Tyler Weltz
Read time
4 minute read
Published
19 Mar 2026
Topics
AI and Data Science
Executive summary
Same functionality. Same codebase. A completely separate environment.
A hedge fund had an extensive process built within their investment management lifecycle including in-house and vendor applications. A need arose to start supplying the same services to a third party — with one development location that would allow enhancements to roll out to both in-house users and the third party simultaneously.
OmniVista analysed all features available to current users — custom logic, reports, visual effects, and scheduled processes — then outlined a plan to make all references configurable so the base code could be rolled to multiple locations with configuration files as the only differences. A hybrid team of consultants and hedge fund full-time personnel executed the complete application development lifecycle from design through implementation and testing.
Architecture
One shared codebase — two independently configured production environments
Rather than building separate codebases for each environment, OmniVista made all client-specific references configurable — so enhancements made to the base code automatically become available to both instances. Configuration files are the only difference between environments.
Dual-instance deployment model
Why configuration-driven?
→
Enhancements deployed once to the shared base automatically reach both environments — no duplicate development work.
→
No client name or acronym appears in the third party’s instance — all references are passed in via configurable parameters.
→
Reports, emails, and scheduled processes all read from configuration to determine which environment’s branding and data to use.
→
Third party had previous experience with the workflow — no training required, enabling a faster go-live.
Scope
14 components replicated for the third party
The client required that the third party would have all the same functionality and processes as their current users. Every component of the investment management lifecycle was included in the split.
Trading System (CRIMS)
Charles River Investment Management System — used to build and execute trades and pass to settlement. A full new instance created for the third party including Middle Tier, Citrix, Bloomberg Server, and FIX Server.
Custom trade flow & allocation services
Custom services managing trade routing and allocation logic — all hardcoded client references replaced with configurable system parameters.
Holdings & trade loads
Data loads to and from the in-house data repository — scheduled processes updated to accept company name as a parameter, distinguishing which environment is running.
Reports & reconciliations
Microsoft Reporting Services reports rebuilt with conditional logic in the header controlled by a configuration parameter — so headers display correctly for whichever environment the report is run from.
Custom trade importer (C# DLL AddIn)
A C# DLL created as a CRIMS AddIn — hardcoded default fund references replaced with a System Parameter within the CRIMS environment, making the tool fully instance-aware.
Custom buttons & position views
Custom UI elements within CRIMS — including custom buttons and a custom position view — replicated and configured for the third party environment.
Scheduled processes & email triggers
SQL Agent Jobs and Windows Task Scheduler processes rebuilt with parameterised stored procedures. Email triggers updated to accept company name as a parameter — controlling the subject line per environment.
FIX connectivity, Bloomberg & Omgeo CTM
FIX Server, Bloomberg instances, and Omgeo CTM broker matching all configured for the new third party environment — including new CTM user setup, profiles, and end-to-end flow testing.
Implementation
From hardcoded to configurable — a systematic approach
The first step was identifying every instance where the client’s name was hardcoded — across database table values, custom logic, reports, and database objects. A stored procedure was created to search all database tables for the client’s name or acronym. Everything found was documented as a required change before any third party instance work began.
Result
Two production environments. One maintenance burden.
The result was two production Investment Management instances sharing the same base code, each configured separately. After initial setup, the production database was copied from the client environment to the third party and cleanup scripts ensured no client information existed in the new environment.
One codebase. Two production environments. Zero duplicate maintenance.
OmniVista · Application development · Management consultancy
Need to extend your investment management stack to a third party?
OmniVista designs and implements configurable, multi-environment infrastructure for investment management firms.
