6.1 Industrial Organization and Software Architecture

Industrial organization closely parallels software architecture (see section 4.3). As with software architecture, there are three issues that must be addressed: the decomposition of the industry into cooperating and competing firms (analogous to software decomposition), the separate and overlapping responsibilities of the individual firms (analogous to the functionality of software modules), and the business relationships among firms (analogous to the interaction among software modules). Organization and architecture influence one other because organizational efficiency increases if organizational and architectural structures can be reasonably aligned. Conway's law (see section 4.2) made this observation early on: "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations" (Conway 1968). The recent view suggests it is advantageous for organization to follow architecture (Coplien 1995).

There are also strong indications that the most successful software suppliers (and computer suppliers) over the long term are those that take the lead in defining an architecture and then position themselves strategically within this framework (Ferguson and Morris 1994). Such firms have many more strategic options and opportunities to manage the relationships with competitive and complementary firms than those focused on "point products" that serve a specific need independently of other products.

Example With its System/360, introduced in 1964, IBM offered for the first time an architectural framework for mainframes that supported a range of needs from small and inexpensive to very advanced, all with compatible software and allowing its customers to migrate gracefully as their needs grew. By defining and controlling this architecture, it set the basic ground rules for competitors' adding components and applications to a system. Intel has followed a similar path with its 286 microprocessor architecture; it has sought to define and promulgate an architecture for all the functions surrounding the microprocessor, the bus for expansion cards, and the interfaces to peripherals. In software, successful operating system suppliers (Digital, Hewlett-Packard, IBM, Microsoft, Sun Microsystems, and others) all define and promulgate an architecture that allows applications to access system resources and enables application composability.

From this perspective, choosing the industrial organization is choosing the modularity of an industry, as well as the modularity of the software produced by that industry. (Of course, the industrial organization is determined to a large degree by market forces rather than the invisible hand of an architect.) To emphasize these parallels, this chapter uses the terminology and perspective of software engineering to describe industrial organization. What modularity would be natural in terms of natural business functions and core competencies and the relationships among those functions? These insights are then compared to the observed industry structure.

Relative to software, decomposition arises in two contexts. This chapter examines the decomposition of the overall supply chain functions that were discussed in chapter 5: software creation, provisioning, operation, and use, in which the software itself is considered monolithic, an economic good that is acquired as a prelude to the other steps in the supply chain. The division of labor between traditional software companies and other types of firms is fluid and ever-changing. The supply chain perspective best captures the issues faced by end-user organizations, and the software industry perspective best captures the issues of software creation. The intermediate ground between these perspectives harbors many organizational possibilities, in theory and in practice.

Individual firms have responsibility for complementary functions, for example, software development and maintenance, user support, provisioning, administration, and management. A goal is to address how these responsibilities can be naturally divided among firms, how this partitioning of function is changing, and what factors drive this change.

Another issue is business relationships among firms. In this regard, one driver is ownership. A software application and its supporting infrastructure typically incorporate a number of modules and underlying hardware technologies that may be owned and supplied by different firms. Boundaries of company responsibility must align with interfaces among software modules, and interface design and specification form an important means of coordination and separation of responsibility. Since software is freely replicated and nonrival in use, it is not sold in the traditional sense but is licensed for replication and use under specified terms and conditions. Ownership takes the form of intellectual property, a form of government-sanctioned and enforced property rights (see chapter 8).