Summary
With powerful personal computers and local area networks easily affordable even to the smallest businesses, many software companies are making big bets on providing small business software. But any soul braving that market would do well to carefully think through their business model: they might find something completely unexpected.

As the large enterprise market for software matures, software firms must look elsewhere to sustain their growth. One of those areas is small-business software: Software for accountants, lawyers, doctors' offices, auto dealers, contractors, etc. That software includes both vertical-market software components, as well as the infrastructure part of supporting vertical market software (databases, operating systems, servers, etc).

All the major software firms have announced plans to significantly invest in that market segment. Microsoft, for instance, plans to spend on the order of $10 billion in the next few years on marketing and product development aimed at the small business market.

Indeed, most businesses are small businesses. A large part of the US economy consists of businesses employing a 100 people or less. These businesses provide many billions of dollars of output, and collectively employ far more people than the top 1000 largest firms in the US. It follows that making these business' lives easier with software products could prove a significant business opportunity.

But wait a minute before you rush out, quit your job, and start a company building small business software. Serving that market segment may turn out to be the ultimate trail of trials for a firm that embarks on that journey.

The reasons for that premonition are simple: First, small business software is mission-critical software. When you sit in a dentist's chair, and your dentist wants to pull up your records on his computer system before he pulls your tooth, that dentist simply can't afford for that system to fail at that moment. Or, if you're an auto dealer and a customer is ready to purchase a vehicle, you simply can't afford for that computer to fail at the crucial moment when you need to calculate the customer's loan payments.

At the same time, small business software must also be inexpensive, since small firms don't have the IT budgets of larger enterprises. (Many small firms don't have IT budgets at all.) If you charge above a few thousand dollars per customer, at least in the US, you simply won't reach a large part of your small business market.

Not only must small business software be inexpensive to buy, it must also be inexpensive to maintain. Since small firms don't have an IT department, they don't understand the continued investment required to maintain a typical enterprise software system. While maintanence of a typical enterprise software, such as an ERP system, costs far more than the initial purchase price, a small business is not prepared to accept a similar reality.

So what appears to be at first an attractive business opportunity, might just be the ultimate contortionist's excercises for software firms: Sell software suitable for the space shuttle in terms of reliablity, but at a millionth of the cost.

As if that were not a challenge enough, consider that the software environment on the space shuttle is controlled by the system provider: Astronauts are not, at least to my knowledge, allowed to install OS upgrades, download all the spam that fits in email, or browse pornographic Web sites with a dozen spywares and pop-up ads.

A small business' computing environment couldn't be more different: All users typically run with full administrative privileges (since most people just start using new PCs with the default settings), and are allowed unrestricted access to the computer and the Internet. That results in a dangerous elixir - the personal computer equivalent of Anthrax. Since there is no system administrator ever to manage those PCs, the computer environment at small firms tends to decay over time, until it reaches crisis proportions.

And when crisis hits, the software firm supplying the mission critical business software will likely take those blows. As the dentist is ready to start a procedure and needs to view an X-ray image, or the auto dealer is ready to close a sale and needs access to an inventory system, if the system fails at those crucial moments, they will then reach for the phone and utter the dreadful words that sends shrivels down the spines of anyone listening at the receiving end of the line: The system is not working.

At that point, both the customer and the software vendor are in a crisis mode, since the customer is stopped from performing a mission-critical action. As with a person who never bothered to go in for a checkup for decades, and then suffers from a massive heart attack, doctor and patient are in for a life-and-death struggle to save the patient. The medical analogy stops there, though: In the medical field, insurance companies (or the government) pick up the tab. In the software world, both the customer and the vendor end up as loosers.

I've have been building software for small businesses for the past 2 years, and, to be honest, have not yet been able to find a solution to that quandary. I hear and read the optimistic predictions about small business software, but then see the daily reality of managing crises and putting out fires that burn at the edge of the network, in the offices of small firms.

And here is the rub: Many small business owners are not able to distinguish between hardware and software, let alone types of software. They only know "the system." The system includes the total environment to perform the mission-critical business functions: The hardware, the OS, the vertical market app, the network, and everything in between. If any of these components fail, then the "system is down."

Actually, most of us software types think in a similar fashion when it comes to non-software: It's our car that doesn't work, not the ignition or the transmission. We just can't get to work because the system is down, and we don't really care at that point about the root of that problem. We just want the solution. So we take the car in the shop.

But there is no equivalent of "the shop" when it comes to a computer system. The local computer guy might help fix this and that, but they seldom perform the maintenance work required to prevent crises from breaking out. In the world of small business software, I believe that there is a need for the equivalent of a service station.

Lacking the notion of preventive maintenance, and lacking the sophistication in popular commercial operating system to peform that maintenance automatically, software vendors catering to small enterprises end up becoming service-based businesses, not product-based. In other words, they will end up, by default, delivering the value by performing services (crisis management, etc), and not by selling products. They end up as emergency room operators without the help of medical insurance or government assistance.

The problem with that is that a business must invest in the areas where it sees the most return. If we don't see return from developing and selling great software, we won't be justified to invest into that area of our businesses. Instead, we will probably have to invest in the services and crisis management areas.

Services might just be where the software business, in general, is going. To finish the auto business analogy, car manufacturers are realizing that they, too, become increasingly dependent on services to create revenue. Instead of investing in new technologies for making cars better and safer, they must equivally, if not more, invest in building service offerings to support the "systems" their customers care about.

Becoming a service businesses raises interesting questions for technology firms: How does R&D and intellectual property help that kind of a business? Should we look to successful restaurants (as an example of a service business) for business models instead of the Microsofts and Suns? What happens to the typically high profit margins of technology firms when they convert from being product-based companies to being service-based ones? If the auto industry is any guide, those margins will surely decline.

Admittedly, I wanted this blog to be as much an invitation for comments as a rant about the way I see things. You're input is most appreciated.

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.