Arnold Kling

"Arguing in My Spare Time" No. 1

In the financial trade press, most notably American Banker, the role of computer technology in banking is a frequent topic of discussion. One issue that is posed is the competitive threat to banks posed by software companies (with one company in particular cited as the chief menace). The issue is presented as:

Are software companies trying to act too much like banks?

If this were the critical question, there would be little reason for banks to feel threatened. Despite the parallels that exist between moving data and moving money, the banking industry has deep cultural roots that are not going to disappear quickly. Just as an example of how important it is not to overlook cultural lag, I have read that only 30 percent of people with bank accounts have used an ATM machine.

There is a threat to banks, but it is not the one typically posed in the financial trade press. In fact, it can best be expressed by posing the question in reverse:

Are banks trying to act too much like software companies?

The answer to this question is "yes," and the problem this represents for banks is significant. The large MIS departments and proprietary software systems of banks are a real threat to their survival. The faster a bank can get out of the software business, the better are its chances of success.

SOME DEFINITIONS

Making an arrogant, sweeping pronouncement is fun, but we are getting ahead of ourselves. We need to back up and undertake the more mundane task of defining terms more carefully.

We want to talk about a shift in software development activity from one sector of the economy to another. We wish to define the "Dilbert sector" to be those organizations whose primary business is not software development. It includes government, banks, retailers, manufacturers, and so on.

The professional software sector is to be defined as those organizations whose primary business is software development. What these organizations sell (or give away) is software. Moreover, this software can be sold to many companies, as opposed to custom software developed for a single buyer.

To make this contrast meaningful, we will need a definition of software development. In particular, we need a clear boundary between using software and developing software. Here is one proposal:

Someone is applying software when they are not writing "if..then..else" statements.

Someone is developing software when they are writing "if..then..else" statements.

By these definitions, someone who is doing word processing is using software. Someone who writes a program in C or Java probably is going to meet the definition of developing software. By these definitions, over 99 percent of spreadsheets reflect someone using software. However, spreadsheets do come with "if then else" tools, and when these are utilized, the spreadsheet crosses over the line as we have drawn it to constitute software development.

The spreadsheet example suggests that we do not need to hold to an "either/or" view. In fact, we can think of a continuum. Imagine all of the "if..then..else" statements that have to be executed in order for software to work. The percentage of these if-then-else statements that have to be written by me is an indicator of the extent to which I am a software developer. In the case of word processing, this percentage is 0. In the case of spreadsheets, it often is 0 and even when it is not 0 it still is quite low (the underlying spreadsheet software must execute many "if..then..else" statements even if none are included explicitly in my spreadsheet).

There are software metrics that are more sophisticated than the number of "if..then.. else" statements. There is an entire discipline of software metrics, of which I am only dimly aware. One of the terms in this discipline is "function points," which I am told is a very reliable measure of the difficulty of software development. However, for the purpose of these essays, thinking about the proportion of "if..then..else" statements will suffice.

Using the "if..then..else" metric of software development, we can define proprietary software applications as applications where a large share of the "if..then..else" statements that are executed are statements that were written for that application. In contrast, when you have an application that was assembled by configuring software written by someone else, this will be called applying software.

Today, for example, it is possible to set up an entire order-entry system on the Internet with a back-end database, without writing a single "if..then..else" statement. Whether you are marketing stuffed animals or home equity loans, you can create order forms and link these to the necessary databases without doing any programming.

Assembling an application is defined as putting together a system to perform a business task. Building an order-entry system is an example of assembling an application. Assembling an application may or may not require the writing of new "if..then..else" statements. Therefore, it may or may not require software development, given our definition of the latter.

BACK TO THE ESSAY

With our terms better defined, we can distinguish three ways to assemble software applications:

1. Develop software in house

2. Out-source software development.

3. Apply generic software

When I am talking about the Dilbert sector getting out of the software development business, I do not mean out-sourcing of proprietary software development. Out-sourcing is only a slightly different way of developing old-fashioned proprietary applications. Many of the "if..then..else" statements still are written specifically for the application. The fact that the programmers of this proprietary "if..then..else" logic work for another firm does not make a dramatic difference in the cost of development or the difficulty of maintenance.

The really powerful option is the third approach of applying generic software. When firms switch from developing proprietary software to applying generic software, the potential gains in productivity are much more dramatic. Once the tools have been installed successfully and business people have been trained to use them, the firm can take hard-core programmers out of the critical path of developing and enhancing applications. One does not need to be a programmer to use a word processor, create a spreadsheet, or compose Web pages. Moreover, since most of the tedious testing and de-bugging of computer programs is necessitated by the "if..then..else" logic, the ability to develop applications without having to write this logic makes for far fewer mistakes and far less work.

Of course, applying generic software only works if it solves your business problem. It is common for generic software to fall short of meeting the specific needs of a company. Therefore, the company must write some of its own "if..then..else" logic. What is interesting about today's environment is that the Internet is producing quantum leaps in the capabilities of generic software, and this is creating the potential for a much more rapid evolution away from proprietary software and toward business solutions that are based on the application of generic software.

With the capabilities of generic software increasing rapidly, it is possible to imagine a bank without the large MIS department that until very recently has been a necessity. A bank that offers traditional services powered by computer applications based on generic software would be a formidable competitor. The banks that continue to think that they should invest in developing major proprietary software systems would be well advised to stay out of Microsoft's business.