Rebuild: Desktop to Modern Web-Based Software

Why did the client need to update their existing system?
Our client had a system that was originally built in the eighties, and had only undergone minor updates in the thirty years since its implementation. So it was based on very outdated technology. The user interface was no longer effective and there were numerous security risks. Furthermore, it was programmed in a language that few developers could work with. This was a particular frustration for the company since, due to the limited number of developers who knew the language, they were obligated to pay unreasonably high rates to maintain the system.

From a maintenance perspective, certain operations within the software had to be rewritten annually to stay current with ongoing industry changes. Financial aid rules change on regular basis, and the limits and values associated with student loans also fluctuate. The way the system was architected required the developer to rebuild sections of the application to accommodate these changes. Essentially, they would have to rewrite portions of the system for about three to four months every year just to keep up.

The client wanted an application that could be easily modified by an administrator on a regular basis to adjust to these industry changes.

What were the challenges in the context of a desktop-based system?
The company’s processes required that their application be installed on each user’s desktop in order to perform financial aid functions. Because security has become very restricted by IT departments, it was increasingly difficult for financial departments to get approval to install the application. This was a significant roadblock for them. In addition, the way the application functioned was by using system-generated batch files that users had to download and install themselves. This process was particularly slow, cumbersome, difficult to navigate, and ultimately prone to error. The client specifically wanted to overcome these setbacks with the new system.

Were there actual user perspective changes?
At a high level, the client basically wanted us to rewrite their application as a web-based .NET solution. The first step in doing this was to determine what functionality in the legacy system was being used and what was not. Over the thirty year lifetime of their system there were many aspects that would now be obsolete. We had to sit down with the users to walk through the existing functions and evaluate their purpose and importance. Once we understood what was necessary we had to design web-based screens, redesign the work flow, and build a system that was generally easier and more efficient for the users and the financial offices.

What were the core technologies used?
We used Microsoft .NET for the presentation layer, C# for the middle tier language, and Microsoft SQL server as the database.

When the company’s clients use their system interface to apply for financial aid, there are a lot of financial questions that open or close doors to more questions. For example, depending on how much money a client makes there might be several other questions that apply and need to be answered. The client wanted to be able to have their screens add and drop questions on the fly according to the answers being input. In a typical solution, the answers would be sent back to the server where the next step would be determined and relayed back to the user. This would require moving to a new page, or refreshing the current page. The client wanted to avoid that extra step so we programmed the ability to add and drop questions instantaneously on the current page as the answers were entered.

What contributed to the choice of a three-tier architecture?
When you’re building a web-based application the two main options are thee-tier or two-and-a-half-tier architecture. The approach we choose depends on the performance and security requirements. With either approach, the top and bottom tier are always the same. The top will be the web presentation layer which is the part that will appear in the user’s web browser and allow the user to input data. The bottom is always the database.

When the web layer receives data it will then go to either the second or third layer for validation or storage. With a three-tier system, the web layer passes information to the business layer, layer number two. Once there, the data is validated against the business rules and then passed down to the database.

In general, a three-tier solution is necessary for companies that need to handle thousands of users at any given time. It also has a higher level of security, being nearly impossible to crack. If you’re building an internal solution that will handle a finite number of users, a two-and-a-half-tier model will be just fine. However, if you need the increased security or need to handle large quantities of web traffic, the three-tiered approach is preferable.

Our client required a very high level of security, so we went with the three-tier model.

How long did the development process take?
We broke this project into two development phases. We began with analysis and functional design. When that was completed we started development on phase one. The piece that was built during phase one was an outward facing portion of the system which included the financial aid application interface. The company needed this up and running by a strict, short deadline, so we completed and implemented it with their legacy system. It was launched by their deadline and they were able to start using it immediately. Phase two is currently underway and is on time with the scheduled completion date.

How often did you communicate with the client?
During the analysis phase we communicated with the client on a daily basis. During the design phase it was also on a daily basis while we designed the new functionality. Once we began development we communicated a couple times per week about the status of the project and open issues that were being addressed.

In terms of the interaction between the client and vendor, this project was an example of how a successful project should be approached.

Are you doing maintenance on this system?
We are constantly monitoring the performance of the system and monitoring the database to ensure that everything is performing optimally on a daily basis. Our maintenance includes system support, so if there are any questions that arise, our developers who worked on the project will address them. Maintenance also includes bug fixes, so if the client has any problems within the application, we will fix them and release a new version with the corrections.