The age of the temporary application is here

Growing up as a US Army brat, I learned from very early age the meaning of the word "temporary," hopping between two-to-three year residences in Germany, France, Virginia, Maryland, New York, and Pennsylvania.  The Army even provided us "temporary quarters" to stay in until we moved into our more "permanent" quarters.

The notion of "temporary" has always had mixed connotations, but in business and IT, it's a fact of life. Just this past holiday season, retailers began experimenting with temporary stores south of Houston Street in New York. Most companies do not run versions of mission-critical applications that are more than three years old. Companies such as Kodak and American Apparel set up full-functioning outlets just for a few weeks or months, to test demand for certain products and perhaps launch a new notion of agility in a highly competitive and oversaturated retail market. An interesting redeployment of "bricks" in the era of clicks.

There it is; temporary has become quite chic. Temporary is like, so contemporary. Of course, this is just another case where information technology has been way ahead of the crowd.

In software, at the bits and bytes level, we're well acquainted with having temporary files, directories, caches, user IDs, licenses, and so forth. And, the notion of the "ad hoc" application has been around for some time, especially as it relates to networking and mobile computing. And, let's face, it, most companies do not run versions of mission-critical applications that are more than three years old.

But there's also a huge sea change taking place at the highest levels, and we're seeing it happen through a convergence of trends, including on-demand, software as a service, and of course, SOA. Standardization makes this possible — in interfaces, messaging, service delivery, and hardware components. It's all become hot-swappable. Even vendors have become hot-swappable (which they increasingly recognize).

This is happening across the entire business spectrum. Many of today's projects are managed and completed by ad-hoc teams that form to address a problem, then disband as team members move on to the next challenge. The same goes for the applications to support such efforts.

The other message I've been hearing is that for many enterprises, the technology that is in place now is enough to launch these new workloads. SOA can be initiated with many of the tools and technologies already in place in most enterprises. Composite applications can be built to access existing data sources. On-demand and SaaS applications, of course, can be accessed on a moment's notice.

Under this model, we can build and disassemble applications as business needs change. That could include services maintained within the enterprise and accessible via a common repository, as well as on-demand services available from an outside vendor or partner. Like the SoHo stores, applications may be deployed for a limited amount of time, as needed.

Gartner's Roy Schulte has pointed out that in the past, most applications were "built to last" — their longevity and robustness was the most prized features about the application. However, nowadays, the most important thing about an application is that it is "built to change."

Built to change, not to last: That thinking is emerging behind many enterprise architecture efforts as well. The goal of EA is not to expend time and energy building a system that will last through the ages, but build a supportive infrastructure that will easily accommodate change, and temporary or ad-hoc applications. Plus, more vendors wisely recognize that their relationships with customers are "temporary," and need to be maintained with TLC (and I don't mean temporary loving care).