Platform Ecosystems: Aligning Architecture, Governance, and Strategy (2014)

Part III. Dynamics and Metrics of Ecosystem Evolution

Chapter 9. Modular Operators

Platform Ecosystems’ Evolutionary Baby Steps

In This Chapter

• An overview of modular operators

• The role of modular operators

• The SPLIT operator

• The SUBTRACT operator

• The SUBSTITUTE operator

• The AUGMENT operator and its INVERT and ENVELOP special cases

• The MUTATE operator and its PORT special case

• A stylized representation of evolution using modular operator sequences

Modularization of platform interfaces embeds flexibility in the form of real options in their ecosystem. This flexibility is manifested in five discrete operations that can be performed on a platform or an app, and within the ecosystem to evolve it. These discrete steps are called modular operators. Evolution of an app, platform, or the entire ecosystem can be mapped on a timeline with nothing but this small set of modular operators. Think of modular operators as the alphabet—or baby steps—to precisely describe evolutionary paths taken in platform ecosystems. In this brief chapter we describe each of the five operators along with some of their special cases. We subsequently use these operators in Chapter 10 (on platform evolution) and Chapter 11 (on app evolution) to explain how platform owners and app developers can use them to evolve platforms, apps, and entire ecosystems using these five discrete operators.

9.1 An overview of modular operators

Modular operators are a repertoire of discrete actions that can be performed in modularized platform ecosystems. These operators are actions that change the existing structures of platform ecosystems into new ones in well-defined ways (Baldwin and Clark, 2000, p. 129). Complex evolutionary changes in a platform can be understood and envisioned using sequences of modular operators applied successively over time. Modular operators can therefore be iteratively applied to a modularized design to incrementally refine the ecosystem. Modular operators are therefore baby steps representing the trajectories and pathways through which a platform’s ecosystem evolves.

There are five modular operators. Table 9.1 briefly defines each operator, what levels in an ecosystem it applies within and to, and provides a notation for each operator. Figure 9.1 illustrates the operated-upon system before and after each modular operation.

Table 9.1

Scope of Application of Each Modular Operator in a Platform Ecosystem

^aCan be used in monolithic systems as well; all others can be used only within modular ecosystems.

FIGURE 9.1 Before and after the use of each modular operator.

Most operators, with the exception of SPLIT, work only on modular systems, entire “modules” or subsystems (i.e., the platform or an app) at a time as a whole (Baldwin and Clark, 2000, p. 131; Gamba and Fusari, 2009). Therefore, all of the operators can be appliedwithin platform ecosystems, and to the entire platform or entire apps as a whole. Except for SPLIT, they cannot be used within an app or platform unless it is internally modularized, a move that should be avoided for the many reasons, described in Chapter 5 on architectures in Part II of this book. They can, however, be used within a platform or an app once the SPLIT operator has been used on it.

9.1.1 Split

The SPLIT operator involves subdividing a monolithic system into two smaller, possibly modularized subsystems. Applying the SPLIT operator is the only way a monolithic system can be modularized (Gamba and Fusari, 2009). This operator is involved in refactoring of software systems, which is how a monolithic system can be given modular properties. This is the only operator that can be applied to nonmodular/monolithic systems. Splitting a monolithic pre-platform system is often the first step to evolve an existing system into a platform; competition among rival apps arises only after splitting makes app-level substitution possible within the ecosystem of the modularized platform. SPLIT can therefore be applied within a platform or an app, unlike all other operators that can only be applied to a platform or an app as a whole.

9.1.2 Subtract

The SUBTRACT operator applies only to modular systems and involves removing an app or the platform from the ecosystem. Therefore, removing an app from a platform’s ecosystem is an example of a SUBTRACT operation on an app. Similarly, removing the platform from an ecosystem while retaining the apps is the application of the SPLIT operation on the platform. An example of this is the removal of the Android platform from the Android ecosystem and subsequently replacing (the SUBSTITUTE operator) it with the Blackberry Tablet operating system (using emulation). In this example, the subtraction allowed the Blackberry Tablet operating system to exploit the existing pool of Android apps for use with its own platform. However, since apps and platforms are often internally modular though externally modularized, this operator cannot be applied within individual apps or a platform, only to them taken as a whole. Exclusion—by leaving out a selected subsystem—creates a minimal design now with the opportunity to subsequently increase its scope and functionality using the AUGMENT operator (Gamba and Fusari, 2009).

9.1.3 Substitute

The SUBSTITUTE operator involves substitution of a subsystem (i.e., an app of a platform) within an ecosystem with another one. It is usable within an ecosystem but usable only on individual subsystems taken as a whole. It is therefore not usable on systems that are internally monolithic, unless they are first internally modularized using the SPLIT operator. The SUBSTITUTE operator is the key to accelerating evolution in modularized platform ecosystems because it allows one version of an app to be replaced with an improved version, without causing a ripple effect in the ecosystem. It is also key to creating competition among rival apps in platform ecosystems because it allows one app to be swapped out for a different one by end-users. For example, a Web browser in a mobile computing platform can be substituted for an existing one. The substitute operator allows platform ecosystems to evolve through modular recombination (Garud and Kumaraswamy, 1993; Simon, 2002), giving an ecosystem a plug-and-play property with respect to individual apps (its subsystems).

9.1.4 Augment

The AUGMENT operator involves adding a new subsystem—usually an app—that adds new functionality to a platform’s ecosystem without requiring any other change elsewhere in the ecosystem (Gamba and Fusari, 2009). This operator therefore is usable on an app and within an ecosystem. The AUGMENT operator is the primary mechanism for adding new capabilities and giving emergent properties to an ecosystem.

9.1.4.1 Special case 1: Invert

Inversion is the first special case of the augment operator. Inversion is used to subsume into a platform functionality that is widely shared by many apps in the platform’s ecosystem. Such recurring functionality might have emerged after the original system was implemented but is widely used by many apps. Therefore, it meets the criteria for high reusability and low variability, making it a prime candidate for integration into the core platform. Evolutionary theorist Brian Arthur (2009) describes this as the congealing of a heavily used subsystem into a platform. This operator often requires the addition of new interfaces (usually in the form of new APIs) that apps can use to invoke the now-integrated functionality (Baldwin and Clark, 2000, p. 138). Inversion is the opposite of the split operator because it reduces modularity by potentially combining two modularly interacting subsystems into a larger monolithic system. Inversion is the key mechanism through which redundant implementations of common functions recurring and spread across many apps can be consolidated into the platform (Gamba and Fusari, 2009; Kamel, 1987). This reduction in duplication of effort across apps in turn improves the scale economies obtained by a platform’s app developers, increasing the value of the platform to future apps. However, inversion can also wipe out the business of app developers who might have previously specialized in providing the inverted functionality. An example of inversion is iOS subsuming cut-and-paste functionality and system notifications that were required by many apps but absent in the earlier versions of the iOS platform. Paradoxically, inversion speeds up the evolvability of the ecosystem as a whole because it allows any apps that use that common functionality to benefit from improvements in it when that functionality is implemented in the platform itself.

9.1.4.2 Special case 2: Envelop

Envelopment is the second special case of the AUGMENT operator because it involves adding a new module to an ecosystem that replicates the functionality of an adjacent solution or product whose user base overlaps with that of the original ecosystem. This operator is the primary mechanism through which an ecosystem can expand to swallow solutions offered in adjacent markets (Eisenmann et al., 2011).

9.1.5 Mutate

The MUTATE operator involves making a copy of the original system to create a derivative system intended for use in a different application domain. Mutation creates a distinct derivative system, leaving the original intact (Tiwana et al., 2010). The spin-off inherits some properties of the parent system but with a function distinctive from its parent. The mutate operator can be used on both modular and monolithic systems at all levels. Therefore the mutate operator can be used on—but not within—an ecosystem, a platform, or an app.

9.1.5.1 Special case: Port

A special case of the MUTATE operation is the PORT operation, which applies primarily to apps. It can sometimes also be used on a platform. Porting involves replicating the functionality of an app to allow it to function on a different platform from the one for which it was originally implemented. The core functionality of the app remains unchanged but its implementation is unique to the new platform. An example of porting would be implementing the Skype Mobile app originally developed for iOS on the Android platform. The advantage of porting is that the app does not have to be redesigned from scratch for the target platform. However, the implementation often must be done from scratch because of cross-platform differences. There have been attempts to create universally portable “write-once-run-everywhere” software, but they have had limited success. Portability often conflicts with an app’s platform specificity (i.e., the degree to which it can leverage capabilities unique to a specific platform in its own operations). Therefore, universal portability is rarely an attainable goal and is often not desirable given the performance tradeoffs that it often introduces. However, the use of virtual machines (e.g., Java virtual machine and Microsoft’s .NET framework) allows a limited degree of cross-platform portability.

A growth in platform-specific APIs can discourage multihoming and reduce portability. App developers can and often do spread their development costs across multiple platforms, hedge bets on multiple rival platforms than being tied down to one that might end up failing, and also access a larger pool of potential customers. An indistinguishably similar pool of apps on rival platforms reduces platform differentiation. Therefore, it is generally in the interest of app developers to increase portability but in the interests of a platform owner to reduce it. Platform owners can reduce portability by rapidly adding new APIs and platform functionality that differentiates the app on their platform, increasing incentives for app developers to reduce modularization of their app in order to take advantage of the platform’s unique capabilities. App developers in contrast can increase portability by increasing modularity vis-à-vis a platform, relying on virtual machines, and relying less on platform-specific capabilities (instead investing in building their own).

Each of the modular operators can be applied in any sequence, one at a time to a platform, app, and an entire ecosystem. The stylized representation in Figure 9.2 illustrates how the evolutionary trajectory of platform subsystems using the exhaustive set of modular operators described in this chapter can be compactly tracked. We return to these operators in guiding the evolution of platforms and apps, respectively, in Chapters 10 and 11.

FIGURE 9.2 A stylized representation of evolution using modular operators.

9.2 Lessons learned

• Modular operators are five discrete evolutionary actions. Modular operators are a repertory of discrete actions that change the existing structures of subsystems in a platform ecosystem into new ones in precisely defined ways.

• Modular operators can only be applied one at a time. Complex evolutionary changes in a platform can be envisioned using sequences of modular operators applied successively over time, one at a time.

• Modular operators can be used on all types of systems but only within some. All operators can be used on an ecosystem, app, or platform taken as a whole. SPLIT can be applied within a platform or an app.

• The SPLIT operator breaks a monolithic system into two smaller subsystems and can be used to modularize a monolithic system.

• The SUBTRACT operator removes a subsystem from the ecosystem.

• The SUBSTITUTE operator swaps out one subsystem in the ecosystem with another.

• The AUGMENT operator adds a new subsystem to the ecosystem. Its two special cases are the INVERT and ENVELOP operators.

• The MUTATE operator replicates a system to create a distinct derivative system for use in a different application domain. Its special case PORT operator reimplements its functionality in a different platform ecosystem.

• Modular operators on a timeline convey evolution. A stylized representation of evolution using modular operators conveys its evolution trajectory.

The next chapter delves into how platform owners can orchestrate the evolution of a platform.

References

1. Arthur B. The Nature of Technology. New York: Free Press; 2009.

2. Baldwin C, Clark K. Design Rules: The Power of Modularity. Cambridge, MA: MIT Press; 2000.

3. Eisenmann T, Parker G, Van Alstyne M. Platform envelopment. Strateg Manag J. 2011;32(12):1270–1285.

4. Gamba A, Fusari N. Valuing modularity as a real option. Manag Sci. 2009;55(11):1877–1896.

5. Garud R, Kumaraswamy A. Changing competitive dynamics in network industries: an exploration of sun microsystems' open systems strategy. Strateg Manag J. 1993;14:351–369.

6. Kamel R. Effect of modularity on system evolution. IEEE Softw. 1987;(January):48–54.

7. Simon H. Near decomposability and the speed of evolution. Ind Corp Change. 2002;11(3):587–599.

8. Tiwana A, Konsynski B, Bush A. Platform evolution: coevolution of architecture, governance, and environmental dynamics. Inf Syst Res. 2010;21(4):675–687.