Custom-Development Shop or Software Product Company-What's the Difference, and Why Should You...

HEADNOTE

The type of company that a lender chooses to develop its software is as important as what it builds.

IMAGE ILLUSTRATION1

It wasn't that long ago when lenders thought about technology in terms of an investment

they may or may not choose to make. Lenders in today's competitive marketplace realize that having the right technology doesn't just make you more competitive; it allows you to stay in the game. But now lenders are faced with another technology-related decision-determining the way they should buy the systems they need to stay ahead in the business. * In the beginning, when real estate first migrated to computers, all lending technology was custom-written. No software existed to automate the many tasks lenders performed every day, and so every new platform was created from the ground up. Now, after literally thousands of implementations have occurred in the mortgage lending industry (both successful and unsuccessful), that's no longer the case. * Today, certain vendors are telling lenders that they have all the basics figured out when it comes to the technologies they need to operate most cost-effectively. Lending technology is now shrink-wrapped like any other software, and pre-configured loan origination systems (LOSes) and the vendors that sell them are promising lenders that they will save them months of implementation time and tens of thousands of dollars in setup costs.

Is this possible with the complexities of today's loans? Actually, yes. And no.

There are many factors to consider when choosing your next technology platform. Some aspects of your business might make it possible to get up to speed quickly with an off-the-shelf solution. However, lenders need to thoroughly understand the long-term implications and repercussions of their purchase before deciding they don't need the vendor's information technology (IT) support.

Knowing the difference

The lending business is very similar to a manufacturing assembly line. We gather data, evaluate them, determine the risk, price the product and then process and close it. Then we go back and do exactly the same thing again on the next deal.

The software business is not like this. Typically, writing software that works is an iterative process in which we define requirements, write the application, test it, keep what works, try to fix what is broken, determine how close we are to the end goal and then go back and do exactly the same thing again on the same product until we get it right. With the rapid rate of change always present in the mortgage lending business, some could argue that it is never perfect and we will always be back at the drawing board creating the next iteration to drive another incremental gain in efficiency.

Software vendors go at this problem in different ways, depending on how they are set up to operate. Software shops build software programs in the hope that they will meet a broad industry need and garner a large enough base of users to fund future enhancements. These players are looking for repeatable processes. They then try to create generic solutions for automating them, which can then be sold to multiple customers.

Custom-development shops start with basic components and then build a solution that meets the needs of an individual customer. It may take longer and cost more, but no other company in the space will have the same tools or, by extension, the same advantages-at least that's the argument. The best part of the custom shop is that the customer drives the future releases of the software-that's not always true for software application companies.

It's rather like choosing between buying your next car from a dealer's lot or from an engineering firm that can build exactly what you imagine your next car should be.

For many lenders, the choice comes down to one of these two types of shops. But according to Kamel Boulos, information technology director for Irvine, California-based Homefield Financial Inc., it starts with an investigation of the lender's own goals and strategies.

"It realty depends upon the organization's strategy," Boulos says. "Is the company seeking an application that can be implemented right out of the box, with minimal customization? Or do they plan to customize or configure an application to fit their own processes?"

Some institutions will want to shift most of the implementation work to the vendor, Boulos says, in which case it can make sense to go with an application that is already fully developed. But even if a lender chooses to customize, the implementation can still go quickly.

"Once you know your goals, the next step is to partner with a vendor who is able to run fast and get you what you need in a very timely manner," Boulos says. "There are vendors out there that have good processes in place and that can actually move quite quickly."

Finally, Boulos points out, using a vendor that has a thorough understanding of your business can be even more important than the way the software vendor provides your automation. "It's going to be much more difficult to work with a vendor that specializes in the automotive industry and has a piece of software that you like, but doesn't understand much about mortgage," he says.

Since vendors began offering boxed software to the mortgage space, lenders have been split over this issue. Can off-the-shelf technology still provide a competitive advantage? And if so, how much is it worth to have such an advantage? Can the firm afford the time it takes for custom development? Can the company afford not to invest in custom software?

These are tough questions, made tougher by an increasingly competitive marketplace with falling loan volumes and projections for weak future business opportunities. Lenders have to be more careful than ever before when it comes to deciding how to spend their technology budgets. According to Guilford, Connecticut-based MORTECH LLC's MORTECH 2006 study, even though "mortgage lenders are seeing thin margins ahead, they are nevertheless spending 8 percent more on technology than they did [in 2005]."

So, let's look at the pros and cons for both working with a software product company and working with a custom-development shop-from the lender's perspective.

The true product company

Modern lending software may not be something you can park in your driveway, but it's a product just like your car. You can expect most good software houses to follow the same proven strategies that other manufacturers follow when it comes to gauging market acceptance for new products and producing them in accordance with their customers' needs.

Like other manufacturers, software product companies will typically survey users to find out what they need in a new software product. This is also the case in the mortgage software industry. Because most lenders face the same challenges, most products designed by these firms have similar feature sets.

According to Needham, Massachusetts-based TowerGroup's report, Consumer Lending': Top 10 for 2007: Business Drivers, Strategic Responses and Technology Priorities, by Bobbie Britting, TowerGroup's senior analyst, Consumer Lending, and Craig Focardi, research area director, there are some clear technology priorities for lenders.

Technology priorities for U.S. consumer lenders include:

* core lending systems transformation;

* new analytics and tools to reach untapped markets;

* IT architecture transformation;

* automated workflow and business process management;

* enterprise content management;

* specialized compliance systems;

* data management;

* IT process improvements;

* risk and portfolio analytics; and

* customized and integrated channel portals.

Sharing the cost of development over a number of industry players reduces the cost of ownership. Typically, lenders need fewer internal resources to deploy these products. Vendors take supporting their software seriously in hopes that executives will pull their tools into new shops with them when they move from job to job.

Because product companies have dedicated teams of developers, programmers and quality-control (QC) personnel all dedicated to the same software product, their internal infrastructure for quality assurance (QA) and quality control tends to be higher than one of a custom-development shop. Good shops leverage this by mapping out vast QA/QC processes that every component and new revision undergoes before being deployed to the customer.

This job is simplified, because these companies typically work from a single code base. Every product they market is identical, and changes made to the software can be checked for quality once and trusted to run the same in every installation. This makes this software backward-compatible, minimizing the risk that a product bought today will be relegated to a back shelf in the unsupported division in the future.

Typically, product companies can provide more documentation relating to the software as it is today and the previous versions that were marketed. Fewer overall products on the menu make it easier to keep up with the documentation for those that are actively sold.

Finally, because the product company needs to attract as many customers as possible to survive, these firms generally provide a broader base solution with at least some functionality in most of the places that lenders would expect to find it. If the vendor is successful, it will mean that many lenders have purchased/endorsed the product, which means that buying it will keep a lender within the pack when it comes to following industry trends. In addition, the more lenders that are using the software, the more important it is that the vendor keeps the software fully compliant with all legislative and regulatory requirements, minimizing that risk for the lender as well.

The downsides to the product-company approach are predictable: Lenders may not have much say in how the original software was designed, what it was designed to do or how it will be changed in the future. In the worst cases, smaller lenders could find their technology evolving in a way that serves larger lenders better because those companies license more software (contributing more to the product company's bottom line) and are therefore more important to the lifeline of the company.

It is unlikely that the lender's priorities will be the same as the product company's priorities when it comes time to upgrade the software. When changes are made, every lender that owns a seat will have the new benefits, so there can be no specific benefits to the individual lender in terms of providing a competitive advantage.

Owning it all

Historically, the approach that has typically been favored by the nation's largest lenders has been to contract with a custom developer to write software for the installation. There are a number of advantages to this approach, including the obvious: You get exactly what you want, and pay for only what you plan to use.

Lenders that operate in small niches will find this a cost-saving measure. Firms that specialize in second liens may have little use for an online loan application or appraisals. Those lenders that seek a competitive advantage may not save money, but could gain a stronger position in the marketplace. Lenders can spend their technology budget where they feel they can get the largest return.

The custom development house gives the lender a great deal of control over the product's development, both in terms of what gets built in and when it gets deployed. This allows the lender to ensure that the company's existing processes are built in, instead of having to retrain company employees to work differently. This type of pre-configuration by design can save lenders months of training time and thousands of dollars.

Lenders that follow this path end up owning all of the intellectual property involved in their application, allowing the company to take the product to another custom developer or making further enhancements in-house, if necessary. At the same time, it adds value to the company, possibly making it a more attractive acquisition target.

According to an article in Technology & Business magazine, "Research firm Gärtner [Inc., Stamford, Connecticut] recently projected that maturing development tools and growing dissatisfaction with packaged solutions would see fully 20 percent of companies building their core application components by 2008."

In the end, custom development can be a faster and more cost-effective approach for some lenders, especially those that specialize in one part of the business. In addition, this may be the only approach possible for these firms that allows them to have any leverage over their software developer, as they would not be the power users of the shrink-wrapped software offered by the product company.

The pitfalls along the custom-development route are not as easy to spot as those along the off-the-shelf path, because sometimes what appears to be a benefit can turn out to be the opposite.

For instance, a lender working with a custom shop can determine exactly what it wants the software to do and exactly what it doesn't want to pay to develop. But what if the lender is wrong?

What if regulatory compliance forces the lender to add components that were not originally designed into the software? What if the company expands and the functionality required to move into the new market is not available in the current application? Charting a solo path involves the risk that the institution will move in a different direction than the industry as a whole.

When this happens, the advantage of paying only for what is initially desired turns into the disadvantage of having to pay more to integrate new functionality. When this happens, QA/QC becomes an issue, which is often exacerbated by the fact that in custom projects, the customer is often called on to do a fair amount of the testing. In the end, this can cost the lender much more in dollars and resources, plus take much longer to deploy.

Even if the lender is very careful in specifying the software during the initial design phase, the total cost of ownership for custom software will almost certainly be higher than the total cost for out-of-the-box tools. Without other users to share the ongoing costs of maintenance and ongoing support, a codependent relationship can develop where the lender is likely to become as dependent upon the software firm as the software firm is on the lender.

Even with the increased internal resources required to manage an ongoing custom software-development effort, lenders that choose this path run high risks of failing to adequately project future needs. This can develop into a co-dependent relationship of the worst kind, resulting in the software literally falling to execute as the lender outgrows it.

If the vendor is successful in growing the software with the lender, there will exist multiple versions of the application. Which of these does the lender own, if any? Where is that application's source code kept, and how is it safeguarded from loss, theft or sabotage?

Finally, the lender that chooses to form such strong ties with a custom developer must always worry that its partner might exit the business. If for any reason the vendor is not able to continue to work on the software, the lender will be forced to bring another vendor up-to-speed or take the maintenance inside. Neither option is attractive.

The resolution-Door No. 3

It is hoped that no lender is likely to be subjected to all of the disadvantages listed here for either approach. Neither can every lender hope to enjoy all of the advantages of either choice. It is clear there are significant risks involved regardless of which way a lender chooses to acquire the software necessary for the operation of its day-to-day business.

In the past, lenders were pretty much forced down one of these two paths. Today, there are a select number of softwaredevelopment firms that can offer the lender the best of both worlds. In fact, it is unwise for any lender to embark down one of these paths without considering how the alternate choice can be integrated for fulfilling the lender's solution requirements.

This hybrid approach can be employed in a number of ways, depending upon the specific needs of the lender. For a firm interested in a broad base of lending products and a number of origination channels, going with an off-the-shelf system to meet 70 percent of its needs and hiring a custom shop to tailor the remaining functionality can make good sense. Likewise, a niche-based lender can hire a firm to develop its software, but instruct the vendor to use certain open-source or pre-built components in the development.

Irvine, California-based Financial Freedom Senior Funding Corporation, the nation's largest reverse-mortgage specialist, needed mortgage banking technology specific to its niche market. Because of the nature of reverse mortgages and the reverse-mortgage product's relative newness to the marketplace, no existing system could sufficiently handle the sophisticated loan-entry and calculation requirements required for a reverse mortgage. Due to these factors, Financial Freedom refocused its LOS search to target a system that would provide it with 70 percent of the functionality it needed out-of-the-box and offer an architecture that would support customization to include the reverse-mortgage functionality it needed to meet its lending requirements.

In the past, this kind of software development was not practical because integrating the various components could cost as much as the custom code. With today's industry standards and continued software implementation frameworks, such as service-oriented architectures (SOAs), we have much more flexible frameworks in which to work. Lenders intent on getting the most out of technology budgets will investigate them and develop their future platforms accordingly.

In the end, according to Robert Phelps, executive vice president, application development, for Countrywide Financial Corporation, Calabasas, California, there are more important considerations than how the vendor designs the software you ultimately use in your mortgage business. He provides three key considerations.

"First, is experience. This is huge," Phelps says. "secondly, the product itself must fit very well into the lender's environment. Finally, we look at what it's going to take to implement the software in our environment. Any shop will look for alt three of these."

In addition, Phelps says, the lender will look at the future prospects of any vendor partner selected in an attempt to determine whether the company will have the resources to support the software going forward. This could have an impact on the type of software shop the lender chooses. While the number of seats sold may have limited impact on a company that sells shrink-wrapped software, taking on a new client could be a serious drain on the resources of a custom-development house.

SIDEBAR

Modern lending software may not be something you can park in your driveway, but it's a product just like your car.

SIDEBAR

The pitfalls along the custom-development route are not as easy to spot as those along the off-the-shelf path.

AUTHOR_AFFILIATION

Michael Detwiler is chief executive officer of Mortgage Cadence, Greenwood Village, Colorado (www.mortgagecadence.com), a firm providing enterprise lending solutions and other technology platforms for a range of industries. He can be reached at mdetwilerd@mortgagecadence.com.