The Business Case for Portability

The collective experience of hundreds of projects demonstrates that writing cross-platform, portable code is well within the skill level of most development organizations. But just because you can write such code, should you? The only valid reason for creating portable solutions is that doing so will ultimately result in a more profitable product.

The revenue side of this equation is based on whether or not you'll obtain a sufficiently large market and charge enough to be profitable. Marketects are often good at identifying these revenue drivers. Unfortunately, they often forget some of the key cost factors. Consider the following.

• The costs of training the developers, QA, and support people in developing within, testing, and supporting each platform.

• The costs of purchasing, configuring, and supporting the hardware and software for each supported platform. Each group has different needs with respect to these activities. Developers are most productive when you give them fast hardwareoften the fastest possible. QA and support need a range of hardware choices to adequately reflect the performance options that match target customer segments. Someone has to support all of this hardware. If your IT department isn't up to the task, someone in development, QA, or support will have to do it. This often creates a hidden cost.

• The testing time for developers and QA to make sure that the product works properly on each platform. As a general rule, the larger and more complex the matrix of pain (the complete set of your supported platforms) the longer it will take to release your product. This isn't necessarily a cost, but instead can be lost revenue.

• The complexity of managing multiple release cycles. Suppose that you choose to support Solaris, HP-UX, and Linux. This means that you must track three operating systems. When Sun Microsystems releases a new version of Solaris, customers will want to know when you are going to support it. Each time you choose to support another platform you relinquish a bit more control over your release cycle.

These costs can only be justified by a sufficiently large target market. One company I worked with supported SolarisOracle and WindowsSQLServer. Approximately 90 percent of their installed base ran Windows-SQLServer, accounting for more than 80 percent of total corporate revenue. The cost to support a cross-platform product was not recovered and the company actually lost money on a spurious marketing claim.

The following conditions should be met before building cross-platform solutions.

• Your market analysis identifies sufficient revenue to justify the incremental total product development and support costs associated with each platform.

• You have included the total cost associated with developing, testing, and supporting all of the supported platforms. This means the necessary hardware and the skills necessary to maintain and configure these machines.

• You have sufficient development resources to allow you to create, test, and support multiple platforms.

• You understand the relative impact the various platforms you must support have on your development efforts and can manage it. For example, if you're going to support Solaris and Windows you have to account for their differing release schedules.

A good rule of thumb is that it is easier to justify a portable technology than a portable application. By technology, I mean a solution designed to be a component of a larger solution. Examples include relational databases and communication libraries offered to large target markets. The classic example of Oracle in the book Crossing the Chasm [Moore 1999] shows how a portable technology helped a company win significant market share.

Portability Is Always about the Money

I've managed both ends of the portability spectrum. We explicitly designed a new kind of enterprise-class system for an emerging market that was not portable but was designed to run only on Microsoft productsMS Windows NT/2000 and SQLServerusing Microsoft development tools. Our first challenge was selling the system to Sun Microsystems. As you can guess, the initial response was "No thanks, we don't want a system based on Microsoft technology " (although the original wording associated with the rejection was a bit stronger). Sun wanted us to port the system to Java/J2EE running on Solaris and Oracle. We also received a no from Pfizer on the grounds that our Microsoft-based solution didn't fit their corporate SolarisOracle requirements.

It was difficult to handle these early rejections because we knew that Sun and Pfizer would be good customers and we were a young and hungry startup. But a simple cost analysis showed that we couldn't afford to port the application with the available resources. When we asked Sun for the necessary development funds, they said no. I don't blame them, for we estimated that the job would cost several million dollars.

Although the situation seemed bleak, everyone supported the decision to maintain a platform-specific focusan amazing show of discipline, especially given our hunger for revenue. Nonetheless, we kept improving our technology and growing our customer list. After each release, we would talk again with Sun and Pfizer. Eventually, something amazing happened : The system had reached the point where its feature set was so compelling that the two companies simply couldn't live without it. Furthermore, their competitors were adopting the system, which provided them with additional incentive to license it. And they didfirst Pfizer and later Sun. The key lesson I learned is that building a good solution on a single platform is more important than building a mediocre solution on many.

At the other end of the portability spectrum, I managed server software that ran on Microsoft, Sun, and Linux operating systems and client software that ran on Windows and Macintosh. Unlike the previous example, these were not complete applications (solutions) but core technologies embedded in our customers' environments as part of a larger solution. In this case, the technology requirements justified a portable solution. On the server side, the revenue distribution was almost evenly split between customers running Windows and UNIX. On the client side, our biggest customers, including Adobe, Symantec, Macromedia, Corel, and Roxio, required both Windows and Macintosh. Indeed, they continually asked us to port our technology to additional platforms. This confirms that listening to your customers and making certain portable solutions will be profitable solutions is your best approach.

Applications, which are rarely designed to be a component of a larger solution, can often achieve a large and profitable enough market share within a given operating environment so that portability doesn't make sense. Countless applications from profitable companies run only one operating system (e.g., Sun Solaris, MS Windows, IBM 360). These companies, for a variety of reasons, have decided to focus on a target environment.

Rules of thumb are just that: rules of thumb. There are also numerous counter-examples of platform-specific technologies and portable applications. Examples of portable applications include any number of mid-range server or desktop applications. Concrete examples are some of the mid-range graphics tools that run on both Macintosh and Windows platforms. For the average user , these tools are acceptable. For the professional, they aren't, and professionals turn to high-end, platform-specific tools that are tuned to leverage all of the capabilities of a given platform. There are also many examples of platform-specific technologies, such as network accelerators that run only on Solaris, or serial port expansion cards that run only on Wintel platforms. The issues are complex, but all of them boil down to well-defined target markets that ultimately determine how the development team should create the application.