Greenfield Technologies

Your Progress OpenEdge Database Expert

Buy or Build?

By Tom Bascom and Len Tichy

This article first appeared in the November 1994 issue of Mortgage Banking magazine. It's amazing how little has changed...

If you've been to a trade show or heard a sales presentation lately, then you know that every piece of software ever written is easy to use, flexible and will solve all of your business problems right out of the box. And if you read the computer media you know that there is a seemingly endless parade of tools which allow anyone to build a complete solution to any business problem, no matter how complex, in a single afternoon. So should you buy? or build?

Buying: The Quest for Software Flexibility

The whole point of a software package, after all, is to maximize utilization of a standardized solution at minimal cost. Yet who, in this complicated, ever-volatile industry can say they have not been frustrated by a production system that couldn't perform some task they needed it to do, the way they needed to do it? More importantly, it is the rare production manager who can say that their system can be modified substantially and rapidly enough to handle any change in business requirements in time to meet the market. Yet that is precisely the job a mission-critical loan production system needs to do.

Mortgage lenders for years have been routinely asking vendors if the software they are selling can be easily changed after it is installed, and once changed, easily maintained.

In Myths and Methods -- a Guide to Software Productivity author David T. Fisher makes a statement that should catch the interest of today's mortgage lender -- especially those who are anxious to squeeze more benefit from their loan production systems. Fisher writes, "a software package is only a prototype, even though the supplier might be reluctant to admit it." Not the most comforting words to hear when your plan is to implement a turnkey system.

It comes as no suprise to many end-users to hear that Fisher further supports his assertion by saying, "System designers usually lack the detailed knowledge necessary for understanding the subtle aspects of the users' environment enough to design the optimal system", and that "...user satisfaction, one of the most important factors in the success of a system, is highly dependent upon user involvement in the design." In other words, no matter how smart and industry-wise the system designer, without substantial end-user input, the resultant system is very likely to miss the mark. Non-technical end-users intuitively know that this is true as soon as they sit down to even the best software solutions. There are always useful functions that were left out by the designer, useless functions put in and flaws in concept or execution that the designer left in. In short, there is always room to make things work better.

What is striking about Fisher's opinion is that he expects software to never be more than a prototype. More to the the point, it is not possible for a packaged software product to be more than a prototype for a particular enterprise, especially when the target business application is complex, large scale, and mission-critical. Despite how satisfying it may be to blame designer ignorance for software dysfnction, it is nevertheless no panacea to introduce higher levels of end-user involvement into the system development process. On the contrary, involving users will definitely keep the system requirements a moving target.

Even when end-users do contribute their ideas to improve a system, too often the enhancement is obsolete by the time it is deployed, adding to the frustration of both the end-user and the system developer.

No one wants to hear that an expensive, comprehensively packaged software product is only a prototype to be continuously re-shaped by perpetually changing end-user perceptions and volatile market forces. A mortgage lender is seldom happy to bear the additional costs for modifications and attendant maintenance to accommodate such change. Neither is a software vendor anxious to devote resources to low profit, high risk custom work -- work that further complicates an already difficult maintenance task.

A growing number of origination firms are seeking more flexibility in the systems they intend to purchase. According to Jeff Lebowitz, co-author of MORTECH 94, a biennial study of the use of technology in mortgage banking published by SSP/RES Research, demand for flexibility in software systems is the newly emergent trend among mortgage banking firms. Lebowitz believes that the increasing demand for flexibility is due in large part to growing desire among mortgage lenders' to gain more leverage from their technology investment. Specifically, lenders want more day to day business functions handled by their loan production systems -- functions which frequently fall well outside the scope of the packaged software they originally purchased and implemented.

Lebowitz indicates that 3.8% of all origination firms have either built their own systems or have so heavily modified the original packaged software they purchased that it is no longer supportable by the vendor. Mortgage bankers, at a rate of 6.6%, are nearly twice as likely to follow this path, and of the top 100 originating firms, 12.4% either make, versus buy, their production system or are vendor-independent in their use of a customized packaged solution.

While it is not precisely indicated by the MORTECH 94 data, it seems reasonable to assume that these companies are motivated to expend such substantial development efforts in order to achieve a better "fit" between their production system and the work of the organization, as well as to enhance their capacity to respond quickly to changing market demands.

This is not an indictment of software companies and their products. Rather, it is simple recognition of the increasing demands of the business environment and the role of mission-critical software in the face of such challenges. The task will of course remain a moving target just beyond the reach of any packaged solution, no matter how well conceived or produced.

Build: The Quest for Control

There more than 90 loan origination software products available to today's mortgage banker. Why, you ask, would any mortgage origination enterprise trying to streamline its production infrastructure ever be tempted to build its own system from scratch? Yet, there are a significant number of larger firms who have either already "rolled their own" system or are seriously considering it among the options they are tempted to explore.

There are a number of reasons to build rather than buy that appear compelling to many IS (Information Systems) people.

It can be very frustrating and dangerous to be dependent upon software vendors when you need to react swiftly to a changing market. Unfortunately the traditional software vendors business model is to create a large base of customers who are producing of maintenance fees. Customers who are dependent upon the vendor's packaged solution, and available resources for customization. The customer is encouraged to conform their business practices to the vendor's package. Serious end-user modifications to the package are discouraged as it severely impacts the vendor's profitability -- an obsolete business model for a market seeking tools to create competitive advantage.

Virtually everbody is talking about pouring client-server concrete. Virtually nobody admits that the real 5 year cost per workstation (software, hardware, connectivity, and maintenance) is about $45,000. Precious few recognize the radical increase in the levels support needed at the farthest reaches of the WAN.

The technical issues are poorly understood. There is little practical industry experience managing large WAN environments with hundreds of users sharing an application as complex as mortgage origination.

What there is is a lot of media hype saying it should all work, presumably because the components are available. Hence, IS and senior operations managers expect it to be readily available in the market for immediate, risk-free implementation. It's not.

The Information Technology publications are also crackling with Tool Talk. It is difficult to find a periodical that doesn't relate persuasive stories of how IS departments everywhere are rapidly gearing up to employ the latest in Software Application Development Tools to replace their aging legacy systems. The task seems deceptively simple. What can be so complicated about building a system that captures one big file of seemingly static data and outputs a pile of forms and reports -- kind of like a glorified word processor joined at the hip with a database?

Mortgage origination is the most deceptively complicated, volatile, highly regulated, exception-prone business application known to the finance industry and likely the most difficult development task a mortgage banker's IS technical staff could choose to undertake.

Why then do so many attempt it? Barry Boehm says that it's because people are basically optimistic, they desire to please their superiors and they would like to avoid confrontations. Further, there is a pervasive perception that sizing a software project is impossible. Requirements are unknown and volatile, no reasonable metrics exist, nobody else is doing it, we've never done a project like this before and it's a lot of work and even if we did do it nobody would understand it. When projects are small and timetables are forgiving these attitudes are merely ignorant. Large projects are very, very different in character from small projects. It is not possible to simply add people to a software project in order to complete it sooner. Nor is it possible for every project to be completed on the industry standard deadline at year-end. Large projects must be carefully planned and managed in great detail or they will inevitably lead to disaster.

There is a minimum amount of time needed to complete any project and any effort to compress the schedule to close to that time, or worse, to less than that time will result in major cost and schedule over runs. The fastest way to make a late project later is to add more people to it. If you want to speed things up or spend less money then reduce the size of the project team. The industry is littered with proof of these statements and yet time and time again arbitrary and unrealistic schedules are first set and then accelerated to disaster.

Capers Jones identifies the following pitfalls an IS department faces when building a mortgage origination system:

Inadequate measurement

Tracking and cost-collection systems for software projects tend to leak and omit major portions of software expense. Unpaid overtime, managerial effort, administrative effort, user effort and many specialist groups such as quality assurance and technical writing are often omitted....the average leakage ranges from 35% to 50%.

Excessive schedule pressure

Irrational schedules and excessive schedule pressure have occurred on more than 65% of all large projects we've assessed to date. Excessive schedule pressure is a key contributor to poor quality, cancelled projects, low morale, fatigue, burnout, high attrition rates among software personnel.... For projects larger than 5000 function points [mortgage origination systems have in excess of 10,000 function points], the frequency [excessive scheduling pressure was observed] approaches 90%.... The number of bugs reported in the first year of projects with excessive schedule pressure can be up to four times higher than normal. This can raise the cost of defect repair to more than $200 per function point, as opposed to $50 per function point for more carefully developed software.... Unfortunately by the time excessive scheduling pressure becomes visible, it is usually too late to control it.

Creeping user requirements

The rate of growth of creeping user requirements is about 1% per month.... Creeping requirements are endemic to the software industry and seem to occur on more than 70% of all applications over 1000 function points. The severity of requirement creep is directly proportional to the size of the application. The average creep for a sample of 60 projects was 35%.... Assume that the average cost to build a project is $1000 per function point....

Cancelled projects

For projects larger than 10,000 function points, the probability for cancellation is greater than 65%.

Further, so-called evolutionary or maintenance costs of a system make up at least 70 percent of its total life cycle costs [Boehm, 'Improving software Productivity', IEEE Computer, Sept. 1987, p. 48.]. That means that more than two-thirds of the costs of a software system have to do with reworking the original concept. There could hardly be better proof that every new system is really only a prototype.

Buy and Build: The New Model

Reusability ...the ability to make subsequent use of standard parts and concepts. Reusability in software is only starting to be a serious research topic. The possibility of reusable artifacts for software include reusable architectures, reusable designs, reusable specifications, reusable code or modules, reusable test cases, reusable data, and reusable documentation. Some companies and projects are already developing new applications with more than 75% reusable components by volume.

-- Capers Jones
Assessment and Control of Software Risks - 1994

The "buy and build" decision is emerging as new paradigm for the implementer and manager of large scale systems. It is an approach which preserves options and provides an incremental pathway for ongoing business reegineering.

The enterprise buys a functionally rich, complete mortgage banking package and also gets with it a comprehensive library of software development tools from a vendor whose business philosophy and technical support team encourage the creation of new business functionality. The enterprise is free to re-shape the standard package without limitation.

While the vendors packaged solution may be a "prototype" in the eyes of some it represents years of effort that cannot be matched by any but a very small number of internal IS staffs.

As Fred Brooks wrote in 1982, about a much stabler computing environment, "In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but start again, smarting but smarter, and build a redesigned version in which these problems are solved....Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time."

In today's computing environment, where companies are striving to engage in some form of perpetual business re-engineering, the notion of purposely throwing away the first system sounds extravagent. And what of the second system? Brooks goes on to warn against second system syndrome wherein all of the neat ideas that couldn't fit into the first (unusable) system are tossed in to form a Baroque, everything including the kitchen sink, sort of software. Buying a proven solution leverages the vendors mistakes and shaves years off of development schedules.

Buy and Build means starting out with the hardest, most expensive, and riskiest part of the development cycle behind you. Instead of developing from scratch, the enterprise can advance its case further and in less time by focusing internal resources on:

• Planning for a well orchestrated conversion;
• Analyzing and streamlining business practices;
• Rapidly re-shaping the software to fit specific requirements;
• Training end-users and managers to fully utilize the system;
• Smaller scale, less risky projects with disproportionately large benefits (e.g., EDI interfaces or Imaging).

These are all areas where the internal staff enjoy expertise that cannot be readily duplicated by any outside vendor. Who knows better than the internal staff what your needs and abilities in these areas are?

With every passing day, the essential business challenge of mortgage bankers drifts closer to electronic information management. There are few companies in any industry that can afford the time, cost, and risks associated with planning and developing a mission-critical business software applcation from scratch. Buying and then building to suit is an excellent strategy which meets the needs of an increasing number of todays mortgage banker.