That Is The Question
By FDI’s Program Management Team
Your organization has huge amounts of data in legacy and redundant applications that need to be retained, but the applications’ core functionality is no longer required. These applications are costly to maintain, and your data may be at risk due to security vulnerabilities.
You decide to archive your data. One of the decisions you’ll need to make is whether you’ll need a graphical user interface (GUI) to access your data. However, is developing a GUI worth the time, money, and effort?
What You Need to Consider
In order to answer this question, you need to analyze who needs to access the data and for what business purpose:
- Who will be the primary users of the archive?
- What groups do they represent?
- How often will the data be accessed?
- Why will the data be accessed?
- How quickly does the data need to be made accessible and in what format?
- Is the data coming from a single source or multiple sources?
- Will the data be accessed in a planned manner (specific data at a specific date) or will requests for data be more ad hoc?
Key to this process is to focus on the required business use of the data. Be careful about broadly analyzing past usage of the application as this could lead to users’ wanting to recreate their entire legacy application.
Once the ongoing business needs are understood, you can evaluate whether a GUI is needed or not.
The Pros and Cons of Developing a GUI
There are pros and cons to building a GUI so that your static data can be readily accessed from your archive.
The main reason to develop a GUI is to provide users access to the required archived data in a quick and easy fashion.
Pre-defined search and reporting capabilities, along with graphics for analytics, can be defined that deliver rapid business value in a fraction of what it used to cost to maintain the legacy application. However, a GUI for the archive will cost time, resources, and money to develop.
First, there is the requirements analysis. You will need to understand how the system will be used and for what purpose. It’s important to obtain screen shots and examples of associated reports from the legacy application as well as to gather any documentation on the system (data dictionaries, schemas, etc.). Then mapping of the required fields from the archive screens and reports to the database will need to be performed.
Next, there is development and test, AND the indexes. Indexes are crucial to archived data so that the most used queries are optimized for speed. This can take time to analyze and then even more time to create. Indexing archived data can’t be taken lightly. Rapid response time is key to successful adoption of an archived system.
We find that incremental development and testing using an agreed upon test set that fully exercises the system is best. This provides the ability to demonstrate parts of the archive system so subject matter experts (SMEs) can validate that the required functionality is present in the archive and enable development to course correct early.
At times, an application or applications to be archived can represent data from several systems. This can make it challenging to interpret the data and map it so that it can be served in the GUI. Database SMEs, documentation on the legacy systems, or SQL tracing can be used.
Data on a screen in the source system can also be derived through ‘hidden application logic’ (e.g., if field “A” is blank, get the data from field “B”). Again, the database SMEs are crucial as well as good documentation or SQL tracing. If any are missing, the time investment to determine the data mapping can increase greatly.
User Acceptance Testing (UAT) is also critical, and planning needs to be performed well in advance to secure time from key participants to ensure their active engagement. Sometimes, there can be multiple rounds of user acceptance testing before the archived system is production ready.
What if you don’t develop a GUI?
If the legacy application data does not need to be readily accessed in a pre-defined fashion and can be accessed in a more ad-hoc nature with ample time to spare, you may want to consider migrating the data into the archive, but not developing a GUI.
Instead, queries can be developed to access the data on an as-needed basis. However, if at a later time a GUI needs to be developed and the SMEs who understand that application and database structure are no longer available, the investment to create a GUI could be substantially higher than if it were developed when initially archiving the application.
With a non-GUI archive, there is a lower cost of entry for archiving. The extract, transform, and load (ETL) process is the same for both GUIs and non-GUIs. For the non-GUI archives, once the ETL process is completed, simple indexes are created, and simple queries are performed to smoke test the data.
Most likely, only data administrators (or those authorized to have data administration privileges) will have access to the data in the future. Skill sets are important for this group. Depending on the underlying archive platform, new skills may be required. For example, an archive using an XML database may require knowledge of XQuery. An XML-based archive which supports SQL querying may help to ease the skill set changes.
Some indexes can take a long time to create and they need to be created thoughtfully so that performance is not degraded. If an ad-hoc request comes along, be aware that the answer to that request may take quite a while due to index creation.
To GUI or not to GUI?
The answer really lies in how your organization will be using the newly archived data and how long people needing the data can wait to retrieve it.
Flatirons has done numerous data archiving projects for clients both with and without GUIs. If you’re looking for additional advice, we’d be glad to provide more insight.
