Product Platforms in Software Development

Companies that make nonphysical or intangible products, such as software and computer-based information services, can use the concepts of product families, product platforms, and derivative products. Our purpose here is to show how to apply these concepts for more effective development of software products, whether for commercial sale or for systems developed by MIS staffs.

Our first hypothesis: that well-designed platform architectures for software products, like platform architectures for physical products such as a car or office furniture, can provide substantial R&D productivity benefits for development organizations. We define a product platform as a set of subsystems and interfaces that form a common structure from which a stream of derivative products can be efficiently developed and produced.1 That efficiency is measurable in terms of the cost and time required to generate products from underlying platforms.2

Platforms as an engineering concept are not new. A chapter in Modern Man by Henry Ford contains a careful delineation of subsystems inside an automobile and examines new component technologies both inside and outside the company to improve comfort, ease of use, and durability.3 And, during the development of the DC3 in the 1930s, a small team of dedicated engineers that wanted to make commercial passenger traffic profitable for the fledgling airlines designed the DC1 platform as a series of innovations to major aircraft subsystems. The new platform subsystems included new designs for a welded frame, new engines from suppliers, new navigation systems, stronger landing gear, and a passenger friendly interior, all designed during several weeks. Better versions emerged, leading to the DC3, and from it, a passenger version, a cargo version, a troop-carrying version, and so on, all derivative products based on the same product platform.4 Platforms are the common sense of yesteryear being rediscovered today by management in various industries.

This definition — the platform composed of subsystems and interfaces between subsystems and the external environment — serves well for software. Indeed, at a conceptual level, the architecture of a software platform differs little from that of a chair. The chair’s subsystems include the pedestal, stem, seat, armrest, backrest; the subsystem interfaces include various fasteners, coasters, and user interfaces, such as the height adjustment lever and seat cushions. A word processor’s subsystems are similarly modular, although far greater in number, ranging from file access subsystems to those for editing, formatting, importing graphics, and printing, all with internal subsystem interfaces and a Windows-style user interface. Each product, the chair or the word processor, requires a careful study of the user’s requirements and incorporation of these discoveries into engineering initiatives. The only difference is that there are many more subsystems in complex software than in the typical physical product.

In software, the interfaces reign supreme, that is, controlling their design and evolution can lead to long-lived systems and is one element of market domination. In fact, the interfaces between subsystems can easily be more important than the subsystems themselves. Microsoft, for example, effectively guides the innovation of thousands of independent software companies by having developed and promoted as a “standard” the interface mechanisms that allow different programs to communicate with one another in a Web-centric distributed computing environment —known among software developers as “ActiveX.”

Our second hypothesis builds on the first: that platform architectures for software firms are also a business model, allowing for rapid development of market share and revenue. For a software company, the benefits of a robust platform include the ability to more rapidly and flexibly create products tailored for particular niches within the company’s market focus. This is achieved by building small, solution-specific modules that plug into a larger, more generalized foundation of common program code that provides base-line functionality for all specific solutions. This approach can lead to market advantage through more timely new product introduction, a richer product family covering a broader scope of a particular market, and ultimately, barriers to entry for other competitors that lack an equivalently robust product line.

Microsoft is masterful at translating the technical leverage derived from common software platforms into market power. Many of its individual products share software leading to a common user interface, common methods of accessing data, and common approaches to communicating over networks and the Internet.5 For internal MIS staffs, internal customers appreciate commonality and ease of integration in systems. “Interoperability” reduces the learning time from package to package in which each package shares a common user interface, or in integrating different systems so that data from one may be readily accessed by another.6

Beyond these benefits, however, lies an even more important market advantage enabled by platform thinking and execution. If the developer builds and clearly communicates methods or techniques by which other companies or individuals can build modules that operate in or on the underlying platform, it has created the opportunity to become the standard or basis of large-scale innovation. Platform architecture can allow a software company to become a conduit for other individuals or companies building modules based on that architecture. Strategically, the firm can foster the development of a multitude of derivative products created for different specific uses or market niches without having to bear the direct cost of programming labor. The firm can also reap the benefits of brokering or distributing these third-party software modules. The business is transformed from being merely a producer of products into a channel of distribution.

Of our two hypotheses, one deals with R&D productivity and the other with commercial outcomes. We now present a visual model of the implications that a platform has for developing a software product family. Next we explore that model through two in-depth case studies. Then we suggest ways to manage software development with greater clarity and purpose.

Demystifying the Software Platform

To clarify the meaning of a software product platform, it may be best to first explain what it is not. During the 1970s and 1980s, people developing or acquiring software referred to the type of computer that the software was made to run on as a platform. For example, Lotus Development Corporation initially targeted the Intel-based personal computer as the platform for its 1-2-3 spreadsheet product and the Macintosh computer and Unix workstation as successive platforms. Other spreadsheet companies targeted minicomputers or mainframes as their platforms.

During the late 1980s, the software community’s use of the word “platform” transformed dramatically. Operating systems, always important in the overall scheme of computer technology, became a central force, consuming the efforts of manufacturers, software firms, and service providers. Microsoft’s operating systems offerings became the de facto standard for desktop and notebook computers. The influence of operating systems was so pervasive that software developers began to think of “platforms” as the particular operating systems on which their products functioned — Windows, the Macintosh operating system, a version of Unix, or a proprietary IBM operating system. However, the various subsystems and interfaces within Windows are a product platform for one company — its producer, Microsoft. For all the companies that make software, calling Microsoft’s operating systems their own platform is not enough for them to be efficient and effective in their respective development of robust platform architectures. The user interface, communications, and database interface technologies provided by Microsoft or Sun Microsystems (the two warring camps in distributed computing) are only a subset of all the subsystems and interfaces that the developer designs and implements to create the platform architecture needed for his or her own products.

Similarly, many companies see the implications of the Internet as a major shift not just for the software they make or use but for their business models. For example, many people like the ease and convenience of the Internet to order flowers for remote delivery on Mother’s Day. In terms of software development, however, who would consider the Internet as the “product platform” for the on-line mall and order-taking software for flowers? The Internet comprises the enabling core technologies for communication and interaction that are built into various subsystems performing tasks for the user or the machine. The on-line flower distributor’s software platform might include a database of products, an electronic commerce engine (including credit card authorizations), the user interface for browsing and ordering, and a customer notification subsystem. While these all employ Internet technologies, they are the “platform,” not the Internet itself.

Nonetheless, many managers still view the operating system environment or, more recently, the Internet itself as the platform. Obviously, when operating systems change or new core technologies emerge, software developers may need to revise the architecture of their own software products, just as Microsoft has done with its internal architecture. Externalities are important because they are part of the total environment in which a particular system must function. However, an externally focused platform definition does not suffice for a software company wishing to fully manage the architecture of its own products. Management needs an internal, comprehensive definition of its own software product platform. Each company must create or derive that platform architecture best suited for its own products and systems. Our frameworks may serve as templates in that effort.

The Architecture of Software Products

Every software product — an operating system, a programming tool, or an end-user application — has an internal product architecture. As with physical products, that architecture can be structured to create a robust platform architecture from which derivative products can be efficiently developed.

For example, screen savers were developed to fill a clear need: to avoid monitor damage from phosphorous burnout, which occurs when programs are left running unattended for long periods. Screen savers have libraries of different images. Some businesses have created their own screen-saver modules for consumers to download over the Internet and plug into Windows 95 — all for the purpose of branding. Each image is a distinct module that can be used with the same screen-saver program. The general architecture of the program is the platform. The specific shapes are plug-in modules. The user can go into the screen-saver customization program to pick an image. In effect, this creates a specific derivative product for the user based on the same product platform, for example, the underlying screen-saver software or engine.

Many developers are trying to achieve this software platform architecture. The platform is the base software engine, and derivative products are the add-in modules that can be seamlessly plugged into the base engine. A software product family — which, in the screen-saver example, is the platform and the collective images developed for it — can provide great choice and variety by giving users customized modules that can be incorporated into the software platform at no additional integration cost. Robust standard interfaces for both developing and then using specific programs with underlying software products are central to software platform design strategy.

The platform is composed of the developer’s design strategies and specific implementation procedures and protocols for the products within the entire family (see Figure 1). In the abstract, these rules and tools can be incredibly powerful. To a software developer, for example, a Web-centric, object-oriented design philosophy has as much meaning and consequence as the decision to use metric measurements has for a power-tool designer who thereby targets a global market. In tangible form, the software architect’s rules and tools will eventually become standards and protocols embodied in programming libraries and data/object/rule specifications that all applications developers working with the architecture will (or, more aptly, should) follow. Supporting or enabling technologies for that par- ticular generation of the product family can also be considered components of the platform architecture. Here, operating systems, hardware, networking environments, and the like fit into the overall picture. To reiterate, these core technologies are an important part of the platform picture but not its entirety.

The applications or solutions layer is composed of specific modules of software that plug into and work seamlessly with the underlying software (see Figure 1). There are two general types of applications: those common to all market niches within the scope of the software product family and those specific to each niche. For example, a business software company might have general ledger, accounts receivable, accounts payable, order entry, and inventory modules that serve all its target markets. Then it might have specific modules that tailor these functions or produce specific reports and management analyses for retailers, mail-order houses, manufacturers, and professional services firms. Each might be a derivative product in the classic platform sense: specific software that utilizes the infrastructure and information provided by the underlying software platform.

The applications development interface is where developers inside and outside the company create specific software modules that work with the base product. Once a number of external programmers take advantage of this interface, the company can either resell this new external work or facilitate such work by third parties. In either event, the company has the potential to offer to its customers a range of functionality far beyond what it could provide with its own resources. Furthermore, to both external developers and customers, the software development company can be transformed into a channel of distribution. The implications for market share and firm valuation are substantial.

Any particular generation of a firm’s product platform should not be a monolithic entity that must be used in its entirety in creating a derivative product. Rather, the platform is a collection of subsystems, themselves composed of modules or components, any number of which may solve a particular application problem or requirement. A “complete” platform will either have or provide linkage to all the building blocks that the application developer requires to satisfy the user at a reasonable cost and time.

Does this model apply to internal software development by MIS staffs in corporations? Most companies fail to integrate the information systems of respective divisions or departments. Over the years, however, data warehousing and other types of enterprisewide computing approaches have sought to create common repositories of programs and data that various groups can use and add to. The same empirical support for the platform approach is not widespread among the internal MIS developments of large corporations, but that does not mean that the model is any less applicable.

In summary, a software product platform is both an architecture and an implementation of architecture that comprises core subsystems that propel a family of software products or internal corporate applications. The subsystems are based on key enabling technologies, such as databases, programming languages, or the Internet. Modules are developed and plugged into the platform to provide various solutions for customers or users, either as new versions of existing products or systems or as entirely new products or systems. In well-designed and -implemented platforms, individuals or entities outside the company can make these modules.

Software Platforms in Action

Visio Corporation makes a highly successful line of graphics-charting software. Begun in September 1990, the company shipped its first product (Visio 1.0) twenty-six months later. Today, its revenues have surpassed $100 million, and it has users in about forty countries. Scores of plug-in modules are available for Visio software that contain all types of industry-specific diagrams, many made by companies and individuals.7 The business success of the company’s technical and marketing approaches is strong, considering the fierce competition; Microsoft has a charting package too.

The company’s founders agree that their platform strategy, focused on building an architecture that is “open” and “scalable,” played an important role in the firm’s success. They had a clear vision: to create a major software industry platform to which both the company and then other companies or end users could easily incorporate add-in shapes (SmartShapes) and charting scripts (often called “wizards”) to draw charts and diagrams. These shapes carry a certain “intelligence” that makes their use convenient and powerful. For example, the software will automatically adjust connections between different shapes when they are moved or resized. For technical applications, such as charting requirements in engineering, architecture, or science, providing specific behaviors for certain types of shapes can have dramatic benefits as the user constructs complex diagrams.

Visio’s architectural approach mirrors that of the screen saver (see Figure 2). The major components of the platform are the core graphics engine, the SmartShape management subsystem for incorporating and then manipulating graphic objects, and an applications programming interface that provides a standard scripting language so developers can create and integrate their own plug-in programs into Visio.

For example, a user can select an organizational chart “stencil” that contains numerous specific shapes. Or the user can run the “organization chart wizard” that automatically constructs an initial chart based on a series of questions and answers, allowing the user to specify an external data input file that contains names, titles, and ranks. Either way, the user can then edit the chart with standard graphics tools via menus. The user can draw, label, connect, color, and resize objects in the charts, from simple to complex.

The true power of Visio’s platform approach lies not only in the ease of use and functionality of the general product, but also in the many add-ins offered. Through these, the company can address the needs of unique user markets with value-rich applications. These derivative products have various roles in the markets that the company addresses: home, business, and technical (see Figure 3).

Perhaps most important for the evolution of Visio’s business is a development package that contains numerous shapes and source code examples so users can develop their own stencils and wizards. Using these, developers have created customized charting applications based on the Visio platform.

The power of the platform approach for software is similar to that for physical products: a software developer can provide a family of products without starting from zero every time. R&D efforts to import the software to a new operating system or networking environment or to use a new set of software development tools can also focus at the platform level and then move automatically across the entire product family. In most cases, a company’s improvements to its software platform are released as new versions of an existing product. In other instances, however, platform improvements can open new markets for the same basic technology. Visio has introduced a new version of its core product almost annually. Six major releases later, the underlying platform has advanced to incorporate many fundamental computing features.

Along with this platform renewal, Visio has penetrated a variety of new industries and areas. Users have made thousands of plug-in modules for internal corporate applications; and Visio is helping its business partners promote a hundred other modules to several million Visio users. Within the product family, charting modules exist in fields as diverse as biotechnolo-gy, petroleum engineering, insurance accident reporting, and process reengineering. Although Visio’s own programmers are not experts in these domains, they are building the programming interfaces so that domain experts can build shapes and programs. Like other major players in the software market, Visio has strong partners to provide marketing and technical assistance.

A more subtle but equally compelling benefit is that the add-in modules are what the end user employs most. If these modules are clearly separated from the underlying software platform, they can be carried forward across generations of the product platform, often without radical revision. End users can thus be shielded significantly from changes in the underlying technology from year to year.

In successful software firms like Visio, the combination of smart technology and equally smart distribution wins the game. Quark, for example, is a privately held firm that has a commanding market share in the high-end professional electronic publishing and communications industry. There are hundreds of plug-ins for QuarkXPress, made by third parties and distributed through independent software houses. The company is now creating new platform designs that help customers manage their repository of pictures and other graphics in a client-server environment.

Hewlett-Packard’s OpenView network management software was initially marketed as an environment for developing applications, e.g., a platform for creating a host of specialized applications. HP provided the OpenView platform with the Network Node Manager, which gives a graphical view of a computer network, including all the devices on the network, the logical and physical connections between the devices, and the operational status of each device. It gives network administrators an at-a-glance view of their networks from a single computer console. Programmers in the data communications industry have created many OpenView derivative applications.

Both Netscape Navigator and Microsoft’s Internet Explorer are powerful host environments for Web applications, such as electronic stores or customer support centers. Each has a seemingly infinite number of plug-in modules made by other companies, conforming to the browsers’ respective programming interfaces, that can be downloaded and run transparently and seamlessly. Netscape is now giving away its source code, hoping to further entice programmers to build plug-in modules for its product.

Renewing Platforms

In software, competition is hyperactive. Platform renewal is therefore essential to sustained success. Take, for example, operating systems. A vendor of “real-time” operating systems, VenturCom, was founded in 1980. Its founders made Unix run on an early IBM PC with the early Intel 8088 processor. They also created a real-time process scheduler within Unix for process control applications, such as brewing beer or scientific experiments. During the 1990s, the use of Unix for industrial process control applications declined. Management began to distinguish between VenturCom’s core competence in real-time, embedded systems and its competence in Unix specifically.8 The company ported its software to Windows NT in 1993 and to Windows CE in 1997.

The new platform has more rapid response times than the prior Unix-only version (see Figure 4). The company also provides tools to measure response times and evaluate different hardware environments. Further, its Windows programming standards allow users to employ other development tools and programming libraries that also conform to these standards, whether from Microsoft or a third party. Customers program their real-time applications and then download them into read-only memory chips as part of closed, special-purpose systems. The customers themselves then build the final systems to control robots, run telecommunications switches, or operate various instruments.

To survive, the managers had to evolve their thinking about the company’s product architecture and its role in current and prospective markets. “We had limited ourselves by viewing the operating system as the platform,” remarked one founder. “Our platform was really our real-time scheduling algorithms and embedded systems architecture. Once we realized that, our potential rose exponentially.” The company made the transition from one generation of platform architecture to the next.9

Platform Evolution

The management of platform evolution does not have to be a monolithic endeavor. The increasing modularity of software allows a more concurrent engineering approach, in which small teams can improve core subsystems or end-user applications piece by piece and still incorporate them into the overall architecture. For example, Visio rewrote several key platform subsystems from older sixteen-bit technology to Microsoft’s thirty-two-bit architecture in Windows 95 and NT operating systems. However, all the SmartShape sets and add-in code from prior versions remained operational and useful without changes on the new thirty-two-bit platform. How much time, cost, and risk would have been incurred had the company had to rewrite, translate, and test thousands and thousands of graphics shapes and customized programs? Instead, the new platform attracted more users and new developers. The product family continued to grow.

Management may sometimes be forced to scrap everything and start anew. An example is Lotus Development Corporation’s transition from PC desk-top technology to a distributed, component-based architecture for its office applications software — the development of eSuite compared to its earlier development of SmartSuite. During the 1990s, Microsoft and Lotus fought for share in the Windows office suites market. By the end of 1997, Microsoft Office had 80 percent market share. Lotus tried to match Office feature for feature to maintain its own share. Finally, Lotus had to change the rules of the game and create a set of products that altered how customers viewed their own office productivity software. Java, and more specifically, distributed computing, offered some help. (Java is a programming language that allows programs to be downloaded over the Internet and run on anyone’s computer through standard Internet browsers.)

Lotus’s SmartSuite evolved from single products into a semi-homogeneous set of applications. The product platform grew from this group of programs over time. The individual programs had to be retrofitted to work together and share a common user interface. The underlying product platform for Microsoft Office also evolved in this manner. In both instances, the net result is a collection of programs that share some common subsystems. For Lotus, its word processor, spreadsheet, and graphics and presentation maker share charting, spell-checking, an information box, different input and output filters, an OLE/ActiveX subsystem, and an applications-authoring language called LotusScript. While others can write LotusScript eXtensions for any SmartSuite application, Lotus itself made the vast majority of features.

Office application suites, whether SmartSuite or Microsoft’s Office, contain more than 200 megabytes of code that have to be updated in thousands of machines. In a component-based, distributed computing environment, an Internet server can dynamically download those components that a user requires and then allow data from the program to be used by other dynamically requested and downloaded programs. To create systems that exploit this environment, however, a company has to redesign its software platforms.

Lotus recently introduced eSuite, which has a completely different architecture than SmartSuite. The emphasis is clearly on third-party development and its potential challenge to traditional monolithic office suite software. Lotus saw the entire office suite as a set of small applications (“applets”) wired together dynamically at the time of execution. The applets are designed as components developed in Java, called JavaBeans.

eSuite’s platform features two interface components so critical that management views them as the two primary subsystems of the product platform. The first, infoCenter, controls the user interface so that new applets can be brought in at anytime and behave identically to other applets already in use. The second, infoBus, controls the sharing of data and other information between applets. All data are fully contained and have self-descriptions so that other applets can access them. Data integration has always been time consuming and difficult when joining complex systems; Lotus’s component-based approach in eSuite makes data integration easier. Other developers do not have to learn a special Lotus scripting language to write plug-in modules. Rather, they can use a general purpose language (Java) and simply incorporate Lotus’s major subsystems into their own code to make modules that look and work as if Lotus itself had made the modules.

The underlying design principles of the component-based software for distributed computing environments fit into the platform strategy we have described: providing mechanisms that allow third parties to build applications for their own platforms, thereby accelerating the development of the overall product family. Derivative products from this type of platform technology can be developed even more quickly because they are a collection of applets. Developers that share an interest in a particular vertical industrial market or broad consumer category can work together, without knowing one another or sharing a corporate affilia-tion. Other authors have likened this pattern of development to a swarm of bees taking flight, collectively adapting to changing environments and conditions without central command and control.10

As students of management, we find it both intriguing and commendable that the same company that made SmartSuite is developing eSuite. Its management has allocated resources to make an existing product obsolete with technology that is more flexible and extendible, and that offers the promise of creating more useful solutions. The point is clear: if an architecture and its complementary subsystems and technologies are outdated, management must proceed expeditiously and forcefully to renew it. In an industry cycle of “Web years” (only three months), relying exclusively on a decade-old architecture can be perilous!

Determining the Need for Change

Unfortunately, the platform design and management presented here is the exception in the software industry. How can software companies embrace commonality and leverage technology? How can management be convinced that a current design has “run out of gas” and that a different approach is needed?

First, we recommend that a small, dedicated team working with a senior executive’s sponsorship must assess the current situation and develop a new solution. Without sponsorship, the team cannot create a common set of subsystem technologies across the breadth of the firm’s software. This platform team may begin in central R&D, but must seek input and participation from line groups responsible for specific systems development. Platform design and development requires a common, enterprisewide perspective for both analysis and action. Or, if the initiative is focused on improving internal applications, the MIS platform team may start in central MIS but must quickly include lead users and application developers from operating units. Either way, the team must first show that a platform architecture will make better business sense than the existing system.

The team must start with a holistic understanding of target applications. Team members should first develop a market segmentation grid to document both market information and systems or product status information. The grid should have market segments on the horizontal axis and tiers of price performance, such as high-end or low-end, on the vertical axis (see Figure 5, an example taken from a measurement systems software company). In many cases, such as complex information systems or internal MIS applications, tiers of price performance will not seem truly applicable for segmentation.11

Many corporations fail to consider all their markets together to design common information system structures and building block technologies. They treat each column in the grid as a separate business, with R&D decentralized to each business unit. Over time, systems tend to grow further apart in terms of sharing common platform and applications components. Integration between systems becomes virtually impossible. If management desires commonality, it must begin by having all team players realize that they are building solutions for different parts of the same market.

The team can use the market segmentation grid to map current systems and assess the degree of commonality across the different systems on the grid. (Figure 6 shows an example of this mapping, differentiating what could be common, and what is actually common, using words such as “unique” or “common.”) The team must consider two levels of technology when assessing commonality: (1) in low-level building-block technologies (such as databases, languages, or operating systems), and (2) in applications components (the platform subsystems and interfaces).

Team members who are intimately familiar with the systems under consideration must do these assessments. When these data are coupled with project staffing levels, development budgets, a rough allocation of staff to types of work (building tools and subsystems versus building final applications), and cycle times, the results can be revealing.

The team at a measurement systems company found no commonality in terms of sharing platform subsystems between its different measurement system products (see Figure 6). Yet subsequent internal analyses and companywide discussions showed that great potential for such sharing in all five major application subsystems across the seven product groups. Additionally, most of the systems failed to share common building-block technologies such as database management systems.

Commonality can be measured by dividing all subsystem areas that use shared or common technology by the number of subsystems across all the product lines where the team finds clear opportunity for subsystem sharing. In the case shown in Figure 6, none of the subsystems among the thirty-six subsystem iterations where sharing was shown to be possible and desirable were common to any other system.12 This was clearly not optimal; management sought to achieve at least a 50 percent degree of commonality.13

The team should also examine financial performance for the firm’s software products to plot changes in sales and contribution by product line (or by business unit) (see Figure 7, an example taken from an industrial systems firm). This technique requires that firms maintain appropriate allocation of revenues and expenses to products or systems, and groups of products or systems. In the case shown in the figure, management’s allocation of R&D funds has been roughly equal for all systems, even though only several showed any promise of sustained growth.

The team should also document market factors, including total segment size and growth, leading competitors, the firm’s sales and share, and the number of engineers and engineering costs associated with development (see Figure 8, a template example). Often companies work in traditional markets without considering current market size, growth, and competitive competencies. Gathering market information systematically in this manner and then overlaying those areas in which a company’s systems currently “play” is a reality check. The team may find that resources are not directed toward producing products for the most rapidly growing markets or that the needs of internal customers may not be addressed.

The team should map all the organizations responsible for developing systems for external or internal customers on the grid. Organizational boundaries and overlap may explain the divergence of underlying computing technologies between different systems.

Planning a New Product Platform

Together, these various analyses will provide an accurate portrait of systems development areas relative to the key issues we’ve discussed. At this point, the team should seek approval from the sponsoring executive to develop a common platform proposal and budget and authority to engage developers from across product lines and key customers. There are four essential steps for putting together a plan:

1. Understand target users’ simple and complex requirements.

For example, systems developers have to reconsider the basic meaning of “reporting” in the context of the Internet. Or a developer of medical information systems must not only perform certain types of statistical analyses but also consider how practitioners might access information through the Web in the context of remote diagnosis. Whatever the method a company uses to create its system specifications, designers must try to understand users’ frustrations and limitations. The team must have face-to-face discussions with representative users, rather than relying on third parties for market research.14 If needs vary across different customer groups, the market segmentation grid can be used to organize the analysis and presentation of requirements.

2. Propose a new platform architecture and strategy.

A high-level block diagram of the new architecture helps portray the major subsystems and interfaces in the proposed design. These subsystems and interfaces are those components of technology that, once developed, will be shared across development groups within the company and potentially with outside developers. Most important, the platform design must embrace all the target market applications that the design team has chosen for the initiative.

3. Propose an implementation plan, budget, and time line.

Increasingly, product platforms are a collection of reusable components that various development teams, either inside or outside the corporation, can use to build solutions. Therefore, a development plan for a proposed platform need not present a grandiose budget for a monolithic systems development effort. There is no substitute for short-build cycles, focused deliverables driven by clearly stated user requirements, and an overriding discipline that imposes relatively short time periods between successive new product releases (three to six months, rather than two to three years).

4. Propose an approach that harmonizes the realities of decentralized R&D with the need to jointly design and share platform components and development processes.

This is management’s most difficult task. A totally decentralized approach to platform development will lead to many different platforms and a lack of commonality in both the look and feel and data integration of derivative systems.

One approach is to make a platform group the “next step” concurrent engineering group responsible for platform architecture and specification and development of next-generation subsystems within the platform (see Figure 9). This group is responsible for defining user interface and data interfaces for the entire portfolio of products or systems. It should also be responsible for development processes and methods used throughout the company. Its staffing does not necessarily have to be permanent; small teams from application groups can improve subsystems in the common platform or add new capabilities.

In this sense, the platform team becomes an interface that coordinates the shared needs of different applications development groups and advocates a common approach to development. The governing “board of directors” for the platform group are the managers of business units, who will invariably want their R&D managers to help define platform goals and funding levels from year to year. One manager described this approach as a “honeybee” model of organization and cooperation: the platform team creates the structure of the hive, and different groups arrive asynchronously to pollinate and draw sustenance from it.

Conclusion

Software platforms are the collection of subsystems and interfaces on which an organization and its external partners can build a stream of specific applications targeted to different users. Platforms make technical sense not only for software but also for the business.

Senior management’s understanding and buy-in is essential for achieving an effective platform strategy. Companies must upgrade their systems — software products or internal applications — or face competitive disadvantage. It is a safe bet that the component-based technologies of Microsoft and Sun Microsystems will fundamentally change new systems development just as two-tier, client-server architecture transformed computing during the past decade. Imagine the time and costs if a major software company with twenty derivative products has to rewrite programs individually for this new computing environment. Compare that to a new competitor that creates a systems or product platform from which it can make derivative systems or products in a fraction of the time and cost. The new competitor has a good chance of beating the old market leader. Or, imagine a large financial services company facing the same task with hundreds of applications, each built at a separate time and with different, poorly documented data structures.

The platform approach is an opportunity for both firms and MIS departments to be more efficient and effective in systems development. However, the executives in those organizations have to rethink how their corporations plan, budget, and organize for such endeavors.