Menu
As we continue to engage more customers, effective implementation has become a major topic of conversation both among the FundGuard team and within our client ecosystem.
We’ve talked previously about the technological advantages of an all-in-one investment accounting solution, but what does that solution look like on a practical level? How does that translate to common concerns like implementation, testing and upgrades?
To answer these questions, we spoke with FundGuard’s Program Management Director, Diane McLoughlin. With three decades of middle and back-office implementation experience, Diane has a unique and seasoned perspective on the evolution of accounting systems and data management solutions. Needless to say, Diane has seen it all!
Following is part one of her three-part series on the FundGuard Difference and its implications for transforming the tedium of legacy upgrade processes.
FG: Across the board, we’ve seen clients express a desire for intellectual change while lacking the technological knowledge or experience to execute a successful digital transformation. What do you see as the fundamental difference between FundGuard and legacy technology, and how do you help clients see it, too?
DM: When I speak to clients, upgrades are always at the top of their minds — but upgrades no longer matter in the same way as before.
If you think of the mindset our clients come from, they’ve likely spent one or two years between each upgrade or version of their legacy accounting software, creating this concept of upgrades that is very tedious and time-consuming. Not to mention that they are spending millions of dollars on this upgrade process, making it a touchy subject all around.
Comparatively, upgrades are really a non-issue. Our modern tech stack enables us to remove the entire legacy upgrade process with our blue-green deployment, a new approach to deployment and testing around which we have to help our clients adapt their thinking.
When clients request new functionalities or we announce new features, they often think, “I’m not going to see results from these upgrades within the next five years.” In reality, FundGuard can bring about meaningful developmental change as early as within the next quarter. There isn’t that inherent lag in time to market, which is a substantial difference compared to outdated legacy upgrades that do take years to achieve and implement.
“There isn’t that inherent lag of time to market that you would get in the legacy system.”
💡Here’s an example of why that matters: Think about front office teams hyper-focused on selling and delivering differentiated customer service. This creates ongoing tension with the back and middle office teams when dealing with legacy systems. It’s always a push-and-pull, because the accounting team needs to account for data before it can be traded. So you’ve got the accounting team sitting there saying, “Well, I can’t account for it, so you can’t trade it,” and the portfolio manager is saying, “I’m gonna trade it. You guys gotta figure it out.” And “figuring it out” has typically resulted in years of legacy systems stacked with bandaid-style solutions that create more accounting problems and potential errors down the line.
This challenge practically vanishes with FundGuard’s technology – from our accounting data as a real-time data source to our modern processes, we don’t have the legacy baggage to weigh our software down, and we are able to quickly add business-impacting functionality.
As a whole, the biggest hurdle I help clients overcome is reframing how they view investment accounting outside of the lens of legacy accounting.
FG: You touched on an interesting point that clients struggle to think of upgrades from a more modern lens rather than from a legacy perspective. Can you discuss how this impacts a client’s view on software as a whole and how new functionality can be deployed quickly?
DM: In the earlier days of my career, we would call different versions of software by a number, for example, version 5.5 or 7.0. Eventually, we evolved to calling them by their release years, like 2016 or 2017, and so forth.
For each of the hundreds of clients we managed, I had to track how many were on each version of the software. And within that major release there were also minor releases and hot fixes that were called branches, and in no time, you’re tracking hundreds of permutations on top of the many different versions that exist.
From the client’s mindset, they often think of being on a branch with a unique piece of code and wonder how they are going to get back to a more populated branch. Tangentially, with all the branches and sub branches, developers who build new functionality in a legacy system not only have to work on the new feature but they also spend time applying that code and testing it across a number of branches.
By contrast, FundGuard offers one code base via a multi-tenant software architecture, eliminating the need for many different versions of the same basic functions. This multi-tenant solution concept allows all clients to benefit from software updates while keeping the configuration tailored to their specific needs – an idea that takes some getting used to for clients raised on less flexible, more confined customizations.
Paired with blue-green deployment, you end up with just two versions of the code, the live version and the testing environment. You don’t have different branches running at the same time. As our current clients can attest, that can initially come across as unfathomable – that they won’t have to suffer through tedious upgrade processes that take years to finalize and that FundGuard does not have to maintain multiple versions of our code base.
FG: In addition to being obviously operationally inefficient, are there examples of how things can fall into pieces when mitigating risk across many different branches of software compared to FundGuard’s singular environment?
DM: When you have to put functionality into multiple different versions and then test those functionalities individually, several problems can occur. Even if you have automated testing, the challenge centers around what to do when something goes wrong with one of the versions. Also related is the need for different data sets when increasing functionality.
This is where the concept of upward compatibility stems from, a concept that FundGuard aims to address and employ directly.
Any new functionalities inherent in our development are immediately made upwardly compatible. So, for example, if yesterday I needed five fields but now, because I have new functionality, I need ten data elements, our developer makes sure I have those five additional elements.
This is a big mindset shift for the client and for developers plagued by legacy thinking: In legacy systems, the developer would have to build the new functionality and someone else – often the client, the vendor implementation team or the vendor support team – would have to worry about increasing the elements from five to ten, rather than directly assigning such tasks to the developers. But in the FundGuard development process, seamless upgrades have become a reality – beyond expanding the functionality it is also the developer’s responsibility to deliver the code and data required for previous users to use the expanded functionality.
FundGuard really tries to center itself around this more modern coding philosophy. We prioritize simpler, more streamlined development that isn’t fractured across many branches.
FG: One way FundGuard takes a distinctive approach to investment accounting compared to legacy systems is how we treat data. Can you explain your perspective on data and how you work with clients to create more precise functionalities?
DM: I started out as a programmer. I won’t tell you what software languages I can code in but, when I was programming, coding the reports last was a common practice, which would result in bad (sometimes even missing) data, leading to bigger project delays down the line.
Our mindset at FundGuard is to avoid such issues by looking at the data first. We want to find out the “gotchas,” so to speak – for example if your legacy system has flagged a derivative as an equity – these are the things we need to know and address from the beginning, not the end.
We don’t encourage our clients to directly move from their legacy accounting systems over to a modern platform without first untangling the workarounds and bandaids I mentioned earlier. Instead, we want them to embrace an entirely new, cloud-native approach. Legacy system shortcuts ultimately just slow us down and make it harder to consolidate all of the necessary accounting data required.
With FundGuard, we start with clean data, so we know with great accuracy what the beginning position is and we can build from there. We even go so far as to make the decision not to convert data from a legacy system but build the accounting position correctly at time of conversion.
FG: Errors happen, but when they do, they can be hugely disruptive to trade and investment activities. Our team has previously discussed FundGuard’s immutability and data model, but how does FundGuard reimagine the legacy process of rolling back data to issue corrections and make the process immutable?
DM: At FundGuard, we are not limited by the structure of a traditional data model which are often relational data models, allowing us to more naturally perform certain tasks that would be more difficult in a legacy system.
In terms of immutability, this allows us to change data across an entire system in more meaningful ways.
💡For example: Anyone in accounting knows they will have to perform a backdated trade at some point (commonly referred to as “As-of” processing). In one of my former companies, we had a database that housed all backdated trades and had to manually reference them to get to the correct position. During that backdated trade, the transactions were rolled back to just before the date of that trade, and the accounting team applied the trade. The application of that one backdate trade can have repercussions on today’s valuation all the way back to the date of the backdate.
For example, let’s say I have a position with 100 shares today. Then I get a backdated trade that says the trade actually happened sometime in the past, let’s say two days ago. From an accounting standpoint, I need to reflect that the trade occurred two days ago rather than today.
Typically with a legacy system, you would roll the data back and apply that trade. If the trade was a sell of 20 positions and I rolled forward to today based on that process, that would bring it to 80, making today’s position 80 rather than 100. But what if that inaccurate data has already been shared around to different functions or branches?
What immutability does is we take it one more level, because instead of rolling back, you can hop back to two days ago and apply it forward. That way, it will not only show that I have 80 shares today, but will also tell me that before that trade applied, I had 100. So, we have all these different permutations, which opens up so much analysis and data for the team to look at. You’re not rolling back — instead, you’re hopping back to that spot and then rolling forward with the ability to replay everything.
I am often reminded of something I heard at a conference where the keynote was Josh Linkner. He was speaking about transformation. He talked about doing a “judo flip” to look at your business from a completely different perspective. At FundGuard we have taken traditional thinking around upgrades, conversions and back dated transaction processing and delivered a new way to achieve results faster and with less effort.
We’re a new breed of investment accounting technology. We help you reduce risk, minimize costs, and transform your accounting process into a smooth, truly modern experience. Book a call with our team today to get started.
About the Author
100 Bishopsgate
18th Floor
London, EC2N 4AG, United Kingdom
Sign up for FundGuard Insights
Your use of information on this site is subject to the terms of our Legal Notice.
Please read our Privacy Policy.
