You’re at the Software Development Finish Line! Or are you?

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

There is so much focus and investment put into developing a new software application that many people fail to see that completing the development isn’t the end of the road; it’s really just the beginning.

For one thing, most people don’t realize that over the life cycle of a good software application, more development time is expended after the initial application is developed than within the initial development effort. While it’s a cliché, it is so true that “change is the only constant over the long run”. Therefore your application, no matter how well suited for your requirements now, will have to change over the years and evolve over time.

While ongoing life cycle software development can be the subject of future blog posts, my intention was to be more myopic today. I want to focus on what you’ll need to have in place when you are ready to launch as these requirements are often not well understood. This post will also not address any data conversion, integration issues, or related steps that may be required to implement your system. These are all valid issues but not today’s subject.

In the last 25 years, having resided in both the corporate world as CFO and a couple of times as the CIO and now on the other side of the table with organizations in the consulting world, I almost always see a gap in expectations. The root cause is that most people just don’t appreciate or take for granted what all goes into supporting an application. Even in the IT field, I’ve found that network people generally don’t fully appreciate what programmers have to do and vice-versa.

Let’s break it down. You’ll need to have services that we’ll organize into the following categories: hosting services, production support services, and software maintenance.

Let’s start with hosting services. Most people do understand that they’ll need a server to host their application and Internet connectivity. Given the complexity, required uptime, and interaction of application(s) they may also need application servers, database servers, various redundant servers, switches, firewalls, SANs and load balancers, just to name a few.

Typically a hosting agreement will include backups and a schedule for where the backups will be housed and how often various systems will be backed up. Hosting services should also cover monitoring the hardware involved as well as the application and the specific services running on the servers. Threshold levels have to be established in advance. Exceeding these thresholds will kick off various alerts. Obviously, backups and monitoring require specific software and hardware systems of their own. While many of the things in a hosting agreement should be and will be automated, don’t forget you’ll need someone for the automated services to notify when things go wrong and you’ll need someone to monitor and maintain these as systems evolve.

Although a typical hosting agreement covers some monitoring of your hardware, you’ll really need to have in place Production Support Services. Based on your business model and requirements you first have to decide what will be your solution for Tier 1 support. That’s the person(s) a user calls when he or she encounters a problem. You may want to set up an expert system or FAQs to automate and reduce the need for the initial customer contact. In the event a customer has a problem, many corporations prefer to handle customer calls with their own staff and then other corporations use a more technical vs. business resource as the initial customer point of contact.

As part of production support, you’ll need someone to receive the automated alerts generated by the monitoring systems, which were established by hosting services, and hopefully before your systems fail. When servers, network, or other hardware do have outages or failures you’ll need qualified network people to respond then as well. You need a developer and /or DBA resources to be able to respond to problems with applications and databases.

Under production support, you’ll need to monitor, respond to, investigate, diagnose hardware and software issues and then to repair, fix, or bypass whatever issue exists. One of the most significant decisions to make is the type of coverage you require and what kind of response time can you live with. For instance, do you really require coverage 24 x 7x 365? Do you need the same coverage at 3:00 AM as you do at 3:00 PM? During the night do you really need a programmer on call in addition to a network person? What groups will provide will provide Tier 1, Tier2, and Tier3 and how do you define the escalation to the next Tier?

Regarding software maintenance, I’ve already provided you with the fact that the majority of development time occurs after the application has been deployed. Even so, most people tend to think of a new application they won’t need anything changed for a year or two for some enhancement or new feature. They tend to forget that all software is delivered with bugs and there are incompatibilities due to the complexity of layers of devices and software included from a multitude of sources. The Internet is not a closed system. Expect to encounter anything and everything.

Aside from an event where Microsoft introduces a new O/S for your user base (in which case, all bets are off), my experience has been that right after launch is actually when you’ll see the biggest spike in maintenance requirements. Although you can and should test things extensively during development, until you get in the real world with a general release, you won’t uncover all the complexity of dealing with all your users’ systems, software, drivers, add-ins, and other applications. You’ll need to be able to resolve bugs both by making code changes and by developing workarounds. Most people don’t realize that you will probably invest much more time during the investigation and analysis of software bugs and incompatibilities than in actually resolving the bugs.

There are always things you’d like to have that weren’t slated for the current release. It’s worth noting that once you deploy a release, whether it’s alpha, beta, or production, you’ll start getting lots of feedback on functionality that will also be ammunition for your next release. Make sure you’re getting that both capture that feedback and have a process to integrate that into future development.

Finally, the purpose of this post wasn’t to scare you away from ever developing an application but to initiate a dialog or thought process. Every company with an application on the Internet has encountered these same issues and more than likely has successfully resolved these issues for their unique business.