I’ve noticed a lack of long-term, strategic thinking in the business application development world. Many businesses build applications for current needs, but ignore the future.

It usually goes something like this: A manager says, “I need an application that does X, Y, and Z. When can we have it?” The developers rush through the project, deliver the application, and everyone’s happy.

Or, at least they’re happy for a year or so. Then the business changes, technology advances, and new trends roll around. Now, the application must also support A, B, and C. But it can’t. It wasn’t built for change. It wasn’t built for the future.

Now what happens? They need new apps. All of the previous work is now wasted because they didn’t build the initial app with the future in mind.

That leads to the obvious question: “How do you build applications for the future?” How do you build applications that adapt to change?

The answer: It starts with asking the right questions from the get-go. Ask strategic, long-term questions before you build your applications. To give you an idea of what to ask, I’ve come up with a short list of strategic questions to consider before building a business web application. While I’m sure there are others, these are all key questions which will help you build applications that last:

1. How will this integrate with other applications and services?

Unfortunately, integration is often ignored if it’s not an initial requirement for the project. After all, why design an application for integration with other services/apps if nobody asks for it?

Here’s why: A few years down the line, suppose the sales department implements a new CRM system, and wants it to integrate with the application. Or, suppose a new web service rolls out that would dramatically improve your application. That’s when you start wishing you designed the application for integration.

2. Will this support new platforms and devices?

In an increasingly mobile world, you must now build applications that work across all platforms and devices. As if that’s not difficult enough, you must also consider future devices and platforms as well. For instance, which mobile platform will be popular in three years? Who knows? But your applications must support them.

Why? If you ignore mobile devices, you risk delivering a product that users won’t use…and wasting a bunch of time and money in the process. Here’s a brief story which illustrates this point nicely:

“Prior to OnSIP, I worked on a website redesign project, and developing a mobile solution was not a part of the plan,” says Jason Salsiccia, Project Manager at OnSIP. “The reason for this was budget and time constraints. When launch time came, almost all of the feedback we got was that the site was unusable. It presented a truly awful user experience on smart phones and tablets, which now more than ever are the devices from which most people experience the Internet. The question I should have asked was, “What is our mobile strategy? Is what we’re building useful if people need a large monitor to use it?” We chose to ignore the necessity of mobile devices to satisfy our constraints, but in the end we realized we didn’t have anything viable. Fixing the mistake cost even more time and money than it would have if we had a mobile strategy planned from the beginning.”

3. Will this support multiple databases?

Here’s a common mistake made by many companies: They build applications that only work with their current database.

For instance, we see this quite a bit in the IBMi world. Companies turn to an IBMi-specific development tool, or use an IBMi-specific language for their applications. However, this only locks them to that platform. If they decide to support MySQL in the future, they need new applications.

4. How will this be maintained?

Sure, there’s always the temptation to cut corners during development just to speed up application delivery. Be careful…maintaining a poorly-designed application is both difficult and time-consuming.

“If a company invests their time and resources in building a database, they need to consider ease of future maintenance and development,” says Randall Agee, Founder and CEO of Allshore Global Resources. “If not, the database could become obsolete in a matter of years. This not only costs the company more in the long-run, it can disrupt business depending on how heavily they relied upon this program.”

5. Will this scale to a billion users?

I know…most applications will never have a billion users. Most will never have a million users. My point is this: What if you’re wildly successful? What if your company grows faster than anyone thought? Will your applications grow with you, or will you need new applications?

6. What if we move to the cloud?

Maybe your company hosts your own applications in-house. Maybe you think that will never change. Never say never. Who knows…in 3 years, maybe a new manager will come in and decide that everything must move to the cloud. When/if that happens, do you really want to re-create all of your applications?

Wrap up

If I could sum this whole article into one key point, it’s this: You don’t know what the future holds. Don’t build applications to simply meet current needs. Build applications that not only serve your present needs, but prepare you for future needs as well.