If you've got an application written in the mid to late nineties through to recently and it's got reports; it's likely whether you realise it or not...you've got Crystal Reports inside of your enterprise.

The Crystal Reports tool was a staple in providing reports embedded into applications (both desktop and web) for two decades due to the speed of writing effective and visually superior reports in a fast manner. Although Crystal Reports remains a viable, strong and relevant technology in the broader community, mark-up languages have tended to be utilized more as applications move to a web based platform.

Crystal Reports are built and edited using either the Crystal Reports application or in latter times Visual Studio. Files with the extension RPT capture the report formatting and details which can be run standalone of embedded into applications. In application solutions this approach provided the benefit that once embedded the underlying RPT file could be "tweaked" as required without requiring the application to be redeployed. Users want to add a new column to that finance report....no problem ! Finance want to change the pie chart to a column....no problem !

So what does this mean in a business practical sense ? Commonly as applications age, budgets drop and the appetite to change (or invest) reduces, users are left in the lurch to work around issues such as the "no problem" scenarios mentioned above. Too often we see people still running these reports but then either scribbling all over them and/or exporting to Excel so they can recalculate certain columns since the rules have changed.

Although people have now forgotten the promise of "change as required" with these reports, the option still exists and can often add real value fast. In fact, the ability to hack a few reports may not only extend the usefulness of an application, but ultimately delay the cost and risk of it ending up on the application scrap heap.

To do a quick check yourself, search the folders hosting or application (or web server if a web app) for files with the extension *.RPT, and see what gets returned. The files will likely (and hopefully) identify through their filename the link to the report in the app eg. ApplicationAgedDeptorsReport.rpt and trigger inspiration that you may just be able to deliver that additional field to your users.

An Important thing to consider before going and purchasing a copy of the Crystal Reports application and "hacking" away is to that the underlying applications may have sensitivities to change. In particular should you want to remove fields or fundamentally change the report you may cause an application issue as most reports will seek out fields to do things such as establishing the report in the context of say Customer data. Always take a backup of files prior to any change, and be comfortable with being able to roll back. If your application has a support agreement in place, you also need to be aware of whether your changes may break any such arrangements.

Should you think that your application could do with a targeted boost to extract extra data trapped behind the scenes, this simple appraoch may be the trick.

Of course if you need any help or just some advice as to the art of the possible, drop us a line @ info@legati.com.au and see where we may be able to help.

Like all assets managed by a business, Legacy Assets cost the business in terms of:

Theinfrastructure to keep them runningThe salaries of staff that look after themSupport agreements in place to ensure users get get help when needed

The cost related to managing Legacy Assets can often increase over time in:

Keeping staff trained in older technologiesKeeping staff with specific knowledge of the application on staff for support when standard support agreements “dry up”Keeping older supporting hardware and infrasture outside of the organisations SoE online as the applications are unable to work on upgraded componentsUser Application Support - Helpdesk

Points 1 and 2 can be addressed under the banner of Knowledge Management, while 3 and 4 are Application Support related.

Knowledge Management

An organisation known had followed a policy of recruiting one or more staff from software vendors as they ended support for legacy versions. This was a strategy to keep support running on these applications through “insourcing skills”. Even in the event that the business acts to replace these insourced applications, risk remains in terms of staff turnover and even extortion as staff seek to leverage a known risk created by in their knowledge.

Outsourcing of this knowledge does not fully remove the risk of business knowledge but can work towards removing keyman risk. In an outsourced arrangement, the outsourced provider is obliged to have at least 2people with a working knowledge of the application at any one time. The natural turnover ion the outsourced provider is no longer an issue for the customer, as it is the obligation of the provider to remain compliant to contractual terms in keeping a number of skilled application experts.

Of course, the outsourcing has a cost which is a function of factors such as:

How much assured Service Level do you want the provider to have in place eg. No less than 2staff at a time trainedTurnaround times in the event of issues arising

This needs to be outweighed by working out the current cost in terms of the Fully Loaded Salary cost of resource applied on the project eg. If you have two Visual Basic 6 resources supporting your legacy payroll app, this is likely to be 2 x $120k = $240k p/a.

As with an internal insourcing where you may have a VB6.0 resource covering multiple legacy systems to reduce risk and cost, this arrangement can be built into outsourced agreements to reduce costs as you scale.

Application Support

Legacy Applications tend to slow in their development after an initial High Care, then stabilising phase. The operating systems and hardware they run on tend to be the systems that need to be upgraded and progressed on a more regular basis. While operating system vendors generally do a great job in maintaining backward compatibility, as with everything, all good things must come to an end and in the case of operating systems, features are eventually outdated and removed. For this reason, it is common that with older legacy applications that business must maintain a standalone operating environment for these applications. This creates a synchronous issue for the oragnisation as they must not only must maintain legacy skills in the legacy application but also potentially in older operating systems. The overhead of running an alternate environment with a different set of management tools and processes can increase quickly causing a doubling effect on the knowledge management issues above.

This again is a service that can be outsourced and generally combined with the knowledge management aspect.

This outsourcing arrangement is known as Application Support as a Service (ASaaS) and means that a business can rely on a single organisation offering a managed service covering:

The running of the application on a hosted environment (generally in the cloud)The management of the application to ensure it is online and “healthy”Effective change or fixing application defects (as required)Helpdesk

This outsourcing comes at a cost, however a formal review of internal costs may yield that current costs are more than you think and that a fully backed outsourced arrangement may make good business sense.

On commencing engagements with organisations bringing legacy assets to us, there is commonly a feeling of discomfort and embarrassment as they provide us details of their application. Our clients often dip their head and say things such as:

1. The business just hasn't had the time to address replacing the application

2. The business just hasn't had the funds with replacing the application and finally

3. The business does not have the appetite to face downing the application

All of these points have one thing in common for business; they are all valid business reasons and therefore who are we or anyone else to judge.

If you have called into this web site, it is likely that you not only would you admit to at least one of the above, but you have come to the point of acknowledging that it is time to take the next step in addressing the legacy issue.

Legati’s approach with Legacy Assets is to always take stock and Review and report upon the current state. This allows us to provide a considered report detailing information you need to understand what if any risks are inherent in your approach. It is our aim to turn an embarrassed admission of “The business just hasn't had the time to address replacing the application" into an empowered “The business has decided that the application is in stable enough condition to allow us to seek budget for next year to address a replacement project. In the interim, we are addressing some identified concerns”

This post starts with a leading question and to avoid disappointment does not answer it directly. Why ? Because it is a question that naturally starts with the phase “Well it depends…..”.

Let’s investigate the realm of the extreme by reviewing a bit of history. In the late 90’s the programmers of the world were faced with a (mad) rush to address the Y2K problem.

In perhaps the greatest example of what can be done to extend Legacy Assets, major financial institutions faced the choice of re-engaging (often retired) programmers to fix systems that had been untouched for 20years vs replacing their systems with new applications. Overwhelmingly most paid huge amounts of money to bring these long neglected programmers back in to address the issues….Why ? Because ultimately it was deemed cheaper and/or less risky than new system replacements. We may never be able to formally assess as to whether these large institutions made the right choice, but some 15years on those legacy systems largely remain the backbone of our financial management and banking systems.

These large institutions made and continue to make the decision that it is more prudent to keep their legacy assets alive as opposed to replacement.

What this shows is that it is possible to keep these applications "alive" much longer that the original suggested working life they were built for. One might be glib and point to these instituttions seemingly unlimited access to resources (both money and people); however the fact remains that they continue to make a business decision that it is more cost effective and risk adverse to continue on this path. It would seem inevitable that one day this cost and risk analysis will flip but for now, legacy does rule in these organisations.

In theory, every business therefore is faced with the same decision point in relation to aging applications, although their options may be limited (again people and money) in what they can realistically do in extending their life.

The basics of the decision come down to:

The uniqueness of the application and whether there is anything that could replace it in an Off the Shelf/SaaS capacityThe support lifecycle of the underlying components of the application eg. Will the application work on Windows Server 2012 which is being forced across the organisationIf the business were to support the application on its own infrastructure outside of the SoE, what is the additional management cost ?What is the level of support in the technology workforce to maintain the application eg. There are still a number of active Delphi programmers, but Turbo C++ resources are limited

These questions can only be answered by doing a review of the application to a deep enough technical level to arrive at options and recommendations for you to make the decision yourself as to “How much longer can we keep this alive ?”

Risk Management is a topic that yields a range of emotions in people. Some embrace the concept, while others run to the hills as though it’s some form of witch craft designed to find problems and cause more damage than good.

At the end of the day, everything in our personal and working lives is and could be a potential problem…..there I said it, things can go wrong.

Within an organisation, management too is all too aware of this also, however savvy management will want to know

a) what problems lurk round the corner and

b) what can we do to avoid the problem and/or reduce the damage the problem may cause.

Legacy Assets provide a special kind of angst in most organisations particularly when those who implemented/understood the application have moved on leaving those left to manage ongoing unsure as to:

How to fix it if it breaksHow to change it if the business changes

Inevitably, a fear based approach is taken revolving around “I don’t want to touch it in case it breaks” results and embeds. Hiding from the problem not only increases the likelihood of delays in the event of a failure, but also impacts the business’ ability to be able to positively change an application when the need arises. From this we see ithe rise of temporary workarounds resulting in Excel and Access running the business.

If your application is aging and ticks any of the boxes as being Utilised, Critical or Unique to the business, your organisation does have a business risk that needs to be understood and managed.

The good news is that that the application can be formally assessed, the risks documented and strategy put in place to manage the risk as the first step to being able to make appropriate business decisions as opposed to fear driven halts.

As a result of understanding the risk it can often be the case that you may for the first time in years open up the opportunity to actually revive and change legacy applications where “workarounds” had been the only perceived strategy.

Key areas in assessing risk in relation to legacy applications revolve around questions such as:

In the event of a problem, do we know someone who understands the technology ?In the event of needing to change an application, do we have sufficient knowledge of the application to quickly find the root of the problem and address a fixDoes the application/technology contain dependencies on underlying operating systems or components that are likely to change or be retired with by the vendor or within our application ?Do we have access to the source code in the event of failure ?Is the application written in a way that makes it plausible to change ?

In then assessing the required effort (time and money) in putting in place a strategy to manage the above risks, it is important to understand the types of strategies applicable:

Enacting a service agreement to provide servicePutting in simple changes to extend the life, support of the application eg. Moving it to a new server that will extend it 3more yearsLooking to replace the technology now or in x time

But before putting in a strategy, understanding is the key. Too often, the decision is made to replace an application at high expense and business risk (if it ain’t broke don’t fix it), when an application can be maintained for longer than expected or maintained for a longer period to enable a longer time frame for a more effective replacement in a hybrid arrangement.

Legati’s services stack has been developed in such a way to allow your organisation to undertake the Review process independent of other resolution services delivering a report that provides you with knowledge as to the actual size of the problem and a suggested approach to managing the risk.

Of course, we are able to assist and carry you forward into our additional services, but if you are looking for a report to table to the board, risk committee as a part of your risk management responsibility, this service may be for you.

In the process of putting together this web site, the team stumbled upon and adopted the term Legacy Asset. So what exactly is it ?

The term was organically arrived at and reflects our attitude to our business focus in looking after software applications that others other vendors will seek a replacement strategy.

Software systems are Asset’s to organisations. There may be a few sniggers in reviewing this statement, however no matter how frustrated you or your team may get at times, your business software is there to perform a job. If at any time the frustration outstrips it’s use you ultimately wouldn’t use it….right ?

So software does provide a service and therefore is an Asset to your business. As with any asset, its loss has a financial implication, specifically in the case of Software assets its financial impact will be in time spent, sales loss etc. dependent upon its specific role in the organisation.

The term Legacy refers to the fact that the software was written in an aging technology (such as Visual Basic) or that it was just written some time ago. Although the age of the software may have no impact on the key fact that it does as it was intended, it does start to introduce issues when the underlying operating systems and other supporting software needs to be upgraded. Also, as software ages, the supportability of the technology reduces as programmer’s skill up and more to concentrate on newer technologies.

Ultimately a Legacy Asset offers some value to your business. The actual value the organisation holds in a legacy asset will be based on a number of factors eg. if it manages the invoicing process versus capturing annual leave.

As they age, legacy assets may start to cause issues within a business which may cloud the value judgement. It is worthwhile sitting back and assessing these points with an open mind rather than arriving at a decision that it is no longer an Asset. As a part of our review service, we look to assess a Legacy Asset in terms of:

There is no pre-determined outcome in this assessment in realising a future goal, rather a fair assessment as to whether the asset is exactly that to the organisation.