When computer applications were introduced to the world of business, they were designed and run by technicians and programmers. If you wanted data processed, you just handed it over and someone returned the results to you. As the computer revolution evolved, computers became just one more appliance that a company purchased to improve productivity, and that brought a whole new range of headaches. The computers themselves could do nothing without applications software. As a result, companies had just two choices:

They could buy off-the-shelf applications and adapt their business processes to fit the software.

They could write their own applications to fit their idiosyncratic processes.

The off-the shelf applications rarely, if ever, gave a customer what was really needed. But custom-designed applications often required endless rounds of revisions and upgrades. That in turn led to costly technical fixes that were often more expensive by far than the original computer. In either case, the systems, as often as not, failed to deliver the expected business results.

Business process reengineering emerged in the early ‘90s as a way to close the loop between the end-users of the business processes and the developers of the application that enabled the processes. The idea was to find ways that technology could optimize processes and then assure that systems were built in such a way that the optimized process would work as envisioned.

Companies like SAP and Oracle introduced a new genre of applications, referred to as Enterprise Resource Planning applications, or ERP. Because of these applications’ flexibility, and the inclusion of sophisticated “best of breed” algorithms, they definitely improved the situation. However, at the same time, the pace of change and the need to compete on the basis of differentiated processes increased, leaving the application developers still unable to meet the needs of the users.

Today, every corporate IT department is familiar with this conundrum. In fact, a study by the Standish Group, a consulting firm, showed that as of 2002, 15 percent of software installations failed outright, and fully half of them suffered from cost overruns or proved not to have the functionality promised by the vendors.

Put simply, applications software has traditionally been very expensive, and a lot of it simply doesn’t work. Nevertheless, North American firms are spending $100 billion a year on it, according to Forrester Research.¹

The FBI, for example, had software designed to create a Virtual Case File so that agents could review cases on desktop computers. But the agency had to scrap the $170 million project due to design flaws. This common predicament results from a host of communication problems that crop up in the process of trying to describe what the software should do, without actually being able to see it.

Everything from divergent jargon among participants, to simple human miscommunication, contributes to this confusion. That results in endless coding and recoding of software just to get to a prototype. And the customer pays every step of the way. In the end, the result is an application that is permanently crippled — a not-quite-good-enough solution that leaves everyone unhappy.

This process of selling — or buying — and then trying to fix inadequate or inappropriate software is painful for everyone involved. Two of the custom software programmers who experienced this were Emmett Keeffe III and Maurice Martin, who developed custom software for some 300 firms in the Los Angeles area over a five-year period. The revisions and cost overruns made their jobs a living hell. By 2001, according to a report in BusinessWeek Online,² they had come to believe that there had to be a better way.

They concluded that the better way was to use simulation. After all, doesn’t Boeing design aircraft on a computer before flying the real thing? And don’t carmakers use computer-aided design software to create cars before they actually begin shaping metal and plastic? Chipmakers wouldn’t dream of building a computer chip without simulating it in software first. So, why not simulate all the features and functionality of a software installation before ever writing a line of code? Let the customer try it out and tweak everything up front.

Keeffe and Martin used this observation to formulate the business plan for a new company called iRise. It also seemed like a great idea to plenty of companies, which quickly became iRise clients. Among the early adopters was Sprint, and that contract put iRise in the black in its first year. With a basic installation fee of $250,000, iRise was snapped up by Boeing, Weyerhaeuser, and Bank of America. Just as no one would consider buying a car without test-driving it, more and more businesses are seeing the logic of test-driving software before spending billions to have it designed. And redesigned.

The reasons are obvious. Cost overruns on software typically amount to a third of the project’s original cost estimate. These overruns can be cut in half with the use of iRise and the tools built by the crowd of imitators that has moved into this new market. The result has been the rise of a whole new industry, sometimes known as “requirements-management software.” According to a recent estimate by Gartner,this new field is rapidly growing from $150 million in 2003 revenues to a forecasted $400 million in 2008.³

Decipher, an independent research organization, surveyed 200 IT executives in 2005 and found that the vast majority of them actually plan to fail when installing new software. They even allow for plenty of waste in their original budgets — including as much as a quarter of the total amount for rework.⁴ This represents billions of dollars, and it frequently causes a huge drop in productivity and a delay in getting new products to market.

Forrester Research estimates that U.S. firms spent $103 billion in 2004 on custom software, and three-fourths of the companies that bought it spent an additional quarter of their original budgets fixing problems after the fact. Think of it this way: Imagine that you bought a new car for $40,000 and had to spend $10,000 fixing it in the first year. That, in essence, was the situation in business software before iRise and related companies came along.

Until now, most custom software projects started with documents describing what it was supposed to do. The IT department produced static screen shots, and also offered diagrams to show what the software claimed it would ultimately do.

Once the end-users and their managers signed off on these static descriptions, the developers went away and came back later with the so-called “finished product.” Then, everything that needed to be fixed was billed on a time and materials basis. In essence, users wrote the developers a blank check. Unfortunately, reworking code adds nothing to the bottom line.

Worse yet, the problem has become more acute as more software development moves offshore. There the customer can’t look over the vendor’s shoulder as easily. A stunning 84 percent of clients surveyed were dissatisfied with the results of these global development strategies. Not surprisingly, that same 84 percent expressed interest in simulator technology for testing software before committing to having it built.⁵

How do iRise and its competitors work? If you’re opening a Web site like Lands’ End, for example, where you’ll take orders, process payments, send confirmations to customers, and ship goods, you can actually shop on the site as if it were already live and using iRise.

Company executives and developers can go onto the site before it’s designed and pick out products to buy, submit orders, and receive their confirmation codes. They can then track those orders as they are processed and shipped, and receive a simulated delivery of the product itself.

During that process, everyone involved can propose changes to the software that can be designed in from the start, before any billable hours are logged on the project. New features can be quickly mocked up and tested.

Moreover, the way iRise tools are designed, any non-technical businessperson can do the mock-up without assistance. An entire simulated site can be built in a day.

For example, before Sprint started to use iRise, it would send IBM and EDS hundreds of pages of requirements and specifications for the software those vendors were designing. Naturally, errors would creep in and miscommunications would lead to a vast array of glitches in the final product.

Because of the enormous potential for cutting costs and accelerating business process improvement, these tools have begun to attract a lot of attention. Competitors large and small are recognizing the magnitude of the opportunity. When only a third of all information technology projects are delivered on time and within budget, there is obviously a huge need that is not being met. Business abhors a vacuum, and many will rush in to fill it.

The nearest competitor to iRise at the moment seems to be Sofea, a Toronto-based company that has been named a 2005 “Cool Vendor” by Gartner. Gartner uses the designation to highlight new and innovative vendors, products, and services.

Sofea’s Profesy Suite allows the customer to collaborate on developing, verifying, simulating, validating, and testing all software requirements before any code is actually written. In one instance, a Fortune 500 corporation implementing Profesy achieved a 285 percent return on investment, recovering its initial costs in just six months. Sofea’s products work seamlessly with the leading offerings in the industry, including those from IBM and Borland.

Among the other entrants in the field are Telelogic, Serena, Apptero, and IBM. Each has a slightly different approach to what’s being called “visualization prototyping.”

For example, while iRise concentrates on simulation, Sofea emphasizes the discovery of requirements. Its software automatically captures new features and requirements that the customer specifies during the prototyping sessions. Then it translates them into flowcharts or other language that software designers understand to eliminate miscommunications.

This movement toward customer-driven software development and simulation began in early 2001, when a group of business software developers met to define some of the bigger problems in the field. They created what they call the Agile Software Development Group, and published their Agile Manifesto, which includes four values:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

In practical terms, that means the focus is on building each application one component at a time so that you always know what you’ve developed, and frequently sharing the results with business users. This is ushering in a new era of transparency and the end of mysterious black boxes in the software development industry.

In light of this trend, we offer the following four forecasts:

First, every significant player in the software development industry will become converts to this concept in the very near future. Ideas like this, which everyone seems to agree was obvious from the start, are extremely contagious. The black-box development of software and the practice of charging customers twice for the same end product are about to come to a screeching halt.

Second, software simulation will become a hugely profitable field. Expect a proliferation of entrants, all offering essentially the same concept outfitted with different bells and whistles. Sorting the wheat from the chaff will be a challenge, but those who manage to do so will win big. Expect to see iRise, among others, going public soon.

Third, watch out for IBM and Microsoft. This is a natural area for IBM, which has great strength in both services and products. Expect its simulation tools to provide stiff competition for first-movers like iRise and Sofea. Similarly, expect Microsoft to build or acquire a simulation application to complement its existing development tools.

Fourth, by 2020, this movement will lead to an era in which the end-user teams routinely define and develop their own software applications, with some guidance and support from technical experts. A tool set and methodology will be developed that simply takes the simulation the users have developed and refined for themselves and then translates it into a working application. This will lead to the end of many systems development jobs as we know them today. These positions will be replaced by “business analysts” and “requirements facilitators,” who help users imagine new possibilities rather than building and testing software.