This article is Part 6 in our Information Systems series.

Part 1: 6 Questions Executive Teams Should Be Asking About Their Information Systems

Part 2: Time To Reengineer IT – Again

Part 3: How Things Should Work

Part 4: New Approaches, New Attitudes

Part 5: Core And Edge

Part 6: The Third Way (current)

Part 7: Grapevine

Part 8: Better Methods At Work

Part 9: Toward A New Normal

The Third Way

There have long been two basic approaches to putting business systems in place. Building custom applications from scratch was the norm until the rise of software packages and ERP systems with extensive functionality. Then most companies adopted a “buy, don’t build” policy, with a strong preference to avoid customizing the software package. That preference notwithstanding, companies found that they had to modify the packages to fit local processes, and supplement them to provide differentiating functionality or simply a friendly interface. They then found themselves in a no-man’s land – locked in to the vendor, its technology, and its software upgrades; and forced to do an ever-larger amount of custom redevelopment with each upgrade. It became a toss-up: Which is worse, dealing with vendor releases or continuing to maintain those ancient in-house systems and their COBOL code?

There is a third way. Build upon a common technological foundation including interface protocols and other standards. Treat everything – including existing applications – as modular components that should be exposed to the platform at large and reused wherever valuable. Use agile development methods to build and modify components. Automate applications configuration and interfaces to minimize the disruption of business and technology changes. You’ll regularly start with packaged software, but keeping up with the vendor is simplified, and you have the option of simply making the software your own.

The third way entails a different applications development process. The first two steps of specification and programming combine. Instead of having a middleman called “business analyst” extract specifications, have business-conversant developers sit down with business people and prototype and exercise new business capabilities. Why talk about business processes and applications when you can work directly with them? We call the people “strike teams” and the process “side-by-side development.”

The last major step of applications development is deployment, including testing, installation and roll-out to user groups. With large legacy systems, production testing and installation of changes can each entail taking down the application, and user testing can send you back to the drawing board. However, with today’s technology, it’s relatively easy and inexpensive to create realistic test environments, and it’s possible to automate deployment to each of several environments: development, testing, user testing, production. User testing is an extension of the strike team’s work. And as long as modifications are kept small and self-contained, and releases are frequent, the costs of introducing an error and making a fix are very low.

The result is unprecedented speed and quality. The specification step is accelerated by eliminating the middleman. Development is accelerated by agile methods drawing upon a platform of components. Deployment is accelerated through automation of testing and regularity of releases. And quality rises with a better brand of business involvement and more realistic testing.

This third way combines the implementation speed of software packages with the fit of custom development, adding inherent flexibility that is native to neither. Small teams accomplish more with less. The enterprise can think bigger and act faster.

Up Next: Grapevine