Tag Archive: replang

As a provider of technology solutions for financial services firms small and large nationwide, I frequently come in contact with investment firms of diverse dynamics and decision-making processes.  I am, of course, familiar with the process and discipline of getting

three separate quotes for goods and services, but even after decades of bidding on projects, it is still unclear to me what investment firms actually do with this information.

In some cases, it seems like the decision has already been made and prospects are just going through the motions to fulfill the expectation to follow a procedure and process established by their firm.  Gut decisions sometimes overrule common sense.

One of my clients actually adheres to this discipline for everything and, if the rumors are true, even gets three prices for paper clips.  In my own experience with them, they did, in fact, get three quotes for a single piece of computer equipment that cost about $75.  Considering current wage and consulting rates this arguably may not be a good use of time or money.  Perhaps it’s a more altruistic goal of keeping our economy competitive that drives their policy.



Recently, I was contacted by a firm looking for assistance with some Axys report modifications.  One of our competitors provided them with a quote for the work they needed.  The prospect felt that the price was too high and they solicited my opinion.  I never saw the quote from my competitor, but heard from the prospect that they wanted 3-4k up front and expected it would cost 7-8k.  In another conversation, I was told that there was also a local company bidding on the work.  That made sense to me – three bids.

I was provided with a detailed specification of what needed to be done and asked to provide them with a quote.  The firm was looking to make some modifications to the Axys report that generates Advent’s performance history data and stores it as Net of Fees (PRF) and Gross of Fees (PBF) data.  Though the requirements seemed complicated initially, it eventually became clear to me that the job simply required filtering of a couple REPLANG routines, and some minor additions.

I shared my impression with the prospect and ball-parked our bid at 3k (a 12 hour block of time) less than half of our known competitor’s bid.   I explained that the actual work was likely to take three to four hours, and rest of the time would be spent on testing, support and maintenance.  My expectation was that we would get the work done in a half day to a day at most and the remainder of our time could be used for any required maintenance or modification later in the year.



After about a week, I called to follow up and found out that the firm was strongly considering having the work done by their local vendor, who told them it could be done for seven to ten days.  “Excuse me,” I said.  “Don’t you mean seven to ten hours?”

“No,” he replied.  He further explained that they really like using the local vendor and would probably use them for the job, which I fully understand.  I have, no doubt, benefited from this sentiment in Boston for years.  At that point in the call, I was thinking that it was more like seven to ten lines of code, but thankfully I didn’t start laughing.  I waited until the call ended.


No Risk, No Reward

In the end, your firm’s decision to select one bid over another is a personal one, similar in some respects to the one that dictates an investment adviser’s success attracting new clients and retaining them.  It’s about trust, performance, and the ability to continually communicate that you are worthy of one and capable of the other.  To succeed long-term in the financial services business, you need both.  Through good performance, we gain a measure of trust.  However, without a measure of initial trust or risk, there is no opportunity to perform.

About the Author: Kevin Shea is President of InfoSystems Integrated, Inc. (ISI); ISI provides a wide variety of outsourced IT solutions to investment advisors nationwide. For details, please visit isitc.com or contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@isitc.com.

Though an increasing number of firms pride themselves on their ability to fire out reports within the first week of the quarter, it seems that most firms still produce and mail out their statements in the second or third week.  Yes, I said “mail out.”  Even firms that have invested in the ability to post their reports to a web portal still mail most of their reports out due to low adoption rates by their clients.   Investment advisors that don’t get their reports out within the first three weeks of quarter end are operating outside of the norm.

There are 13 weeks in a quarter.  Given that most firms send quarter end reports during week two, operations folks aren’t thinking about doing an upgrade in week three.  They’re busy catching up on what they didn’t do in weeks one and two, while they were managing the client reporting process.  That leaves ten possible weeks for a system upgrade.  Weeks four through six are ideal, giving your firm adequate time to test your systems and apply fixes as necessary.

Weeks seven to 13 become increasingly unappealing; lucky number 13 is the worst possible time to perform a system upgrade.  Most people in the investment business know this.  With 25 years of experience installing Advent products, I consider the time approaching quarter end an obvious no-fly zone for in-place system upgrades, no matter how competent you are.  I was stunned yesterday when I received a call from a customer related to a system upgrade.

Apparently, someone working with Advent talked them into upgrading to Axys 3.8.5 last week, telling them they wouldn’t have any problems with the upgrade.  When you are unfamiliar with a client site, broad-sweeping statements like this are all too easy to make.  After the upgrade, their billing reports didn’t work.  The representative doing the upgrade was able to fix the standard billing report, but could not fix our compound billing report, which is used to generate client invoices.

Billing Report (created via compound reporting macros and replang)

Due to this issue, our customer’s billing process was on hold this week until the issue was resolved.  We received their call yesterday afternoon, and called them back before close of business, but didn’t hear from them until today.  We promptly connected to their system, reviewed their issue and resolved it; however, this incident certainly had the potential to end in technical tragedy.

I recently blogged on the different versions of Axys 3.x we see in use working with Advent clients.  The blog indicated that Axys 3.8.5 is a solid product release and should be an easy upgrade for users, but also underscored the need for users with customizations to anticipate difficulties.

Advent typically shows good sense in planning.  For example, in Axys to APX conversions, systems are run in parallel for months.  I am disappointed to hear about this incident, which I can only hope is an oversight, not the modus operandi for Axys upgrades.

Some people feel the need to push ahead no matter how close they are to quarter end.  Perhaps they make a bit more progress in doing so. Still the question for me is what benefit this upgrade had last week versus a couple weeks from now when quarter end reports have been produced.  If there is a benefit that offsets the risk, I am all for it.  In this case, I just don’t see it – not for my client.

About the Author:
Kevin Shea is President of InfoSystems Integrated, Inc. (ISI); ISI provides a wide variety of outsourced IT solutions to investment advisors nationwide. For details, please visit isitc.com or contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@isitc.com.

Unless your computer systems have been severely neglected, the time required to run Axys reports on any given day is unlikely to disappoint most users. Axys taps data and produces most de facto reports promptly. Axys users with less than a hundred portfolios are unlikely to care about processing speed issues, but for those of you that have several hundred or thousands of portfolios, the following performance enhancing tips for Axys can shave hours or perhaps days of processing time at quarter end:

1. Reign in Overzealous Virus Scanning
Norton Antivirus and other Antivirus products are engineered to perform real-time virus checks on all files every time they are accessed. While this functionality makes a lot of sense for office documents that could harbor viruses and the bulk of your company files, repetitively checking Axys file types is unlikely to uncover any viruses. In order to speed processing, disable real-time Antivirus checks on either selected folders like Axys3 or specific file types — like CLI files. It is still prudent to scan all files for viruses in a regular evening process. It just doesn’t make sense to check them each and every time they are accessed.

2. Optimize Network Configuration
In this day and age we still occasionally run into companies that have obviously spent plenty of money on technology, but overlooked the network needs of their investment operations area. IT consultants and/or in-house staff need to understand that Axys is not a client server application. As such, processing takes place on a user’s local machine, but is also dependent on server speed since files effectively need to be transferred to the local workstation so they can be processed. All workstations should be configured with gigabit network cards and connected to the server hosting the Axys application via gigabit switches. This sounds relatively straightforward, but “the devil is in the details.” If a multiple switches exist between the server and the workstations all of the switches involved need to be gigabit switches. The server should have a gigabit card. Most importantly the network cards on the workstations and server should be configured to connect at gigabit speeds.

3. Process Data Directly from the Server
If improving the network speed can enhance Axys performance, removing the network factor from the equation could further boost processing speed. In most circumstances, the operations team does not have the ability to connect to the server that houses Axys and run applications at their whim. Processing from the server can make sense in some smaller installations or in situations where the operations staff has been blessed with their own dedicated server that they have authority to use as they wish. However, processing directly from the server does not guarantee improved performance over processing from a networked workstation. It is possible that a server with poor processing power would under perform when compared with a faster computer connected to the server via a gigabit network connection. As IT professionals ourselves, we have reservations regarding this approach to resolving speed issues and do not currently believe it is a best practice.

4. Distribute Processing Across Multiple Workstations
Establishing the framework to be able to do report production in parallel empowers firms to scale their production as their business grows. If proper planning is done up front to organize the work required by various business units at a company, report production can be parceled off and done simultaneously or asynchronously as various business units demand. Proper planning entails creating the reports, scripts and macros to support parallel report production. Without the necessary infrastructure design and corresponding development, scripts and macros architected for a single user environment can’t be run autonomously as needed.

5. Buy a Faster Workstation(s) and/or Server
Buying a faster workstation should increase your processing speed, but it is conceivable that a bottleneck could exist at the server that limits the positive effect of purchasing a faster workstation. Likewise, buying a brand new server that is connected to older workstations will only do so much. When considering new hardware purchases, make sure you examine all possible bottlenecks. In our experience assisting clients with the development and integration necessary to automate their reporting systems, we found individual user’s Axys processing performance varied greatly. Recognizing the need to benchmark Axys processing speed, we created a simple report in REPLANG that allows us to quickly evaluate Axys performance from any workstation. This utility and other Axys tools are available from our website.

Feel free to download our basic speed test report (speed.rep) at www.isitc.com\aug or recreate it from the code listed below:

format 0
.Axys Processing Speed Benchmark Test\n
.v1.00 Last Modified 01-12-2007\n
.Copyright 2007 InfoSystems Integrated Inc.\n
.All rights reserved.\n
#limit 10000
#accounts 0
ask #limit Enter the number of records to read?
#limit #limit 1-
.Start time $:now\n
label cc
load cli
#accounts #accounts 1+
if #accounts #limit >
goto ee
next cli
goto cc
label ee
. End time $:now\n
.#accounts read.\n\n

As you review and potentially implement the tips from this article, perform follow up speed checks to measure the effectiveness of the methods detailed. Test processing with our “speed report” from each individual workstation and your Axys server if possible. If all of your equipment is standardized you will likely see very little difference in the benchmarks of various workstations. In my own tests, the processing time of 10,000 records went from 46 seconds to 3 seconds, making me wonder why I didn’t optimize my environment sooner.

This article was originally published in the Advent User Group newsletter in 2007.

About the Author:
Kevin Shea is President of InfoSystems Integrated, Inc. (ISI); ISI provides a wide variety of outsourced IT solutions to investment advisors nationwide. For more information, please visit isitc.com, contact Kevin Shea via phone at 617-720-3400 x202, or e-mail at kshea@isitc.com.