Tag Archive: Advent


Whether you are an investment professional or an individual investor, you want to be on the respective sending or receiving end of meaningful statements that effectively convey what has transpired on a quarterly basis. These reports may represent clients and investors’ only communication of the quarter. As such, the importance of mainstream client reports cannot be underestimated. Advisors do not necessarily need a state-of-the-art reporting package, but they also cannot afford to have their reports look dated.

A couple of years ago, I was approached by an investment firm looking to overhaul their client statements. The impetus was the departure of a client, who was “nice” enough to drop off a sample of their new investment advisor’s reporting package. I was presented with the package and asked how much it would cost to do something like this for them.

I went through the lengthy presentation-quality package in detail. It was clearly something that was produced through a custom report-writing engine or a third-party, and not a standard report package by any means. The reports included comprehensive summaries of holdings, allocation, fixed income, equity, and performance. All of the reports contained detailed graphs and charts.

We came up with a number – roughly 50k – and we were not surprised when the prospective client did a double take and put the project out for other bids. Our bid was for a system that worked with the underlying Advent data, but stood on its own. In order to produce the high-quality output they wanted, we needed to get the data out of Axys and into a format where we would be able to use report-writing tools like Crystal Reports and SQL Server Reporting Services (SSRS). That would enable us to create reports of the same caliber. We had done it successfully for other clients and knew what was required.

However, our prospective client made some internal concessions on the presentation-quality aspect of the reports they wanted versus that original package, and eventually agreed to have a less expensive, but well-known competitor do the work as custom compound reports. Shortly after the job began, they started hearing a two letter word few advisors like — NO. It was the answer to whether they could have certain reports in landscape or portrait. And it was the answer to whether certain report components could appear on the same page.

With that experience in mind, the client called us back and asked us if we could do the job using compound reports. We agreed and said YES to all of their requests. We delivered their new reporting package, which consisted of the same types of portfolio summaries they had originally shown us. The reports are generated through the use of compound Axys reports and assembled via Encore, our PDF report packaging application.

The client reports that you send out every quarter are a representation of who your firm is and what you do. Good quarterly reports are an opportunity for your firm to maintain or improve your clients’ opinion of your service. Conversely, substandard quarterly reports are a liability that speaks to your clients every quarter. What do your quarterly reports say about your firm?

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.

There are plenty of lackluster reporting packages that get sent to investors, but every once in a while, you may see a reporting package that is truly impressive in terms of content and presentation. When you do see something that looks that good, it is only natural to wonder how it was done and at what cost. If the package is exceptional, then chances are somebody spent mucho dinero to make it so.

Back in the 80s when I started using The Professional Portfolio, the pre-Windows version of what is now known as Axys, there were relatively few easy ways to enhance reporting. Like a lot of things back then, we had to do it the hard way. There were then, as now, limits to what could be done within Advent’s infrastructure. When we came up against something that could not be done, or could not without Herculean efforts, we stepped outside of the environment and utilized programming tools to get the job done.

One of the first major projects I worked on was a client billing system that generated management fee summaries for custodians, and invoices for clients; it had many of the same features that have only recently become available to Axys users. That program was written in QuickBasic almost 20 years ago. In order to produce presentation quality invoices, specific HPGL2 (“printer language”) code needed to be written to format text and shade certain areas. The results were first rate but the effort necessary was daunting.

In the 90s, we started using Visual Basic (VB) to create one-page account summaries for our clients. By 1995 we were using VB and Crystal Reports to create reporting systems that were way ahead of their time, but the work behind the scenes was still considerable. Over the years, report writing products have evolved, becoming more robust and making it simpler than ever to produce sophisticated reports. There are two fundamental ways you can produce better reports in-house: within the Axys/APX environment or outside of the Axys/APX environment

Staying within has the potential benefits of keeping initial implementation costs down, facilitating standard Axys automation techniques, and lowering future maintenance costs. Cost may be kept in check by nature of the fact that the Axys/APX system’s rigid infrastructure puts the kibosh on what can be done. This approach is absolutely fine for firms that have simple reporting requirements and are willing to accept the limits imposed by this choice.

Here are some report enhancing tips for those staying within the Axys/APX envelope:

1. Utilize Axys master pages and consistent reporting styles to create continuity across reports.
2. The macro based compound reporting feature need not be used to create reports that look like they were “shrinky-dinked” to fit on the same page. Perseverance, patience and creativity usually payoff when designing compound reports.
3. Axys formatting has a certain look and feel that is dependent on report writing syntax. Most of the time you want Axys formatting, but if you don’t want standard formatting you can work your way around it by showing an Excel worksheet instead of a graph and formatting the Excel sheet with Excel macros.
4. Advent’s Excel data link can be further leveraged by utilizing Excel graph add-ins to give your reports a presentation quality that exceeds standard faire Excel graphs.
5. Battle-tested integrators should know that the limits of Excel integration can be stretched to allow the insertion of related data that may not be in Axys or the APX database.
6. It is sometimes okay to tell REPLANG a white lie about whether the report is really a one page report to get all the reports you want to fit on the page.
7. APX features “public views” which allow technology savvy users to create reports from the APX database. However, the public views are limited and do not give these same users access to all of the data they would like.

Staying within the confines of Axys/APX comes with a cost. The compound reporting feature can be finicky. Some things that should work do not work as expected. The resulting trial and error testing can be frustrating and time-consuming. In some cases, you may eventually find that you cannot do something that you should be able to do, forcing you to figure out an alternative way to reach your goal. These mindbending setbacks can delay or derail a reporting project.

This is a sample of what we have done working within the Axys/APX environment to create custom reports using compound report macros.To see more samples click on these links: portrait #1, portrait #2landscape #1 and landscape #2.

Stepping outside of the Axys/APX environment by extracting the data and placing it in a database opens up a new world of possibilities, but it should only be done if complex reporting requirements demand it.

The key perceived benefits of this approach can be best described in one word – flexibility. As a direct result of having data accessible in a standard database rather than a proprietary data format, you gain the ability to use report writing tools like Crystal Reports or SQL Server Reporting Services (SSRS) to produce complex reports efficiently, thereby placing your report developers in a more mainstream development environment where solutions to problems encountered are more readily available. This provides a foundation that empowers consultants/staff to act without necessarily requiring a subject matter expert to facilitate progress.

Some guidelines for creating a successful report production environment outside of Axys/APX follow:

1. Extract all the data you need from Axys/APX. You should have a subject matter expert architect and assist with the development of this feature or buy a product that performs the extract for you.
2. Design a well organized data structure.
3. Import data and perform data quality checks up at the earliest point in your report generation process.
4. Create standard report templates similar to Axys master pages and report styles functionality.
5. Take the time to mockup/document the possible permutations of report packages and determine what the process to generate your reports will look like. Seemingly, little details like page numbers, PDF merging, letterhead, disclosures can be a thorn in your side if you do not plan adequately for them in advance.

This is a sample of what we have done by stepping outside of the Axys/APX environment using Crystal Reports to create custom reports.Click on the following link to see more samples: landscape

Beware; this approach is not perfect either. The newfound, godlike ability to make any report cuts both ways. Because you can do almost anything, you will likely spend more time designing reports than you would have. Popular report writing programs have idiosyncrasies, too. As you develop your reports, you will no doubt be disappointed to learn that your chosen solution set has limitations of its own. Report development in this environment typically takes longer, but has more predictable results and corresponding timelines. Using this method also requires that you retain reliable and responsive resources with the ability to maintain and enhance your system as needs change over time.

The labor required to produce reports outside of Axys/APX is a multiple of what it costs to do so within Axys/APX, but the resulting reporting packages should be easily identified as high-end boutique productions, not standard client reporting packages. For companies that consider their reporting systems a top priority and are willing to allocate the necessary resources to produce uniquely engaging reporting packages, going outside the Axys/APX envelope makes sense.

This article was originally published in the Advent Users Group newsletter in 2008.

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.

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 http://www.isitc.com\aug or recreate it from the code listed below:

 

REPLANG
format 0

.\n\n\n\n
.Axys Processing Speed Benchmark Test\n

; written in replang by Kevin Shea (aka AdventGuru) & updated 01/12/2007
; Disclaimer: This routine works fine for the specific instance it was
; created for, but could need additional modifications for different
; circumstances.

#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
end

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.

Last year, I helped one of our smaller clients get a new phone system – not because they needed one, but because the owner decided it was time for something NEW. There was nothing wrong with the old system, and I am fairly sure that this particular client will get no additional benefit due to their limited use of the phone system. I appreciate this approach when applied to the purchase of new computer equipment, which naturally obsoletes itself as new software updates are implemented. However, the NEW logic that was used to send the old phone system to the landfill was lost on me.

More recently, I experienced a similar issue with a client of ours in regard to their portfolio management system. After many years of using Axys, they decided they were ready for something NEW. They didn’t spend much time considering APX. They wanted something really NEW (i.e., not Advent). I was concerned, and not about our own meal ticket. Though we do a lot of specialty work for Advent Software users, we do our best to remain impartial and support RIAs that use other portfolio management systems. If we see a better product that makes both technological and financial sense for a specific client’s requirements, we will let them know.

There are usually pros and cons to switching from one system to another. When making a decision to move from one portfolio management system to another you are effectively betting that the benefits will justify the cost. I was concerned that my client was making a bad decision, but I also didn’t want to be the naysayer. We spent a limited amount of time discussing the potential switch: I did my best to explain what it was that made their existing system so valuable, however underappreciated it currently was. I’ll blog on the virtues of Advent Software’s portfolio management systems in the near future, but in short, my opinion is summarized below:

Advent Software is a market leader with portfolio management systems that are mature and malleable. At its most fundamental level, the portfolio management system your firm uses is a foundation that can be built upon by your firm, third-parties, and your primary software vendor. A more mature infrastructure gives your firm fewer surprises and a wider variety of solutions to choose from. By selecting a leading portfolio management system your firm benefits from the logical motivation of third-party vendors to make their products available on that platform first ensuring that your firm has the ability to embrace emerging technology at a competitive pace.

At some point, we all want something NEW. It is an opportunity to get rid of the problems with which we have been dealing and get a new lease on life. And while getting a new whatchamacallit is a good thing when we are talking about your ten-year old car, it is not necessarily the right solution for problems with your spouse, or your ten-year old portfolio management system. Our client is now in the process of converting to INDATA, but we probably won’t know how happy they are with their decision until next year.

Unfortunately, the decision to replace your existing portfolio system with another less mature but newer-looking system is likely to result in disappointment. Conversions typically leave some of your data behind in order to get you into the new system in a timely and cost-effective manner. Firms that adopt new systems without sufficient research frequently find out that they have traded one set of problems for another. Those who champion the switch to a new portfolio management system want a successful outcome that validates their decision. As such, those who are most apt to recognize shortcomings early on may opt to sweep the inadequacies under the rug and stick to their guns rather than question their initial decision.

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.