Application Templates: Faster, Better, and Cheaper Systems

In response to increasingly heated global competition, organizations today are undergoing massive transformations in the way they are structured, managed, and operated. In focusing their attention on their customers, many organizations are redesigning business processes to deliver products and services more effectively. The effective use of information technology to support these processes has, for most, become critical.

Transformation, however, is not a one-time event. Organizations of today and tomorrow must be flexible and nimble enough to redefine themselves easily and often. Unfortunately, an inability to develop or change their information systems quickly is proving to be a serious bottleneck to widespread and ongoing change.

Until now, there have been two primary approaches to systems development — build or buy. Our research over the past two years suggests that a third alternative is emerging: the “template” approach. Combining most of the best aspects of the other two, the template approach can enable organizations to both develop and change systems faster. Templates are existing systems, built with the aid of computer-aided software engineering (CASE) tools, that are changed at the design level and thereby customized for a new organization’s use. CASE tools are computer-based tools that help developers build systems; essentially, they are CAD/CAM for systems developers.

In this paper, we discuss how three organizations used the template approach. All three significantly reduced both the time and cost of delivering their systems. In addition, the template approach has:

• Enabled Canadian Airlines to improve its ability to serve frequent flyers by utilizing several new business methods that it learned from the template it purchased.
• Provided John Wiley with the ability to leverage best practices, applications, knowledge, and expertise across its international divisions.
• Allowed Western Resources to dramatically improve existing relationships between the IS organization and the business, to quickly learn an important and necessary new technology, and to accomplish a merger more quickly and easily than previously possible.

Next we briefly discuss the build and buy alternatives and describe the template approach and the three companies utilizing it. We then summarize the pros and cons of this approach and outline the rapidly growing template marketplace.

The Traditional Alternatives: Build or Buy?

Until recently, organizations had to either build or buy new systems. In business terms, the traditional method of building and maintaining a custom system involves a series of fairly well-defined steps (see Figure 1). Given the need for a new system, developers define the functions the system will be required to perform, analyze detailed user requirements, design the system to satisfy these requirements, develop the system by writing the code, test the system, and, finally, implement it.1 This “build” cycle takes a series of business tasks defined in ordinary language and refines it in progressively greater levels of detail into a language the computer can understand, i.e., the code. Once the system is in use, changes in the business require changes, or maintenance, to the system.

Until the mid-1980s, when CASE tools were introduced, this entire process was completely manual. Programmers took the specifications from the design stage and wrote the program code line by line. Now, in a major variation on traditional custom development, a number of organizations are utilizing CASE tools to help automate the process. These tools assist developers in producing a computer-based design of the new system, expressed in diagrams and/or text. The design outlines the data relationships, the process flows, the screens, and the programs. The diagrammatic and textual representations are referred to as models. Many CASE tools also provide the ability to convert the design automatically into code. Minimal, if any, hand-coding is necessary, thus eliminating a major step (step 4 in Figure 1). Maintenance is also greatly simplified (step 7). Rather than changing the code to mirror a change in the business, the change can be made at the design (model) level and the code can be automatically regenerated.

Table 1 summarizes the advantages of CASE tools. However, while their use has steadily increased, it has not grown at the rate originally forecast. Some reasons for this slow growth rate include the cost of the CASE software and training, a significant learning curve, and the difficulties of making the necessary changes within the IS organization.2

A second major variation on the traditional custom development approach can be referred to as “rapid development.”3 With this approach, the proposed system is divided into segments and delivered incrementally. Time to delivery for each segment is short, typically three to six months. Each segment is a fully functioning system. Rather than moving sequentially through the steps of the development process (Figure 1), work is accomplished in an iterative fashion for each segment. With the first iteration, a prototype is built. With each successive iteration, changes are made to the prototype until it becomes the final system. IS and business users work closely together, using the prototype to help specify the detailed requirements for each segment, rather than documenting the detailed requirements for the entire system at the beginning of the project, thus eliminating or reducing a step in the development process (step 2 in Figure 1).

CASE or other tools are often used in combination with rapid development techniques. The primary advantages of rapid development are summarized in Table 1. Many organizations report, as a result of using rapid development, greater involvement in the process by business users, greater responsiveness to business needs, and quicker delivery of fully functional applications.

The benefits of building a custom system are fairly obvious: the resulting system should exactly match the specific requirements of the organization. But there are some major flaws. First, even with CASE and rapid development, time to delivery of the entire system is often too long to meet the business need, especially in today’s environment. Second, the cost of developing a system tailored to the particular organization and the way it operates can be extremely high. Third, the system is often based solely on the organization’s internal view of its business requirements, a limited perspective. Fourth, with the exception of those projects using rapid development techniques, involvement and input from the key players — those who will be using the system — are too often minimal. Finally, except for those systems built with CASE tools, altering the system, once in use, to reflect changes in the business is notoriously difficult, requiring developers to navigate through the code itself.

Thus more and more companies, increasingly frustrated with the custom development approach, are turning to the second “traditional” alternative and are buying software packages. It seems like a good idea. After all, why build when you can buy a fully working system at lower cost and change just those portions that do not exactly meet your needs? Purchasing a package provides an external perspective and new ideas about the business process, and should allow an organization to deliver a system faster and cheaper than building it (Table 1). However, this is often not the case. Most companies find that they need to modify the package — quite extensively — to fit their organization’s needs. Modifying a package generally means extensive changes or additions to the package code, a long, arduous task.4 Our research suggests that, by the time the package is actually installed and running, most corporations realize that it has been more difficult, more expensive, and more time consuming than anticipated. In fact, total installation costs ten times the original purchase cost are not unheard of.

A Third Alternative

A third major alternative that has emerged is the template approach, which combines favorable aspects of both “buy” and “build.” A company using a template approach takes a system that has been built with a CASE tool and customizes the system to meet its requirements by making changes at the design level. Depending on the particular CASE tool the company is using, the code can then be automatically generated from the changed design. What such a company is doing is using an existing system as a “template” for its new system.

What is a template? Any system built with a CASE tool has the potential to be a template. But what actually makes it a template is the way in which it is used. That is, a CASE-built system becomes a template when a new company or division customizes it at the design level to meet a new set of requirements. The key characteristics of a template are: (1) it is an existing system; (2) it has been built with a CASE tool; and (3) changes are made at the design level.

In contrast to the traditional “build” approach, regardless of whether CASE and/or rapid development are used, the template approach starts with a preexisting system or portion of a system. In this sense, it is similar to the “buy” approach; an organization that buys a package is also starting with a preexisting system, which it then typically modifies. However, modifying a traditional package involves understanding and changing the code itself, since most packages do not contain automated and easily displayed design models. In contrast, with the template approach, modifications can be made at the design level, and they are facilitated by the CASE tool. With a template, the design is customized, rather than the code.

To understand this in a more general context, consider the development of an automobile as an analogy. A manufacturer can design and build the automobile completely “from scratch” in software, this is analogous to building a custom system. A second option is to buy an automobile and physically alter it to the desired shape and form; this might include replacing certain parts, possibly adding some chrome, and/or restructuring the fenders to get a different curvature. This option is similar to buying a software package and changing it to meet the organization’s needs. A third option for the automobile manufacturer is to take a computer-based (CAD) representation of another car — one either made internally or by another manufacturer — that has some of the desired features, look, and feel. The manufacturer can then alter the representation, change the curvature, and electronically add some features. Then it pushes a button to automatically generate the code for the numerically controlled tools that build the new automobile. This third option is comparable to an application template.

The three company examples we outline next illustrate three different approaches to using templates. While each company’s story is unique, all use some form of template. All three cite significant cost and time savings, more effective partnership between IS and business users, more targeted systems that better address business needs, and more flexibility to allow change. In effect, these companies believe that templates combine many of the benefits of both the custom and package alternatives in a single solution.

Three Template Cases

In the course of studying the trend toward templates, we spoke with and visited companies that are using templates and vendors that sell them. The three companies we discuss provide a sample of template users. At each site, we conducted interviews with two to six members of the implementation team, representing senior IS executives and IS developers.

Canadian Airlines

Headquartered in Calgary, Canadian Airlines was formed in the mid-1980s by a merger of independent airlines. Slightly smaller than Air Canada, its major competitor, it is the world’s nineteenth largest airline, with approximately 16,000 employees and almost $3 billion in revenues. As part of its newly formed business and IT strategies, Canadian decided to reengineer its frequent flyer system, a highly visible and mission-critical system used to service the airline’s most valued customers. The original system had been designed to handle 100,000 customers but now needed to service more than one million customers. As such, transaction volumes had long exceeded the capabilities of the existing system, which was inflexible and required constant, extensive maintenance. The system could not keep up with the speed of change, because each new frequent flyer promotion required extensive code changes.

Canadian solicited bids for development of a new system and received twelve proposals that varied widely in both cost and time to complete. It decided to purchase TWA’s frequent flyer system, built using Texas Instruments’ CASE tool.5 The template consisted of a handful of floppy disks that contained a fully working system. There were no documents; the documentation was on the disks. Although the code came with the system, Canadian used it only to ensure that it had in fact received the entire system; after the initial “check” run, it never used the code again.

Canadian’s team of seven IS and three business people customized the system to its requirements. The changes it made to the system were fairly extensive; it added bilingual capabilities, changed the way upgrades were handled, and changed point and award accumulation. Canadian trained business users in key aspects of the CASE tool and methodology. The team made changes to the design models, and the code was regenerated by the tool. It was able to easily understand the business functionality of the system from the design models in the template and required minimal support from TWA.

The development team completed changes to the system within the ten months promised, despite a major business change in the seventh month that had required extensive modifications. At that point, senior management had made a business decision that meant the very structure of the system needed major changes. The frequent flyer program — and system — had always been separate from the lounge program and system (the lounge program allows members to use Canadian’s airport lounges). Customers had qualified for each program separately, carried separate cards, and changed privilege levels in each program, independent of the other. Canadian realized that, while this may have made sense from an operational standpoint, it was inconvenient and complicated for customers. Management decided to go to one card and, therefore, to one system. The implications were enormous: all the rules for qualifying, measuring, and changing privilege levels changed dramatically, and therefore the processes and data in the systems changed as well. According to Canadian, a conservative estimate for how long this change would have taken in a traditional system development project was six to nine months. The development team was able to do it in one month and deliver the new, enhanced system in the ten months it had promised for the frequent flyer system alone.

Benefits to Canadian.

Based on its original estimate that a custom solution would require approximately eighteen months, Canadian saved eight months with the template approach. At the same time, it believes that using the template approach offered additional, though less quantifiable, benefits.

The design models that came with the system contained both business and technical information. By buying another company’s approach to the business, Canadian found ways of operating a frequent flyer program it had not previously considered. While a package would have contained this information as well, it would have been buried in the system code. As a Canadian Airlines manager explained, in buying a package in the past, “You were always buying [this information], but I don’t think you were aware of it. You thought you were buying the code. [When you buy a CASE-based] design from another company, you’re very aware that what you’re buying is their business analysis.” In addition to the business information, Canadian acquired technical expertise as well. Through the template, it bought a system design that was easier to understand than if it were in a traditional package and that was better than any other it had considered. For example, in the TWA template system, the rules for frequent flyer promotions were separated from the body of the system. This streamlined design enabled business users to implement new frequent flyer promotions themselves, rather than requiring IS to make the changes for them. (According to Canadian, new promotions sometimes take place weekly.)

At the same time, Canadian could use the template as a working prototype. Instead of starting with the results of a requirements definition in three-ring binders, it began with a working system that business users could “see, touch, and feel.” Given a system that actually worked and needed only to be adjusted to Canadian’s requirements, business personnel could feel confident that the system would be delivered in the time frame promised. More important, because the system was built with a CASE tool and changes could be made at the design level rather than to the code, business users could make the necessary changes jointly with the IS team. As Canadian developers noted, this was not a case of “building a prototype first and then building the system. . . . [This was a case of ] developing the system using a prototyping iterative approach.” Because the burden of writing code was eliminated, the developers were not averse to continual iteration. And, because the users could see that changing the system was easier and faster than it had been in the past, they were more inclined to work with the developers.

The factors that facilitate customization of the system on initial implementation also facilitate ongoing customization over time — or maintenance. At Canadian, “maintenance” refers to both system support and enhancements, and includes: (1) correcting errors in the system; (2) changing the system in order to implement new frequent flyer promotions; and (3) changing the system to reflect regulatory changes. With the new system, support has been dramatically reduced and enhancements are significantly easier to implement, both because of a streamlined, more modular design and because the system resides in a CASE tool.6

John Wiley & Sons, Inc.

While Canadian purchased a template externally, the second company we studied developed its own template internally. John Wiley & Sons, Inc., is a midsized publisher of technical and scientific books headquartered in the northeast, with worldwide subsidiaries in the United Kingdom, Canada, Australia, and Singapore. Recognizing the leverage that they could gain from a global delivery mechanism, senior managers decided in 1988 to adopt a common hardware and software platform. They chose IBM’s AS400 for the hardware. To help them with systems development, they chose a CASE tool from Synon, Inc., a U.S.-based firm specializing in CASE tools for the AS400.

Realizing that their existing systems had become obsolete and could not adequately handle the increasing complexity of a multinational firm, senior managers decided to replace, in phases, the entire portfolio of existing systems. For the first phase, they chose to replace the systems that supported their core business process: order processing, distribution, warehousing, publishing support, and fulfillment activities.7 The first step was the development of a worldwide data model, designed to reflect the needs of multiple country constituencies. As Wiley managers explained, while there is some variation among countries, “a book is a book is a book.”

With the data model as the base, they developed the system first in Singapore, their smallest office. While the Singapore system was easier to change because it was smaller, it was also more functionally complex than some of the other sites (it had multicurrency, etc.). Seven developers completed the project, including learning the Synon CASE tool, in six months. The implementation team then took the Singapore system and transplanted it as a template first to Australia, and then to the United Kingdom. The team is currently implementing it in the United States, with Canada as the next step. The system has been tailored to each site. In customizing the on-line portion of the system, the developers applied all changes at the design level in the CASE tool, and regenerated the code through the tool. Depending on the type of change, business users see the results either immediately or the next day. When the team is finished in Canada, it plans to return and apply some of the further beneficial changes it has made in those countries where the system has already been installed.

In each implementation of the template, IS and business personnel work together to confirm the system’s scope and functionality and to identify any additional data or processes that might be needed.8 Development of the new system is then accomplished by changing and adding to the template. Small segments of the system are presented to the business units for verification as they are completed, with IS and business users together making changes.

The implementation of the core template in the United States provides some interesting insights. Both the business and technical (IS) communities in the United States initially resisted the concept. As a Wiley manager explained, the reaction from the business side was “[We] don’t want anything to do with it. . . . They’re much smaller than us. It’ll never handle our volume.” Eight representatives of the various user departments, from the manager level down, traveled to the United Kingdom to see the system. Their business peers, not IS people, demonstrated the system. After a weeklong review in which they could use the screens and see how easily modifications (which had previously required programmer code changes) could be made, they decided to go with the template. A Wiley manager commented, “The main thing with this system is that we’re trying to get IS out of it. It is a user system. They’re tailoring the screens for their own requirements. It’s their system.” One business manager who initially resisted the template system has become so convinced of its superiority that he is now marketing it to his business peers at another site.

Benefits to Wiley.

Wiley personnel believe that this approach to systems delivery provides significant leverage, allowing them to share — or “reuse” — best practices (both business and IS), applications, knowledge, and expertise. The major benefits are: First, Wiley managers have accomplished two goals simultaneously that had previously been in conflict — they can aggregate data at the firm level (from the common database) and tailor the business process and system to local needs. Second, smaller sites get greater functionality than they would be able to afford on their own. Third, they have reduced both time (of development and maintenance) and cost. Comparing the use of the template to custom development, Wiley managers estimate savings of approximately 30 percent, assuming moderate modification.9 They also estimate that purchase and customization of an external package would have cost significantly more than customization of their internal template solution. Moreover, they are able to avoid the difficulties of integrating an external package with their internal systems. And IS has found that “a template provides a useful, and relatively easy, way to learn a CASE tool.”

Wiley personnel also believe that their internal template approach has significantly improved the quantity and quality of IS-business interaction. The ability to interact and work with the proposed system allows a deeper level of understanding for business users than in the case of textual description. Delivering a constant stream of system segments reinforces confidence. The fact that IS and business users sit together in front of the screen to make changes and the fact that those changes happen with an immediacy previously unseen provides two important benefits: (1) it contributes to the improved level of trust and interaction, and (2) it enables the business to develop a sense of ownership, which is crucial to the success of implementation. And, while business users are learning more about what it takes to deliver a system, IS personnel are becoming more business literate as well. For IS people, the ability to better understand the business is a major benefit from the template approach. As one Wiley IS employee described it, “It’s the only way they’ll ever really get any faith in us — if we can prove to them that we understand what they are talking about.”

Finally, Wiley managers said that beginning with a defined scope was a major benefit. That is, using the template as the starting point essentially provides a clearly defined boundary for the system’s functionality. At the same time, however, they did not feel that this predefined boundary represented a constraint, because the system is relatively flexible and easy to change.

Western Resources

The product of a merger among several gas and electric utilities in the mid-1980s, Western Resources in Topeka, Kansas, is the fifth largest electric and gas utility in the United States, serving approximately 1.5 million customers. In 1986, the new chief information officer (CIO) decided that the company needed a new, flexible customer processing system to take it into the next decade. For a utility, the customer processing system is critical, encompassing billing, credit and collection, meter history, transformer history, and general customer service information. Indeed, the monthly billing envelope is considered the primary communication link between the company and its customers.

Western examined a range of potential solutions, including off-the-shelf package vendors, custom software vendors, and other utilities. It decided to purchase Andersen Consulting’s Customer/1 DesignWare product, the design for a customer processing system that Andersen had developed with another utility. Specifically, the product consisted of a design guide (provided in both paper documentation and electronically) that contained design models as well as some prototyped screens. In essence, what Western bought was a system design, the CASE tool with which it was built, and consultants who had industry expertise.

With help from Andersen, Western customized the design and completed the system. Many of the changes that Western made have become part of the Customer/1 DesignWare Andersen now sells. The system was completed in three years, with 104 team members. Top management played a significant, visible role in the implementation by participating in an upper management steering committee composed of the CIO, chief financial officer, and chief operating officer. The committee set a clear mandate from the beginning that there would be no modifications to the design without good reason.

Users were also involved throughout the system’s development. The original evaluation team consisted of five people from the business units and two people from IS, and the development team included twenty-one full-time business people. Business users learned the CASE tool and participated in portions of the development, such as redesigning the screens. After showing some initial prototypes, the development team presented key functional segments of the working system to the business units. During the presentations, IS and business people worked together on the screens, making changes when necessary.

The ability to quickly modify the system was tested four months after its implementation, when Western merged with another gas and electric utility. Some of the changes were major, reflecting different rate structures, payment plans, and billing practices. The utilities were able to merge in two-and-a-half months, including the system modification and data conversion.

Benefits to Western.

Western estimates that it saved approximately twelve to eighteen months and $20 million by using DesignWare rather than a custom solution. It has also achieved its target of paying for the system in less than three years through head count and other cost reductions.

However, while these time and cost savings are important, Western gained other, even more significant benefits. The system design provided both technical and business information. On the technical side, the Customer/1 DesignWare helped the IS people learn a new database technology (DB2) and the new CASE tool. One of the key developers at Western explained that the IS people knew nothing about DB2. If they had been designing from scratch, they would have based the new design on the old system and would not have effectively used the DB2 product; in effect, they probably would have “tried to DB2-ize the old system.” DesignWare gave them something to start with and learn from, and they could fill in any gaps by talking to the original designers. On the business side, Andersen’s knowledge of “best practice” in customer processing from other utilities was built into the design.

DesignWare contained new business process information ideas, rather than simply automating the current business process. At the same time, however, the design helped define the project’s scope and keep it within predefined boundaries. As the CIO explained: “If we started from scratch, we would have undoubtedly spent far more time on the design. The scope would have gotten out of control. If you don’t start out with a fence surrounding the project, it is everything in the world to everyone. Every single little requirement creeps in.”

Western also gained some leverage in certain technical aspects of the system. While the CASE tool did not automatically generate code from the design models, it did have precoded “program shells” for some of the technical functions common to all programs (e.g., validation edit routines). The shells provided two benefits. First, initial development was faster because some of the work had already been done and the programmers could focus on the business rather than technical functions. Second, the shells enforced a level of standardization that, in turn, made maintenance easier.10

Finally, Western realized some unexpected, but significant benefits from an increase in business involvement. As we have described, IS and business people worked together on system development, with business users designing new screens and modifying existing ones using the CASE tool. They also helped to design and implement the training and system tests. An important outcome of their greater involvement was that the users began to better understand the systems development process, while IS gained an appreciation of what goes on daily in the field. Moreover, both groups learned at the same time, focusing together on operational screens rather than on each other’s shortcomings, as too often occurs in traditional systems development efforts.

Differences and Similarities in the Three Cases

There are certain differences among the three company examples. Canadian and Western took systems developed by other companies and applied them within their own companies. Wiley applied an internally developed system to multiple locations within the company. The companies themselves are in different industries, and the systems vary in functionality, size, and complexity. Moreover, the systems were built with different kinds of CASE tools. Canadian’s template was built with an integrated, full life-cycle CASE tool, which provides automated support for all phases of the systems development life-cycle, from analysis through coding. Wiley’s template was built with a lower-CASE tool, which provides automated support of the design and coding phases. In both cases, the tool automatically generates code from design-level models. Western’s template, on the other hand, was built with an upper-CASE tool, which supports the analysis and design phases and therefore produces design-level models, but does not automatically generate code from those models.

At the same time, however, there are some basic, important similarities in what these companies are doing, in how they are doing it, and in the significant benefits they have received. All three companies noted that: (1) they were able to deliver their respective systems faster and cheaper than before; (2) the systems were more maintainable and therefore could better accommodate future change; and (3) the systems satisfied more of the business requirements.

In all three cases, an existing system is serving as a template for a new system, by reusing the design models. The companies are using the system design models to understand and learn what is in the existing system; the necessary changes are being made to the design models, rather than to the code itself, in all its overwhelming detail. The work is thus being done at a higher level of abstraction than is typical in a traditional systems development effort. In effect, what the companies are doing can be described as model-based development.11

The ways in which the companies used the templates are also similar. They combined the use of a template with the rapid development techniques we described earlier. Rather than starting the project with a detailed list, they began with a set of high-level functional requirements. The template, which satisfied the high-level requirements, provided the new system’s basic structure. IS and business personnel then jointly carved out the details, segment by segment, through an iterative process of working directly with the screens and changing the template’s design-level models. The template, in effect, served as a prototype.

The companies all noted certain characteristics of the template process. In all three, the template served as a learning vehicle for both IS and business personnel. For IS developers, the template provided a useful introduction to the new tools and systems approaches they needed: the CASE tool, some technologies (e.g., DB2), and a model technical design. On the business side, the template provided new ideas and business processes. However, templates do more than simply transfer knowledge; after all, external ideas, knowledge, and expertise can be transferred to an organization through traditional types of packages as well. More important, templates provide the capability for both IS and business users to interact jointly with the new system — to understand and make changes easily. It is this joint, hands-on interaction that primarily distinguishes templates from packages and facilitates learning.

In addition to learning more about their own functions, IS and business users learned about each other’s as well. Thus the template also served as a way to communicate. In effect, it provided a forum for the two groups in which they could understand each other’s jobs better and begin to build a partnership and a sense of mutual responsibility for the delivery of the system. Using the screens to visualize and articulate the requirements of the new system, rather than a blank sheet of paper, helped not only to improve the IS-business relationship, but also to improve the system.

In all three cases, users felt a sense of ownership, not simply involvement. Their ability to interact with, communicate through, and make changes directly to the system helped to foster this. (Table 2 summarizes the advantages of templates.) The template process we describe here, then, is a process characterized by improved learning, improved IS-business interaction, and user ownership. There are, however, some other beneficial elements of the process:

• By starting a project with only the basic requirements rather than with voluminous detail, the companies were more inclined to reuse a system or portion of a system that already existed, rather than automatically taking the “full custom development” route. Several interviewees noted that starting with a detailed list of requirements from everyone involved will almost always result in a custom-developed system or a heavily modified package, because no existing system can precisely match the several thousand requirements typically gathered with this approach.
• Omitting the detailed requirements phase through use of the template helped to contain the scope — and therefore time, cost, and expectations — of the project. One question is whether starting with a predefined scope might be a constraint, potentially limiting creative new ideas and solutions. The template users acknowledged this but believe it is more than offset by the creative thought, embedded in the template, that is available from outside the company.
• The incremental nature of the system delivery — whereby business personnel see results more quickly — also helped improve the credibility of IS and raise the level of trust.
• For a company pursuing an “internal” templates strategy, there are additional benefits — the ability to leverage best practices across the organization and to share applications, knowledge, and expertise.

Some of these benefits are possible with the purchase of an off-the-shelf software package. Others are possible with a custom solution, particularly one that uses CASE tools and rapid development techniques. The template solution we describe here, however, contains the most favorable aspects of both the buy and build alternatives and thus gives many of the benefits of both.

Issues and Implications

While the template approach clearly can offer some significant benefits, it is not a “silver bullet.” Potential drawbacks include:

• A limited supply of templates is available on the market today, although it appears to be growing rapidly. Of course, this issue applies only to those companies that are seeking to purchase templates; it does not prevent a company from pursuing an internal template delivery strategy.
• CASE tools have not been as widely embraced by the IS community as originally envisioned. A company that does not use them may be reluctant to consider templates; on the other hand, some companies have noted that the template facilitated learning a CASE tool and helped to effectively introduce the tool into the organization. Those companies that have chosen the CASE tool route and have already settled on a particular vendor’s tools face a different issue; currently, they are limited to templates built with that tool. However, this will become less of a problem as cross-CASE bridges are introduced to allow interaction between the different CASE tools.
• There is competition for the template approach, most notably, the object-oriented approach, which is a very different systems development paradigm than any used to date. However, while object orientation is very promising, it has not yet been developed so that it can be used easily by the vast majority of corporations for their standard business systems.12 Packages also are a viable alternative for some systems, particularly those that are table driven and require relatively few code-level modifications.

Using a template (and a CASE tool) effectively requires changes in skills, roles, responsibilities, and mind-sets, changes that must be managed.13 For a company pursuing an “internal” templates delivery strategy, the skills required to design a system that can be reused from one site to another must be learned. At Wiley, for example, the developers needed to design the initial worldwide data model to reflect the needs of many countries, which required problem-solving skills different from those they used in traditional system design. Using templates also requires a shift from the “not invented here” mindset that seems to be typical of some IS development groups. Some business users, too, tend to believe that their business process is unique and fundamentally different from others and that a previously developed system cannot be used without major modifications. In fact, there is more commonality than they typically understand or admit.

Finally, the type of change we describe requires management’s leadership and active involvement to be successful. For example, at Western, senior management specified there would be no changes in the template without good reason. At Wiley, the senior management team mandated using common hardware and software as a key component of the business strategy, thus driving the use of templates.

Future Directions

Dramatic change from the status quo in information systems is necessary. For years, organizations have been redeveloping similar functionality from business unit to business unit. The economics of this scenario — the huge expenses incurred — are no longer acceptable in many companies.

The template market, currently in its infancy, is growing. During the past year, supply has increased steadily as software package vendors, tool vendors, and custom software consultants have begun offering templates or have announced plans to do so.14 Players in this market include:

• CASE tool vendors. Some CASE tool vendors operate as brokers. For example, Texas Instruments offers templates that have been built either internally or by its customers, and KnowledgeWare is investigating similar possibilities for its CASE tool. Oracle Corporation, a $2 billion CASE tool, database, and consulting firm, is offering industry-specific predeveloped models, or templates, and consulting expertise. Synon recently entered the market with a set of financial templates.
• Software package vendors. Most of the current template activity in the software package market is among those vendors that offer packages for the mid-range market, specifically AS400 hardware and the Synon CASE tool. Cantoc, a Toronto firm, and American Software of Atlanta are two examples.
• Software consultants. One of the leading software consultants, Andersen Consulting, offers “DesignWare,” or templates for specific industries.
• Industry consortiums. Consortiums are emerging in certain industries (for example, airline, electric, and retail), in which templates may be built and exchanged among companies with similar needs and interests.

In addition, there is some direct interaction between companies, as between TWA and Canadian. New companies, like MetaSolv Software in Dallas, are also entering the market to sell templates for a variety of CASE tools, as well as other template services and cross-CASE tool bridges.

The current types of templates vary across a wide range of business applications as well as technology models. Business applications include, for example, financial services, manufacturing and distribution, hospital systems, utilities, and general financial applications such as general ledger, accounts receivable, accounts payable, and so on. Templates are also available specifically for technical functions, e.g., data access and screen and report templates.

Clearly, templates are a promising trend in the software industry. The essential concept behind them —working with design-level models that represent the system, rather than working with the system code itself —is one that makes intuitive sense and for which there is successful precedent in other industries. In the software industry, templates may be a first step toward a radically new IS process in which systems can be easily assembled from multiple, predefined components, replacing the notion of system “development” altogether. From what we have seen, the template alternative is clearly one that warrants attention today.