Chapter 5. The Orchestra Model

Think about the last potluck dinner you were invited to. The host probably decided the theme—for example, a barbeque or an Italian dinner—and requested that each person bring a dish, dessert, or supplies that contribute to the overall theme. And the host probably contributed a main dish, and other people’s contributions were meant to complement the main dish.

Now consider the story of the “stone soup.” Legend has it that a wandering soldier came upon a famine-ridden village, and found that all the people were jealously hoarding their food. At first, the soldier thought of moving on because there was nothing for him to eat, but he decided to try a creative strategy to get a meal. He announced that he had everything he needed to make soup, and proceeded to fill an iron cauldron with water. He placed a stone inside the cauldron, and built a fire under it. A curious villager approached the soldier and asked what he was doing. The soldier answered that he was making stone soup, which would taste wonderful, although it still needed a little bit of cabbage to improve the taste. Soon another villager approached and offered him cabbage. The soldier added it to the soup and mentioned that it might need some potatoes and onions. Another villager soon offered these for the soup. And so it went, from vegetables to seasoning to garnishes. Finally, everyone enjoyed a delicious pot of soup.

These scenarios have some similarities and some differences. Both involved a central entity (the host family or the traveling soldier) who defined the primary theme for the dinner—a theme that would shape the contributions of other members of the community. In both cases, the contributors (the invitees or the villagers) shared the value derived from the final outcome. However, in the case of the potluck dinner, the host contributed the main dish as the foundation for the dinner and the contributions from other members built on the foundation and enhanced it with complementary contributions. On the other hand, in the case of the stone soup, the contributions of the villagers were cooked together (or integrated) to form one final dish (the soup), which everybody consumed.

These similarities and distinctions are a good analogy for the two types of the Orchestra model of network-centric innovation. As you recall, the Orchestra model involves a group of firms coming together to exploit a market opportunity based on an explicit innovation architecture that is defined and shaped by a dominant firm. There are three important concepts in this definition: dominant firm, innovation architecture, and network members. However, based on the role played by the dominant firm, the functions served by the innovation architecture and the nature of contributions made by the network members, the Orchestra model takes on two different forms:

• The Orchestra-Integrator model. This model resembles the stone soup scenario. A dominant firm (or network leader) defines the architecture for the core innovation and the network members contribute the different components or elements that make up this core innovation. The network leader then integrates the different contributions or components to build the core innovation and then market it.

• The Orchestra-Platform model. This model resembles the potluck dinner scenario. A dominant firm defines and offers the basic architecture, which then becomes the platform or the foundation for the other network members to build on through their own complementary innovations. These complementary innovations extend and/or enhance the reach and range of the basic architecture or platform.

In this chapter, through detailed examples we describe the two types of the Orchestra model including the different types of players (or innovation roles) and the network management systems. We start with the Orchestra-Integrator model. An excellent illustration of this model is the development of the Boeing 787 Dreamliner.

The Orchestra-Integrator Model: The Case of the Boeing 787 Dreamliner

The 787 Dreamliner project was officially launched by Boeing on April 26, 2004. The 787 is designed as a family of airplanes in the 200 to 300 seat class and represents Boeing’s entry into the mid-sized, long-range commercial jet market.¹ The first delivery is scheduled for May 2008. The 787 is a big bet that Boeing is placing to win back dominance of the $60 billion jetliner market from Airbus SAS.²

The new 787 incorporates several radical advances in terms of basic design and technologies as well as facilities for passengers and crew. It uses a new lightweight carbon composite as the material for building much of the plane.³ The use of the lightweight material is supposed to translate into at least 20% reduction in fuel consumption compared to that of jets of similar size. The 787 will allow the use of two types of engines—the GE Next Generation (GEnx) engine and the Rolls Royce Trent 1000 engine.⁴ In other words, the 787 offers a standard engine interface and a new plane can be fitted with either of the two types of engines without making any other changes elsewhere, thereby providing more flexibility for carriers.

The interior design of the 787 incorporates several innovative features for crew and passengers. For example, the 787 will be an “e-enabled” airplane—it will have electronic flight bags (EFB) to deliver electronic charts, manuals, and reference data to flight crews; a satellite-based communications system to provide Internet access to passengers; and wireless networks for maintenance access as well as for in-flight entertainment. Another interesting feature relates to cabin pressure and humidity. The cabin of the 787 will be pressurized to 6,000 feet altitude instead of the conventional pressurization to 8,000 feet altitude. The higher air pressure is supposed to translate into a more comfortable ride, particularly during long flights. Similarly, the cabin humidity will be maintained at a higher level—between 20% and 30% rather than the 10% humidity that is typical of other airplanes. The 787 can maintain such higher humidity because the carbon composite used to fabricate the structure does not corrode when exposed to moisture. The higher cabin humidity will also contribute to a more comfortable ride for passengers.⁵

Boeing’s former CEO, Harry Stonecipher, remarked in 2004 that the new 787 will be “a game changer.” Alan Mulally, the former CEO of Boeing Commercial Airplanes, noted that the new 787 “will allow us to continue to set the standard for commercial aviation in the second century of flight.”⁶ While both Stonecipher and Mulally were referring to the aforementioned new technologies and features of the airplane, their comments also captured the innovative way in which Boeing went about designing and building this new aircraft.

Indeed, the story of the 787 Dreamliner is also very much a story of “innovating innovation” in the commercial aviation industry—how Boeing redefined the very process by which it developed new airplanes and collaborated with a network of global partners.

Elements of Boeing’s Network-Centric Innovation Strategy

In building the 787, Boeing made a radical departure from its traditional design and development strategy. The 787 program started with the expectation that any external partner that had the responsibility to build a part of the airplane would also be responsible for designing it. This was a major point of departure from previous programs, where Boeing did most or all of the design work and other companies then built the airplane.⁷ The 787 project was conceived at the very outset as a highly collaborative innovation program conducted with a network of partners.

Boeing assembled a set of global partners whom it could trust with the process of creating entire sections of the plane, from concept to production. The global partners consisted of companies from all over the world, including Japan, Australia, Italy, and Canada. Each global partner was selected based on a strict set of standards as each company would be assuming responsibility for a higher level of systems and structure—and bringing in their own set of sub-contractors and suppliers.

The design and development tasks were not just outsourced to these partners. Instead, partners made financial investments in those tasks. As Thomas Pickering, Boeing’s senior vice president for international relations noted, “We said, ‘let’s spread the risk and spread the benefit’ ... they get the advantages but they also carry the burden.”⁸ Specifically, each partner was supposed to invest in the project by paying the upfront cost related to design and development. With approximately $10 billion required for the development of the new jet, partners were responsible for investing close to $4 billion—a significant commitment. They were expected to absorb this non-recurring cost of development—in other words, they were not permitted to include those costs in their pricing. And, this was built into the agreements with individual partners. Contracts had common provisions that reflected the central theme of Boeing’s network: “What’s good for one is good for all.”

Boeing’s network also includes its customers, although their role is largely limited to providing ideas and suggestions in the product definition phase. Boeing conducts a large-scale meeting with a number of its customer partners (airlines from all over the world) called the Progress Summit, which features open discussions on customer requirements and concepts for standardizing and simplifying the 787 design.⁹ The summit is also a venue for Boeing to update its customer partners on the progress of the 787 development project. Each partner (or network member) in the 787 project is directly tied to Boeing, although operationally each one is also linked to one another. The innovation network for the 787 project is highly centralized, with Boeing in the center and the global partners around it.

The development of the 787 follows a three-phase process: conceptualization, joint development, and detailed design. The conceptualization phase started in early 2003 with the appointment of the core 787 project management team within Boeing. Michael Blair, a 24-year Boeing veteran, was appointed as the senior vice president and general manager of the 787 program. Other members of the team included Walter Gillette, another Boeing veteran who is considered the technical and intellectual inspiration for every Boeing jet since the mid-1970s.¹⁰ Gillette was to be the creative force behind Dreamliner, too. During the conceptualization phase, the internal Boeing team interacted with a number of external entities including customers (airlines), suppliers, technical experts, and market experts to identify and define the basic new product concept. The business case for the new 787 was clarified. Boeing also entertained innovative ideas for the systems and the structures from the external entities. For example, the potential for using composites as the material for the airplane structure was explored and a number of alternative materials were tested. After the product conceptualization phase was over, it was time to define the basic structure of the 787.

The second phase, the joint development phase, was the most crucial as it would define once and for all the basic configuration of the new plane. As Michael Blair, general manager of the 787 project noted, “Firm configuration means the airplane’s structural, propulsion, and systems architectures are firm or defined.”¹¹ For example, specifying the sweep and size of the wings, the exact size of the fuselage, tail, engines, and all other major components of the airframe. In other words, this phase was when the basic (innovation) architecture would get defined.

Although Boeing will have the final say in all aspects related to the final configuration, the involvement of the global partners is critical as they along with Boeing start assuming risks (related to the product development) right from this stage onwards. Boeing and its partners spent the next year or so defining the 787 architecture.

The 787 program reached the final configuration on September 15, 2005.

The joint development phase not only defined the 787 configuration but also specified the way in which the design job would be divided among the global partners as well as the standards or metrics by which the design would be evaluated. The design work for the entire structure of the new jet was divided into six “integrated assemblies” or work packages. Each of these large components was designed from the bottom-up by one or more of the partner firms.

Boeing took the responsibility for the detailed design and development of only around 35% of the plane’s structure. This included the vertical fin, flight deck, fixed and movable leading edges of the wing, parts of the forward fuselage, and wing-to-body fairing. The rest of the structure was the responsibility of a set of global partners that included Mitsubishi Heavy Industries, Fuji Heavy Industries, Alenia Aeronautica, Vought Aircraft Industries, Goodrich, and Kawasaki Heavy Industries (see Figure 5.1).

Figure 5.1. The distribution of the 787 design and development

“Who makes the parts and where the engineering jobs are,” Reporting by Dominic Gates, Graphics by Mark Nowlin. Seattle Times, September 11, 2005. © 2005 The Seattle Times Company. Reprinted by permission.

For example, Mitsubishi Heavy Industries was responsible for the main wing box whereas Fuji Heavy Industries designed and developed the center wing box and also integrated the wing box with the main landing gear wheel well. Kawasaki Heavy Industries provided the fuselage section between the wing and the cabin, the main landing gear wheel well, and the main wing fixed trailing edge. Alenia in Italy designed and developed the 64-foot-wide horizontal stabilizer and partnered with Vought Industries to build the aft fuselage.

The global partners were asked to “design and build to performance”—instead of giving each external partner detailed designs that they had to implement, they were now given the broad architecture and the performance standards. The innovation tasks needed to get to these performance standards were now the sole responsibility of individual global partners. Thus, the final configuration and the associated performance standards became the set of shared goals and objectives of the network of global partners.

After the firm configuration was defined, Boeing and its partners started on the third and final phase of innovation—the detailed design of the major components. Each partner knew the expectations regarding not only their own contributions (that is, the large components) but also the other partners’ contributions. Such a shared understanding of the goals served to bring coherence to the detailed design and development activities of the different partners located in different parts of the world.

The global partners were responsible for the detailed design as well as the final production of the components. The different components of the 787 would then be brought together at Everett, Washington for the final assembly.

The target for the final 787 assembly in Everett is three days. However, Boeing plans to bring down the final assembly time to two days by 2011: that is, a new 787 will roll out every two days!¹²

The Role of Boeing and Its Partners in the 787 Program

Let us now examine the roles that Boeing and the other partners play in the 787 program. Boeing developed a master design that defined the general contours of the plane, however, the specific design tasks of the different parts were left to individual partners. In fact, network partners were responsible for more than 70% of the overall design work. More importantly, partners were given the responsibility to design and develop some of the most important structures of the airplane. For example, the Japanese partners developed the entire wing section of the 787. As Boeing’s Thomas Pickering noted, “This is the first time we have ever put the full wing ... into the hands of a partner.”¹³ Indeed, no Boeing plane has ever flown on foreign wings and the company has always held onto such critical knowledge (the “crown jewels”) related to building airplanes.¹⁴

Thus, in building the 787, Boeing made a radical shift in its own role—in the words of Scott Strode, Boeing’s vice president of airplane development and production, Boeing made a shift from being a “manufacturer” to being an “integrator.” As Strode notes, Boeing’s role as integrator requires it to shoulder “a broader range of responsibilities that include assembling the partner team and making work assignments, establishing clear expectations, deciding on common tools and processes, and making the critical technological decisions.”¹⁵

Such a shift in roles is a part of a master plan—the Boeing 2016 Vision—to change the company from a manufacturer to a designer and assembler of high-tech airplanes.¹⁶ And it is a change that Boeing’s partners understand very well. Vern Broomall, vice president of quality and engineering at Vought Aircraft Industries, one of Boeing’s partners in this effort, notes, “There is a real difference in the business approach—with Boeing taking the role of the integrator and the partners taking the responsibility for the major pieces.”

Boeing was also the central decision maker in the network. Although each global partner had a lot of autonomy with regard to the design of their individual components, there was still a need for a single decision maker on important design and development issues. Those decisions were made by Boeing management. Boeing’s leadership role is succinctly captured by Steve Shaffer, vice president of Global Partners for Boeing Commercial Airplanes: “We share information with our partners, we listen to them, and we influence each other. But at the end of the day, there’s no doubt that Boeing is leading.”¹⁷

Boeing also makes sure that other partners’ roles are clearly defined and made explicit. As Vought’s Broomall noted, “We’ve never done a project before where the roles and responsibilities are as clear and consistent as they are on this one.”¹⁸ They had better be. Vought is designing two large sections of the fuselage, which then has to be integrated with the components that are being made by Alenia Aeronautica, another partner, in Italy. As Broomall continues, “We (Vought) work directly with the Italian (company), and have an excellent relationship with them, while Boeing facilitates the work for all of us.” Thus, while the network partners build on each other’s design ideas, Boeing has to not only facilitate such cumulative knowledge creation, but also orchestrate the distributed innovation activities.

Boeing’s role as the integrator and its limited involvement in the detailed design and development also meant placing different emphasis on its other tasks. For example, as Walt Gillette (787 program vice president of engineering, manufacturing, and partner alignment) notes, assuming the role of the integrator allowed Boeing to concentrate more on attending to “the voice of the customer” through the product development phase.¹⁹ In this role, Boeing could focus its efforts on maintaining the integrity of the overall product vision vis-à-vis the dynamic external environment and market needs.

What was the role of the global partners in the network? Their primary role was that of an innovator—to help Boeing define the overall configuration of the airplane and to innovate in the design and development of the individual components. They were also responsible for selecting and overseeing the second- and third-tier partners (or suppliers) in the network—a task traditionally carried out with the involvement of Boeing. In fact, the 787 project will be the first time an entity other than Boeing will control the selection of the second- and third-tier suppliers in a Boeing commercial aircraft program.²⁰

Managing Collaboration Among Partners

Coordinating the work on three continents of the partner firms raises some critical challenges related to information flow and communications. The globally dispersed partner companies needed to converse in real-time using the same vocabulary, interpret the design information gained from others, and integrate that knowledge with the design of the components that they themselves were responsible for. In other words, what was needed was a system for collaborative design that facilitated the dialogue among the companies, provided a common vocabulary, and allowed rapid transfer and integration of design knowledge. And as the leader of the network, Boeing had the responsibility to provide such a knowledge-management infrastructure.

Boeing addressed this challenge by creating a sophisticated virtual Global Collaboration Environment for its partners to share information and collaborate on design on a real-time basis. The Global Collaboration Centers at Boeing and in each of the partner locations were linked to one another for live video-conferencing (with encrypted transmission for additional security).

The end solution brought together a variety of technologies and tools. For example, Boeing partnered with the Dassault Systems, the French software company, to put together a suite of Product Lifecycle Management tools to support the collaborative design and development tasks. This includes CATIA (V5) the computer-aided design tool; DELMIA, the manufacturing solution; and ENOVIA, the engineering interface. The global partners also made use of collaboration tools available through Exostar, an online trading exchange for the aerospace industry. Similarly, database and communication tools from Radiance Technologies were used to transmit high volumes of data among partners. In addition, a visualization application developed by Boeing allowed global partners to conduct real-time design reviews without any lag time for the models to load.

These tools helped create a highly collaborative environment. The facilities for real-time interaction facilitated and promoted continued dialogue among the partner firms. Further, the configuration or the architecture of the airplane and the design interfaces were embedded in common databases that were shared by all partners. And many of the tools employed a standardized engineering design language to facilitate interpretation and integration of design done by the different members.

Steve Shaffer, vice president of Global Partners for Boeing Commercial Airplanes, noted that the 787 project emphasized a “situational awareness” among the partners.²¹ Each partner was kept continually aware of the design activities underway in other partner firms as well as the impact of the external environment on the business and technological assumptions. This “situational awareness” or a shared world view is one of the cornerstones of network-centric innovation. In the case of the 787 program, the Global Collaboration Environment facilitated building and maintaining such situational awareness throughout the lifetime of the project.

Building a Trust-Based Environment

Formal contracts signed between Boeing and each one of the partners explicitly outlined the nature of collaboration and the expectations regarding the outcomes. In addition, Boeing also invested heavily in developing a trust-based environment in the network. As the global partners soon realized, it is a very complex undertaking to just get everybody to come together as a team and agree on technical matters, let alone to integrate the different cultural mindsets. A key ingredient of success is the trust and the understanding of one another’s work processes and culture that evolves over time.

Consider the development of the wing box, which is the responsibility of Japan’s Mitsubishi Heavy Industries (MHI). The wing for the 787 will be the largest composite structure ever built for a commercial aircraft. In developing and testing the wing box, MHI had to interact and coordinate closely not only with Boeing but also with other partners in the network. When the wing box testing came up during development, MHI had a different approach for prototyping and material testing than Boeing. The wing box test article measures roughly 18 feet at its widest point and is half the length, approximately 50 feet, of the entire wing. The use of new materials created two challenges: the challenge of designing a new component and the challenge of understanding the new material that will be used to produce that component.

As Dan Smith, Boeing’s 787 wing test and technology LCPT leader noted, “We took some time early in the (design and development) process to build the trust between Boeing and MHI.”²² For example, Smith called upon both the MHI and Boeing teams to complete the initial development of the equipment prototype in six weeks—Boeing had the job of developing the prototype while MHI had the task of building the tooling to support the testing of the prototype—and set up a “beer/sake challenge.” If MHI met the schedule and Boeing did not, the Boeing team would buy sake for MHI team members, whereas if the reverse was the case, MHI would buy beer for the Boeing team. Such team-building challenges help to build a level of trust among partner firms. As it happened in this case, both teams met the timeline and so everybody had both beer and sake. And more importantly, in the process both teams gained better appreciation and trust of each other’s capabilities and expertise.

Such trust and shared understanding of the unique work and cultural contexts of the partner firms have to be developed across all members of the network, not just between two partners. This requires adopting new perspectives on risk sharing and information sharing. Steve Huggins is a senior vice president of strategy and business development in Goodrich Corp, a key partner of Boeing. Huggins noted that component providers used to keep their strategies and information to themselves, like poker players holding cards close to the vest. But such an approach went against the goals and objectives of the 787 program. As Huggins commented, “The degree to which our companies share forecasts and visions of the future today is more like talking with a colleague than telling the ‘boss’ what you think they want to hear.”²³ Such open sharing of information and ideas contribute to the development of trust and higher level of shared world view that is fundamental to the success of network-centric innovation.

The flip side of the trust developed in the network is the long-term risk that Boeing might be assuming with regard to the critical knowledge and technologies that it will be sharing with its partners in the 787 development. For example, technological knowledge related to wing design is considered the crown jewel of aircraft building. In the 787 project, the Japanese companies that will be involved in the wing design have their own long-term agenda in the aviation industry.

For example, Kawasaki has future plans to enter into the commercial aviation industry independently. Similarly, MHI plans to use the knowledge it gains from the 787 project related to the new composite technology to fuel its own future plans in this area. Junichi Maesawa, executive director of MHI, notes that the 787 “is a cornerstone for Japan to become a stand-alone aircraft manufacturer in producing a 30 to 50 seater aircraft in a few years.”²⁴ So will Boeing’s collaboration with these companies lead to knowledge spillover and create new competitors in the future? That remains to be seen.

Comparisons with AIRBUS A380 and Boeing 777 Projects

In sum, the 787 Dreamliner exhibits all the key characteristics of the Orchestra-Integrator model of network-centric innovation. Table 5.1 captures the essence of the model vis-à-vis the network-centric innovation framework presented in earlier chapters.

Table 5.1. Boeing’s 787 Dreamliner Network

Before concluding this discussion, it might also be useful to highlight Boeing’s unique approach in the 787 project by comparing and contrasting it with the development strategies related to two other projects: the development of Boeing 777 and the development of a competing aircraft by Airbus—the Airbus A380 mega jumbo. Table 5.2 compares these three projects.

Table 5.2. Comparison of Boeing 777, Boeing 787, and Airbus A380 Development Approaches

In developing the wide-bodied jet airliner 777, Boeing followed the traditional “build to print” approach wherein suppliers were required to manufacture to fit the detailed design requirements specified by Boeing. The 777 involved significant technological achievements. However, many of these advancements came from Boeing. External suppliers played a very limited role in the development of the 777. For example, the Japanese companies contributed to the building of less than 20% of the 777 components. Further, unlike in the 787 project, much of the most closely guarded technologies and design components (for example, wing design) remained with Boeing. Also, in the 777 project, the suppliers assumed very limited risk—related to the technologies or to the investment needed for new design and manufacturing facilities.

The development of the A380 reflects a more network-centric approach, but it falls significantly short of Boeing’s approach in developing the 787. Why do we call it a network-centric approach? Technically, Airbus S.A.S. is a single corporate entity based in Toulouse, France. However, in reality, its four divisions located in Britain, France, Germany, and Spain still operate as four distinct companies that trace their roots to the four European national aviation firms from which Airbus took its birth. Indeed, in early 2006, former Airbus CEO Christian Streiff noted that “(Airbus) is still in part a juxtaposition of four companies.” The company is “terribly balkanized” with the four divisions often prone to national political forces and harboring cross-border jealousies.²⁵

The major design and development tasks of the A380 project were spread across these four distinct divisions of the company, with Britain in charge of wing design, Germany in charge of cabin outfitting, Spain responsible for the tail, and France responsible for the final assembly. In addition, a number of external suppliers located in Europe and in other parts of the world were also involved in the design and building of smaller airframe subassemblies. Thus, the A380 development followed a network-centric approach although the design responsibilities of external suppliers were limited compared to the 787 project. However, as in the case of 787, the suppliers of Airbus A380 were also required to contribute to the development costs—to the tune of approximately $3.1 billion.²⁶

What do these examples show about the implications of following the Orchestra-Integrator model on innovation outcomes? A comparison of the 777 and the 787 indicates the significant reductions in time, development of innovative technologies and materials, and reduction of overall development cost. Vought’s Broomall notes, “We have probably taken more than one-third to one-half of the time out and perhaps 50 percent out of development cost versus historical methods (as followed in 777).”²⁷

On the other hand, the case of A380 indicates the central importance of the leadership role played by the dominant firm (that is, the Integrator role). For example, in July 2006, Airbus announced significant project delays that were attributed to problems with the internal wiring designs of the A380. Specifically, wiring that was designed and produced in Hamburg failed to fit the final assembly requirements in Toulouse, France. Investigations showed that this was due to the use of incompatible design software. A detailed analysis of the A380 project showed that while the design and development tasks were distributed across the different divisions or entities, there was nobody to play the critical leadership role of the Orchestra-Integrator. Another issue in the case of A380 was related to the lack of a common knowledge-management system. The PLM software tools used for the development of A380 were outdated and had limited capabilities to support virtual collaboration among the different network entities (for example, the tools did not support creating a digital mockup of the A380). Such lack of knowledge-management capabilities along with highly deficient network orchestration (or network leadership) led to limited shared awareness or world view of the project among the different partners and failure to detect design flaws early enough to avoid project delays and cost overruns.

These and other examples indicate the importance of three broad themes that underline the success of the Orchestra-Integrator model:

• The firm playing the Integrator role has to provide strong leadership to the innovation activities—leadership that should be evident in envisioning and clarifying the innovation architecture, facilitating and coordinating the innovation activities of the network partners, and integrating and bringing to market the innovation.

• The key network partners involved in the design and development should be sufficiently invested in the project—in other words, the dominant firm should ensure that the partners share in the risks as well as in the rewards related to the innovation.

• The lead firm should also establish an environment that supports building trust-based relationships and the ability to rapidly share knowledge thereby ensuring high “situational awareness.”

Let us now consider the second form of the Orchestra model—the Orchestra-Platform model.

The Orchestra-Platform Model: The Case of Salesforce.com and AppExchange

In Chapter 2, “Understanding Network-Centric Innovation,” we briefly introduced Salesforce.com (the customer relationship management solution provider) and its AppExchange forum as an example of a network-centric innovation initiative. More specifically, as we will show here, Salesforce.com is a good example of the Orchestra-Platform model of network-centric innovation.

Salesforce.com—Journey from a Solution Provider to a Platform Provider

Founded in 1999 and based in San Francisco, Salesforce.com is one of the leading software providers in the rapidly growing Customer Relationship Management (CRM) market. The company’s core offerings focus primarily on sales force automation, marketing automation, partner relationship management, and customer service and support automation. The sales force automation services help companies to establish systems and processes to manage customer accounts and to track sales leads, share sales forecasts, and coordinate other tasks with the sales force. The marketing automation services enable companies to manage marketing campaigns. The customer service and support automation services allow companies to track, manage, and coordinate their interaction with existing customers in various areas (for example, requests for repairs, advice about products and services, complaints about faulty goods, and so on).

The unique aspect of the company’s core offerings is their availability as “on demand” services that client companies can access through a regular Web browser over the Internet. The market for such on demand or Web-delivered software (also known as software as service) is expected to grow rapidly in the next decade or so—for example, one report estimates that by 2011, 25% of the enterprise software market will be on-demand.²⁸ In the eight years since its birth, Salesforce.com has grown rapidly, riding on the increasing popularity of its particular vision of Web-delivered software. As of July 2007, the company had approximately 32,000 customers using its software and approximately 646,000 paying subscribers worldwide.

Despite its success with the core set of CRM products, Salesforce.com plans to be more than just a CRM solution provider. Starting in 2003, it gradually started evolving into a platform leader. Specifically, the company defined a foundational on-demand architecture that will help external developers to build applications that extend the scope of the company’s core offerings. This shift to a platform provider is intended to greatly expand the company’s reach into applications areas beyond its customer relationship management roots. Instead of creating and offering all such applications by itself, the platform strategy enables Salesforce.com to harness the innovativeness and the capabilities of external developers and transform itself into an all-purpose enterprise computing infrastructure provider.²⁹

As the company’s founder Marc Benioff notes, “The strategy is to let 1,000 flowers bloom and look for innovation.”³⁰ The company hopes to get external partners to build applications that are integrated with the company’s CRM solutions and mimic the embedded experience of the Salesforce.com user interface, thereby making them an application within Salesforce as far as the user is concerned, and allowing Salesforce’s product portfolio to grow without the company building all of them by themselves.

Salesforce.com’s Technology Platform

The on-demand technology platform that the company has developed and made available to external developers constitutes several components. First and foremost, it includes the core sales and marketing application and the customer service and support application. In addition, the platform also includes an on-demand operating system, an on-demand programming language, an integration platform, and on-demand application sharing service.

Consider Apex, an important element of Salesforce.com’s technology platform. Apex is a new Java-like on-demand programming language that the company has made available to external developers and customers. Applications built using the language can be made available as a Web service and accessed using XML and SOAP standards. Apex code runs natively on the Salesforce.com hosted server infrastructure and as such it is faster and more powerful than other languages. This enhanced functionality opens up new possibilities for external developers. Further, applications developed using Apex can interact with the access and manipulate data through the standard application programming interfaces (APIs) the company has made available to its core CRM applications.

Salesforce.com’s network partners can use Apex to build entirely new applications or solutions and integrate them with the flagship CRM application itself. Apex is derived from the same technologies that the company uses in its internal development activities. As such, the company’s current customers can also use the Apex language to customize core features and functions of Salesforce’s on-demand applications. Apex enables external developers and clients to create or modify applications in a controlled manner with all code running off the Salesforce platform itself.

Salesforce.com’s technology platform also includes other elements that enhance the overall capabilities and range of applications that can be developed. For example, it includes a data relationship API for accessing and managing complex data relationships, real-time messaging and integration for notifying other applications or middleware of business events in Salesforce, and an Ajax toolkit for linking Salesforce applications in “application mash-ups” with other systems such as Google Maps.

The company is clear about its motives behind opening up and offering such a technology platform. “We have a vision for millions of applications on demand,” notes Adam Gross, vice president of developer marketing, “but as a company we choose to build only one class of applications called CRM applications. Apex and other elements of our platform will give our partners unburdened freedom and the capability to develop an entire universe of on-demand applications ... ranging from HR and inventory management to transactional applications like ecommerce.”³¹ Indeed, in releasing Apex, the company wants to have a much broader impact on the enterprise software arena—specifically, it wants Apex to have the same effect on the ballooning market for on-demand or Web-delivered business software as Java did on the consumer Web in the 1990s.

Thus, unlike in the case of the Orchestra-Integrator model, here, the dominant firm’s objective in defining the technology architecture is not to specify the innovation components that other network members should develop and contribute. Instead, the “on-demand” architecture serves as a foundation for network partners to build complementary applications that extend the reach and range of the company’s suite of products.

However, pursuing such an innovation agenda requires more than just defining a technology platform. It requires playing the role of a platform leader in the network to promote and facilitate the complementary innovation activities of its network partners. In the case of Salesforce.com, the vehicle for exercising such a leadership role is the AppExchange developers’ network or forum.

AppExchange Network

AppExchange is a forum that the company has created to serve as a common ground for all the different members of its network to come together. These members include independent software developers, customers, and other technology partners. The AppExchange forum serves multiple objectives ranging from providing a marketplace for complementary solutions developed by external developers to facilitating the sharing of knowledge related to the technology platform.

The primary participants in Salesforce.com’s innovation network are the independent software developers who create applications based on the company’s technology platform. Their role is that of a “complementor”—building applications that complement the core CRM solution. The nature of the innovation pursued by the complementors is limited only by the specifications of the technology platform and the imagination of the developers and the on-demand community.

To get a sense of the nature and diversity of the applications available on AppExchange, consider the following two examples. Envox Worldwide, a provider of voice solutions, has created a new application called Envox PhoneLink. The application works on top of the CRM solution and enables businesses to add screen pop-ups and click-to-dial capabilities to their customer contact centers.³² Another external developer, DreamFactory Software, makes add-on application components that extend the basic CRM features by including teamwork automation and management capabilities—specifically, project management, collaborative calendaring, and document sharing capabilities.

AppExchange has two objectives:

• To enable the company to make available the platform technologies as well as the knowledge required to use those technologies. As the platform leader, Salesforce.com has the sole responsibility to define and lead the evolution of the platform. AppExchange allows the company to maintain its communication with the developer community—educating them about new developments in the platform, capturing the community’s emerging needs and issues, and facilitating the overall use of the technologies.

• To serve as a forum for network members to share or distribute applications built on the platform, making it a marketplace for complementary applications. It offers the AppExchange directory wherein external developers can list their offerings. Other network members (for example, existing users of the CRM solution) can browse the directory, select an application that interests them, and test drive or install that application for their own use.

As of July 2007, the AppExchange directory listed about 600 such on-demand complementary applications ranging from financial solutions to human resource management and inventory management solutions. And, 7,400 out of the company’s 32,000 customers had installed at least one application from the AppExchange directory.³³ While some of these applications are offered free of cost, others need to be purchased from the external developer. The directory makes it easy for finding, testing, and installing the applications—in very much the same way you would browse the iTunes Web site to sample and download or purchase songs. Thus, AppExchange serves as an online service for sharing business applications built on the company’s technology platform.

The company calls its AppExchange an “eBay for on-demand computing”³⁴—a community forum that gives an opportunity for external developers to create and offer an “ecosystem of services” that merge well with the company’s own core solutions. And, extending the eBay analogy, the company expects viral growth—as AppExchange adds more products, more buyers show up, and in turn, more developers.

Governance of AppExchange

As is the case with eBay, offering such a forum for external developers and partners requires Salesforce to provide the appropriate level of governance and monitoring. Several elements make up the governance on the AppExchange network. The company uses the following formal and informal mechanisms to govern the AppExchange network:

• Registration: Only registered external developers or partners are allowed to participate in the AppExchange directory service. Thus, while registration is free, it enables the company to maintain a “gated” network that provides the first level of governance.

• Certification: All the applications that external developers want to share or distribute through the AppExchange forum have to undergo an extensive review and certification process from the company. The certification ensures that the application meets predefined standards regarding security, reliability, and quality. The certification process incorporates a rigorous 300-point test plan that includes a security audit, integration and functional design review, functional testing, and an audit of a reference customer. The last part—customer audit—aims to incorporate customer feedback in the certification process. After an application has successfully passed the certification tests, the company awards an “AppExchange Certified Application” logo to the developer for that application.

• Quality Ratings: Salesforce.com uses its user community to evaluate the quality of the applications. As in the case of eBay, the community acts as the judge of the quality of its members’ performance. AppExchange community members can rate an application on a 5-point scale and the average ratings of all customers are shown on the AppExchange directory. Community members can also provide detailed comments and critique on applications.

• Platform Monitoring: Salesforce.com also monitors the way its technology platform is used by external developers so that it can protect the integrity of the platform and the solutions based on it. Solutions from external developers can pose the risks of complexity and broken applications and work against the company’s norms and values regarding ease of use and trustworthiness. To head off this risk, the company has created measures to guard against developers using Apex to inadvertently wreak havoc with its Salesforce.com deployments. For example, when Apex code is being executed on its on-demand platform, the application is constantly monitored for what it is doing and what resources it is consuming. The company’s monitoring of hosted complementary applications from external developers does not stop with the certification process. Rather, it continues during the execution too.³⁵

Salesforce’s Other Initiatives as Platform Leader

Salesforce.com has adopted several other initiatives in recent years to enhance the nature and quality of the innovation outcomes in the network. Let us take a brief look at some of these.

IdeaExchange

Salesforce.com’s customers are also participants in the innovation network. They play the role of an “ideator” by serving as the source of new product or product improvement ideas. The company has created a separate forum called the IdeaExchange to facilitate the dialogue between active subscribers (customers) and the company on product- and technology-related issues. Customers can visit the IdeaExchange and suggest product improvement ideas as well as new product concepts to the company. Comments and suggestions on the forum are continuously monitored by the company to identify promising ideas for implementation. Customers can also weigh in on other customers’ ideas by “promoting” them on the IdeaExchange forum—that is, indicating that the idea is useful, relevant, and important. Ideas that are promoted the most get the company’s attention and are actively considered for implementation. The forum also enables customers to interact directly with the company’s product managers. Thus, the IdeaExchange is a mechanism for Salesforce’s subscribers to actively participate in the product innovation in a way that will benefit them the most.

Most importantly, the forum also serves as an idea “garden” for the external application developers. In other words, many of the ideas suggested in the forum relate to complementary functions or products—functions that customers would like to have but are not included in the core suite of products from the company. And as such, they indicate the potential market for specific complementary applications. The company also uses the IdeaExchange to communicate with its customers and other stakeholders about its technology and product development plans. As Kendall Collins, senior vice president of the company notes, the IdeaExchange provides a transparent roadmap of the company’s development pipeline and the customer demand for new applications and components.³⁶

Co-Marketing and Value Appropriation

AppExchange is a marketplace for complementary applications. External developers can market and trade their applications to potential customers. As such, it serves as a worldwide market for on-demand applications. However, AppExchange is not the only value appropriation vehicle for external developers. Salesforce.com also takes a more active role in marketing external developers’ applications to its customers.

For example, after an application has gained the company’s certification, the external developer can partner with the company and map out co-marketing plans—event sponsorship, paid placements on AppExchange, and so on. In addition, Salesforce’s own internal sales team will actively promote specific complementary applications based on the needs of its customers—in essence, external developers can utilize the company’s internal marketing and sales infrastructure to promote and market their complementary applications. In many of these opportunities, the synergy between Salesforce’s CRM solution and the external developer’s complementary application is leveraged to enhance the overall “value” appeal to the customers. If a sale goes through, the external developers’ share of the sales proceeds is channeled through the company.

Other Partner Alliances

Other technology companies are also key partners of Salesforce’s innovation network. They include major device manufacturers and security, integration, and computer telephony integration companies. These companies offer complementary technologies that the company can leverage to develop customized solutions for its customers in specific industry niches.

Salesforce brings together these companies to support and promote specific aspects of its technology platform. For example, the company has formed the Apex Alliance to promote Apex, the on-demand programming language component of its technology platform. The Apex Alliance incorporates several of Salesforce’s technology partners including Accenture, Adobe, Business Objects, Cingular Wireless, Dell, Deloitte, ExactTarget, Palm, Research In Motion, Satyam Computers, Siemens, and Tata Consultancy Services.

Such forums and alliances serve as a mechanism for the company to share knowledge about its technology platform and to identify opportunities for its external developers and partners to exploit the platform in specific application areas. The alliances also enable the company to signal the commitment of other industry leaders to its technology platform, thereby enhancing its overall status in the market and inducing more external developers to join the network.

AppExchange Central Business Incubator

We mentioned earlier that Salesforce plays an active role in promoting and marketing the complementary applications developed by its external partners. In late 2006, the company announced a much more ambitious initiative, called the AppExchange Central Business Incubator, to cultivate, nurture, and promote the innovation activities of its complementary application developers.

AppExchange Central is essentially an incubation program for partners building applications for AppExchange. Salesforce will invest in creating a physical infrastructure to house its fledgling partners. The incubator will also house Salesforce technical staffers ready to assist in AppExchange application development. The first such AppExchange Central incubator opened in January 2007 in San Mateo, California, near the company’s San Francisco headquarters. Partner companies can rent space in the facility for about $20,000 a year, which also includes the cost of access to Salesforce’s technical and business resources to help bring products to market. The company plans to set up more such incubators in other locations, including Tokyo, London, Bangalore, and Singapore.³⁷

AppExchange incubators are designed to provide entrepreneurs (or external developers) with a package of business services aimed at compressing the development timeline and the go-to-market costs for the incubator companies. These services include access to the Apex programming language and other components of the technology platform, technology infrastructure, product development, sales and marketing support, fundraising, and business development assistance.

The AppExchange incubator represents the very active role that Salesforce expects to play in growing its innovation network. It will not only identify potential external partners but also invest resources in assisting them to develop and get products to the market. In turn, the company expects its incubator strategy to enhance the overall demand for its technology platform and the core suite of CRM products.

The incubation centers also represent another opportunity for the company—it would likely provide a funnel of acquisition candidates, or applications that the company can cherry-pick for future acquisition.

While platform leaders should be careful about showing an appetite for acquiring its complementary solution providers, in many cases, an acquisition can be a win-win situation. For example, in 2006, Salesforce acquired a tiny company called Kieden that had created an add-on to its hosted services for purchasing and managing Google-driven Web advertising campaigns. The add-on solution that became a part of the company’s core product suite allows marketing and advertising managers to analyze ongoing campaigns by viewing which of the people who click on Google AdWords keywords become sales leads. Kieden, which was a San Francisco-based four-person company, was able to develop a public beta version of the application and launch it on the AppExchange where it clearly demonstrated the overall market appeal of the solution.

The example of Kieden thus shows that Salesforce can harness the innovative power of its community of developers in more than one way—it can nurture the growth of such applications thereby indirectly enhancing its technology platform as well as acquire highly promising solutions and make them part of its core product.

Critical Elements of the Orchestra-Platform Model

In sum, AppExchange represents Salesforce.com’s branching out from a position as a CRM-only company to being a provider of an application platform for all types of on-demand solutions, adding value as a platform company and leveraging the efforts of numerous partners in the AppExchange innovation network. Table 5.3 captures the critical elements of Salesforce.com’s Orchestra-Platform model of network-centric innovation.

Table 5.3. Salesforce.com and the AppExchange Initiative

The case of Salesforce.com as well as other platform leaders like IBM, Microsoft, Intel, and Cisco highlight the central role of the platform leader in orchestrating the innovation activities of the different players in the network.³⁸ By clearly explicating the technology platform, the platform leader provides a structure to the innovation space that directs and brings coherence to the innovation activities of the diverse partners. And, as we saw in our case studies, the role involves three important sets of activities: “seeding” and nurturing complementors and other innovation partners, facilitating and supporting innovation, and providing market delivery and other value appropriation mechanisms. We will come back to these themes later on in Chapter 10, “Preparing the Organization,” when we discuss the organizational capabilities needed to carry out the role of the platform leader.

Conclusion

The two forms of the Orchestra model that we have described in this chapter represent two sides of the same coin.

In both the Integrator and the Platform model, the innovation architecture defined by the dominant firm becomes the context for the network partners to innovate. However, while in the Integrator model, the objective is to constrain partners’ activities and channel their innovative efforts to suit the dominant firm’s vision of the final product or service offering, in the Platform model, the objective is to expand the opportunities for network partners to innovate and build on the platform so as to enhance its overall reach and range.

In both cases, the tricky part is to bring together a diverse set of capable partners who are sufficiently committed to the innovation architecture and to orchestrate their activities in a manner that leads to outcomes that are beneficial to all the network members. In sum, the dominant firm has to create the impression in the network that it is giving its partners the opportunity to be part of its success.