4    Building a Digital Platform

A few years ago, when one of the authors was felled by flu, her nine-year-old neighbor offered up his copy of The LEGO Movie, which, he said, always made him feel better when he was sick. It turns out that The LEGO Movie wasn’t much of a fix for the flu. Surprisingly, however, the movie was useful as a metaphor for companies’ digital journeys.

In the movie, a noble construction worker sets out to save the world from a tyrant who intends to glue in place all of LEGO world. Emmet, the construction worker, prevails, of course, because he teams up with other good guys who apply their combined creativity to outsmart the bad guys. Key to their success is their ability to reconfigure LEGO components into whatever machine or weapon they need to conquer each obstacle they meet. The not-so-subtle message of the movie is that, if you want to succeed, you must accumulate lots of components and apply lots of imagination in using them. (We have not confirmed with either the movie producers or the LEGO Group that this was the intended message of the movie.)

Digital companies build, buy, configure, and reconfigure business, data, and technology components to generate and enhance digital offerings—rapidly. In fact, componentization is key to becoming digital. Components enable speed and agility because, like LEGO bricks, they allow people to quickly assemble solutions from parts that already exist. The trick, of course, is keeping track of all the components so you have the one you need when you need it. That’s why you need a digital platform.

An Operational Backbone Is Not Enough for Digital Success

In chapter 3, we described how the LEGO Group invested 10 years in building a robust operational backbone to support its core business processes. Although LEGO executives consider the company’s operational backbone a strategic business asset, former CEO Jørgen Vig Knudstorp noted that the backbone isn’t sufficient to address the opportunities and threats the digital economy poses.1

Where we’re not savvy enough is in where software development is going now, like smaller applications, disruptive business models, omni-channel landscapes, e-commerce, web-based services, cloud-based services, and so on. We’re not nimble enough there. And we could risk ending up with a legacy platform instead of an advantage platform.

LEGO’s operational backbone is an asset, but it is not a digital platform.

The characteristics of a digital platform are quite distinct from those of an operational backbone. In particular, an operational backbone provides a tightly integrated, bulletproof production environment ensuring the reliability and security of business processes. In contrast, a digital platform provides easy access to the data, business, and technology components that make up digital offerings. An operational backbone contributes to customer satisfaction by providing reliability and transparency. A digital platform, in contrast, delights customers by enabling experimentation, rapid innovation, and continuous feature enhancements of the actual offering. Take, for example, Lyft, the ride service. Initially, Lyft offered people the opportunity to request a ride, get picked up, and pay and tip the driver—all on one app. Each of those customer services is a software component stored on a digital platform. Once Lyft had these basic business components, the company started expanding the app’s functionality, offering additional services like fare-splitting, intermediate stops, and carpooling. Lyft can constantly enhance its value proposition by creating new components and reconfiguring its offerings with new features.2

A Digital Platform—What It Is

A digital platform is a repository of business, data, and infrastructure components used to rapidly configure digital offerings. What’s so special about a digital platform? Reusable digital components. As they build a digital platform, companies accumulate a portfolio of components that may be useful in future digital offerings. The components are slices of code that perform a specific task. Examples of tasks a component might perform include retrieving a customer’s account balance, specifying directions to a location, calculating the probability of an equipment failure from sensor readings, accumulating a customer order in a shopping cart, confirming a user’s identity, or presenting performance results in a dashboard. By placing these components on a digital platform, they become available to individuals developing new offerings. Instead of writing code to address all the functionality requirements of an offering, developers can configure an offering by “calling upon” existing components.

To make components reusable (i.e., to enable developers to call upon a component instead of writing new code), developers API-enable components. API stands for application programming interface. An API allows a component to exchange data with another component. In a well-designed digital platform, each component provides an API (i.e., is API-enabled). APIs hence allow pre-defined, “plug and play” connections between otherwise independent components.

A digital platform consists of three repositories built on a base of cloud technologies, as shown in figure 4.1.

Figure 4.1

Depiction of a digital platform

The digital platform can and should continuously evolve. Toyota Motor North America, which has developed a digital platform to support new car-sharing and other digital offerings, provides an example of how component repositories facilitate development of digital offerings.

Toyota and Servco Pacific Inc.’s Hui as an Example of a Digital Offering Built on a Digital Platform

Toyota Motor North America (TMNA) and Servco Pacific Inc. recently launched a digital offering called Hui—a round-trip, station-based car share service.3 This digital offering, which is operated by Servco, Toyota’s distributor in Hawaii, makes available 70 Toyota and Lexus vehicles at 25 easily accessible locations throughout Honolulu. Honolulu has lots of condos but relatively few parking spots, so car sharing is appealing to both residents and visitors. Hui allows customers to reserve a car by the hour or day through a mobile app that also locks, unlocks, and starts the vehicle.

Hui is one of the first public applications of TMNA’s Mobility Services Platform and its consumer-facing mobility services app. Toyota Connected North America (TCNA) built this digital platform for reuse by other Toyota distributors who might want to launch mobility offerings that capitalize on their local expertise.

Zack Hicks, chief executive officer and president of TCNA, and chief digital officer of Toyota Motor North America, heads up development of the digital platform that provides mobility services. He also evangelizes within Toyota the opportunities it creates. He notes that platform development began with recognizing the need for a repository of data components. Sensors on cars and phones collect a tremendous amount of data. TCNA considered how that data could contribute to potential functionality for mobility services—providing information on where vehicles are currently located and where they have been; which customers use what services when and how; what kinds of maintenance issues and expenses they have with their various cars, and so on. Technical experts designed processes for capturing, storing, processing and sharing that data.

TCNA also started to create infrastructure components built on a cloud platform. Infrastructure components allowed TCNA to connect vehicles to the cloud, to authenticate customers who wanted to use services, to link to payment providers, and a raft of other technology services. TCNA also started creating common business components, including the mobile app for reservations, the Smart Key Box (which generates a digital key for locking, unlocking, and starting a vehicle via a smartphone), vehicle tracking to ensure availability of vehicles, and payment services.

Hui is one of many digital offerings that will use TCNA’s digital platform. The value of the platform grows as the portfolio of mobility offerings that reuse components on the platform expands. Soon after launching Hui, Toyota launched a digital offering that tracks buses traveling between two cities in Japan. Because the platform was available, the company was able to roll out this new offering in just six days.

Hicks notes that creating the digital platform did not require a specific understanding of future business models or decisions on the offerings TCNA would create. Rather, he envisioned the importance of mobility services more generally:

We can stop worrying about which specific business model we are trying to enable by saying, “I need to be able to remotely unlock the vehicle. I need to know who the driver is. I need to be able to score the driver. I need the electronic platform connected to the head unit in a vehicle.” These things enable any type of business model, like one-time trunk release for Amazon to do trunk delivery to people’s cars at work. That same technology allows somebody to rent a car for an hour on the streets of Madrid. These are the things that we’re beginning to enable that allow for those future business models.

TCNA, the organization charged with designing, building, and promoting Toyota Motor North America’s digital platform, was a small team of around 200 people in 2018. Leaders anticipate that customer facing organizations will have primary responsibility for configuring and managing digital offerings while TCNA ensures the repositories for the data, common business components, and infrastructure components. Thus, TCNA will likely grow but it will continue to have an outsized impact for its size.

Digital Platform versus Operational Backbone: Two Different Roles

While Toyota Motor North America relies on its mobility services digital platform to configure new digital offerings, it depends on its operational backbone to ensure the reliability and efficiency of its core business processes. Like most established companies, Toyota finds both benefits and limitations in its existing operational backbone. So, as it builds its digital platform, it continues to try to modernize its operational backbone. For as long as companies require both efficiency and revenue growth, we anticipate they will need to invest in both a digital platform and an operational backbone.

Most digital start-ups focus on a digital platform and are often late to recognize the importance of the operational backbone. In contrast, most established companies have been more focused on building an operational backbone. Some companies, particularly large financial services companies, built legacy systems for each of their products (e.g., mortgages, bank accounts, credit cards). These product platforms are more like monolithic combinations of process and product technology than they are like digital platforms. Unfortunately, moreover, most product platforms in financial services companies were built to support one product. Thus, they do not have reusable components (i.e., APIs). As a result, most financial services companies have many redundant systems and processes supporting their products.

Companies have some options as to what they build into their digital platform and what they build into their operational backbone. For example, customer onboarding can be a reusable business component in a digital platform or an end-to-end process in an operational backbone. Which option makes most sense will depend on whether the company wants to make customer onboarding a customizable experience regularly enhanced through innovation (i.e., a digital component) or a standardized process designed for efficiency and reliability (i.e., a core operational process).

Although some capabilities can be built into either a digital platform or an operational backbone, these two building blocks fulfill different business objectives: efficiency versus revenue growth. Reflecting their very different contributions to digital business success, they also have very different organizational design requirements.

Design Requirements for the Digital Platform

To succeed digitally, companies must define data, business, and infrastructure components and design them for reuse. In other words, they must rethink what they want to offer to their customers in terms of components. The power of a digital platform comes from repositories of reusable business, data, and infrastructure components.

Thus, the essence of designing a digital platform is deconstructing the company’s existing or imagined digital offerings into data, business, and infrastructure components. This is a very different way of thinking! To help you understand the design requirements for a digital platform, table 4.1 contrasts the requirements for the digital platform and the operational backbone.4

Table 4.1

Contrasting Requirements of the Operational Backbone and the Digital Platform

Operational Backbone (Digitized)

Digital Platform (Digital)

Targeted Outcomes

Process efficiencies, predictability, and reliability leading to increased profitability

Rapid innovation of new digital offerings leading to revenue growth

Technology Requirements

Stable, scalable, secure operational systems; automation of repetitive processes

Repositories of API-enabled business, data, and infrastructure components

Data Requirements

Accurate and accessible transaction and master data

Flexible repositories of big data (from sources like sensors, social media, etc.) for analytics

Process Requirements

Deliberate, methodical design and implementation of transaction-processing applications

Iterative design, development, configuration and commercialization of digital offerings

People Requirements

Process owners and data architects; project leaders for large projects

Platform architects; component owners who can hypothesize, test, and manage functionality of components

As the table shows, the operational backbone and the digital platform differ in five ways: (1) their purpose and outcomes, (2) their technology requirements, (3) their critical data requirements, (4) the development processes that, on the one hand, enable business processes and on the other, enable offerings, and (5) the key roles people take on as they engage in those processes.

Outcomes

As we discussed in chapter 3, the operational backbone supports core business processes. The key outcomes of the operational backbone relate to operational excellence—the table stakes for doing business digitally. In contrast, this chapter has described how the digital platform delivers new sources of revenue, leveraging the capabilities of digital technology to enhance customer engagement and solve customer problems.

Technology Requirements

The key technologies in the operational backbone are those that support increased automation of repetitive processes. The technology should reduce time, cost, and opportunity for error. This involves implementing systems that simplify and increasingly automate transaction and operational processes. These include enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, electronic medical records (EMR) systems, core banking engines, and product life cycle management (PLM) systems. In contrast, the digital platform houses repositories of API-enabled data, infrastructure, and business components, so that the company can quickly configure and commercialize digital products and services.

Interestingly, the operational backbone and digital platform do not differ in the degree to which they exploit new digital technologies. The digital platform exists to enhance digital offerings with new digital technologies like social, mobile, analytics, cloud computing, and IoT (i.e., SMACIT). But these same digital technologies are also playing an important role in the operational backbone.

Although most companies originally built their operational systems on older technologies, like mainframes and on-premise enterprise systems, digital technologies are helping to modernize companies’ operational backbones. For example, companies are increasingly supporting core business processes using external, cloud-based software rather than owning their underlying systems. In addition, many companies equip line employees with mobile technologies for easy data access and remote functionality. IoT applications can improve operations, particularly for business needs like equipment maintenance. Enterprise cognitive computing systems apply artificial intelligence to repetitive business processes.

Data Requirements

The operational backbone and the digital platform are linked through data, but they fulfill different data collection and data storage roles. The operational backbone supports the collection, storage, and provision of most transaction and master data. This is because the operational backbone is designed to support business processes that generate and manipulate this kind of data. Ideally, this data will support evidence-based decision-making in firm operations; it will be what some call “a single source of truth.”

The digital platform, on the other hand, collects and stores big data—sensor, social media, public, and purchased data—for purposes of analysis and insights about offerings. These distinctions are not pure. For example, some sensor data may be tracking equipment location or functioning in support of the company’s internal operations. Moreover, the operational backbone and the digital platform sometimes use one another’s data. For example, operational data is often used in analytics embedded in digital offerings, while the digital platform will initiate transactions that then generate part of the company’s master and transaction data.

Process Requirements

To become operationally excellent, companies must implement standardized processes where variability would negatively affect the reliability of the company’s data or business outcomes. To build their operational backbones, most companies use methodical approaches that nail down as many requirements as possible before any code is written. Even companies adopting software-as-a-service solutions for their operational backbone are deliberate in defining system and process requirements. The processes for making changes to the operational backbone will involve careful planning and testing and periodic releases.

In contrast, the key process requirement for digital relates to the experimentation we described in chapter 2. Digital offerings start as minimum viable products that expand as they demonstrate value. Continuous improvement of components depends on continuous release of software so that customers quickly benefit from innovations and improvements. The number of components in the digital platform can and will multiply. Change processes will be no different from development processes.

People Requirements

To design an effective operational backbone, architects define an “end state” or “target state” specifying the company’s core processes (e.g., order-to-cash, global supply chain, HR processes) and how they will share data. Companies can then create roadmaps showing how senior project managers can eventually deliver the target state. These project managers lead large enterprise projects to a timely conclusion. They negotiate, as necessary, for enterprise solutions that are locally acceptable, and they roll solutions out so that value is created quickly.

Architects also play an important role in the digital platform: most significantly, they decide which components are likely to be reused and thus should be designed for reuse and stored in a repository. They may also design standards for API interfaces. But they are not designing an end state. The digital platform constantly evolves as new components are created. Component owners, which we will describe in chapter 5, repeatedly hypothesize and test the value of their components.

The Operational Backbone and Digital Platform Work Together

While the operational backbone and the digital platform are distinct, they must be able to exchange data seamlessly. The digital platform often needs access to master and transaction data both for analytics and for purposes of serving customers. The digital platform might also call upon the operational backbone to provide transaction processing and other functional support for digital offerings. Meanwhile, the operational backbone depends on the digital platform to shield it from constant changes in digital offerings. Figure 4.2 depicts the relationship between the operational backbone and the digital platform.

Figure 4.2

Operational backbone and digital platform are linked

Because the design requirements of the operational backbone and the digital platform (digitized vs. digital) are so different, companies will benefit from distinguishing the two platforms and the people responsible for each. But the responsibility for creating and maintaining the linkages between the digital platform and the operational backbone belongs to the people and processes associated with the operational backbone. Selecting the right data or the appropriate process to expose to the digital platform requires a sophisticated understanding of how legacy applications and the processes they enable actually work. Extracting and exposing data or functionality similarly requires the use of the careful, deliberate planning and testing processes that are routine for those supporting the operational backbone.

Building a Digital Platform

Our research has found that big, established companies are still in the early stages of building their digital platforms, but that is rapidly changing. In 2016, only 30% of the big global companies we surveyed were building a repository of business and infrastructure components for digital offerings.5 The remaining 70% of companies had not yet started to design any platform other than an operational backbone. By 2018, however, 74% of big global companies in our research were at least working on building a digital platform.6 Most of those digital platforms are very early in development, but as business and technology leaders start developing digital offerings, they are finding that a digital platform is essential to rapid innovation.

Companies with a digital platform are 3 times as innovative (measured as revenues from new offerings) than companies without a digital platform. In 2018 fewer than 5% of companies reported having a widely adopted and valuable digital platform.7

A digital platform should be easier to construct than an operational backbone, partly because a digital platform can be built incrementally, as the need for a component becomes apparent. Because most companies have not yet built a portfolio of digital offerings, they haven’t (yet) created monolithic systems instead of digital platforms. Be careful—it’s easy to start building monolithic digital offerings to address immediate opportunities without recognizing how those monoliths will limit speed when developing future innovations.

The design and development of a digital platform requires thoughtful adherence to architectural principles like modularity, reusability, roadmapping, and standard API design. It requires that business and technology leaders think about the company’s digital business in terms of components. We have observed two approaches that can help companies develop digital platforms capable of supporting their business models as they transform from twentieth-century to twenty-first-century companies: building a digital platform incrementally or buying one.

Building a Digital Platform Incrementally

As noted, digital platforms can be developed incrementally—one component at a time. And components can be discarded when they become useless. The digital platform can and should continuously evolve.

Conceivably, a digital platform could start with the components needed for a single digital offering. A successful experiment might expose an opportunity and a company can start to build the necessary components. That approach would delay the launch of these initial offerings, however, so digital companies will be tempted to simply code the functionality for any given offering in a one-off, monolithic fashion. This may work for a few early offerings, but it will lead to rework when a company sees growing opportunities to adapt offerings to customer demands.

Toyota Connected North America built mobility services before soliciting experiments for digital offerings. Similarly, when Hervé Coureil (now Schneider’s chief digital officer), was Schneider Electric’s chief information officer, he recognized that the company’s vision for intelligent energy management solutions would require capabilities that didn’t exist in the company.8 His team built out—sometimes working with vendor partners—four major sets of components that would support future offerings:

  1. subscription billing services needed by business models built on recurring revenue from the sale of on-demand services;
  2. a set of identity services that associate customers with their products, and in doing so, provide a complete picture of a customer’s connected devices;
  3. complex event processing that automatically reroutes data from sensors to appropriate operational support systems; and
  4. cybersecurity services to ensure the security of data that belongs to their customers.

These components are critical elements of the company’s EcoStruxure digital platform. Subscription billing services reside in what we refer to as the business components repository, the identity services leverage data components, and the other two sets of services are combinations of data and infrastructure components. Digital platforms like EcoStruxure position a company for rapid development of digital offerings. But this kind of proactive digital platform development requires a clear vision and an upfront investment that leaders in some companies may be reluctant to make.

The challenge of an incremental approach to establishing a digital platform is that the platform may not seem important (or even worth the trouble) until there are enough components to require formalized management. By the time people throughout a company recognize the need for a digital platform, they may have built a rather messy legacy of monolithic digital offerings for which no one wants to be responsible.

Particularly in companies that have long had autonomous or semi-autonomous business units, business leaders may be unenthusiastic about building and using a digital platform. They would prefer to develop offerings the same way they traditionally developed individual products and services. It’s unnatural to think in terms of configuring business components into offerings. As Jeroen Tas, EVP and chief innovation and strategy officer at Royal Philips, notes:9

If you need new functionality, it’s always easier to tweak the legacy a little bit. That’s why people have a hard time moving over to platforms. Because it’s always, “I need this little piece of functionality. Oh, let me code it into the existing code base. It’s too much risk, too much effort to go to the other platforms.” So therefore, as you see in every company, if you don’t do something, legacy always wins.

At Schneider Electric, digital leaders had to sell business leaders on the benefits of shared components. Even as they start to get successful reuse, they continue to evangelize these benefits to encourage greater reuse by business units and to stimulate additional development of digital offerings. It is often easier for business leaders to imagine a new offering in isolation than to imagine how existing capabilities might contribute to it. Thus, companies may need to provide incentives or requirements that ensure development and use of a digital platform. In other words, digital leaders often must foster component thinking.

Companies with a well-developed digital platform, on average, build 61% of their digital offerings from re-usable components compared to 32% for companies with less developed digital platforms.10

To help in this regard, several companies we researched had established an architectural role—and a related process—for reviewing proposed offerings to identify components that are candidates for reuse. At BNY Mellon, for example, an individual who is a CIO report is charged with reviewing proposed new or revamped financial services offerings to determine what functionality is most likely reusable by other offerings. She assigns to her team the responsibility for developing the reusable functionality into shared components. Functional leaders remain responsible for developing the rest of the offering.11 Note that her role, in effect, helps the company think in terms of components.

Designing and building a digital platform requires leaders to recognize and invest in their longer-term needs before those needs are actually apparent. If business leaders don’t think in terms of reusable components and then commit to building a digital platform, they risk waking up someday to a set of expensive and fragile digital offerings. They would be wise to consider the lessons they learned from the messy legacy systems they built in the past. The operational backbone is a challenge today primarily because most companies built systems to meet immediate local needs rather than longer-term enterprise needs.

Buying a Digital Platform

For companies that don’t have a digital platform, one option is to buy a start-up with a platform. Such an acquisition can introduce some new digital customer services and accelerate the adoption of digital business capabilities. Northwestern Mutual Life Insurance Company12 accelerated its business transformation with what Gartner calls a “techquisition”—the acquisition of a tech company to accelerate the development of digital capabilities.13

Northwestern Mutual Buys LearnVest

Northwestern Mutual, which was founded in 1857, provides 4.4 million clients with life, disability, and long-term care insurance; annuities; investment products; and a wide range of financial planning, brokerage, and advisory services. Northwestern Mutual is designed as a B2B2C business, providing services to its highly satisfied customers (its renewal ratio is 98%) through a network of financial advisors that has long been one of its competitive advantages. Many customers continue to value their relationship with their financial advisor, and the company assumes that will always be true.

Because its financial advisors have always been pivotal to the company’s business model, Northwestern Mutual has focused its systems and processes on meeting their needs. Nonetheless, Northwestern Mutual’s leaders recognize that growing numbers of potential customers, especially younger customers with less complex financial needs, are more likely to seek financial advice through digital channels than financial advisors. Many are more comfortable entering data into digital tools than sharing personal information with a financial advisor. They also have little patience for attending a series of meetings. They expect immediate feedback on their options and rapid closure on their financial security decisions. In addition, even customers who value their relationship with a financial advisor increasingly demand online, real-time, and mobile capabilities.

Northwestern Mutual’s leaders believe that combining speed, convenience and a delightful customer experience with world-class advisors and products will create a unique winning formula in the industry. Thus, its digital vision calls for offering a portfolio of personal and digital interactions meeting the financial needs of clients with an experience that is dictated by the client.

Feeling an urgency to deliver on that vision, in 2015 the company purchased LearnVest, a born-digital company focused on digital delivery of financial planning for Millennials. The LearnVest acquisition not only provided digital financial planning tools, it accelerated adoption of Agile at scale and other cultural changes. As a result, Northwestern Mutual has been able to accelerate development of both a delightful digital customer experience and new digital tools for financial advisors.

LearnVest, which has been fully integrated into Northwestern Mutual (including its HR, finance, facilities, and technology), has evolved into a set of integrated teams focused on delivering a world-class customer experience. The integrated teams are building financial planning, analytics, and online advice services. The organization, which had 150 people at the time of acquisition, had grown to a 500-person organization by mid-2018.

Buying a born-digital company with an existing digital platform may be an easy, quick option for adding digital capabilities to a company undergoing a digital transformation. But we would like to offer a word of warning regarding acquiring a digital platform by buying a born-digital company. To better understand how digital platforms are built, maintained, and used, we studied the platforms of several born-digital companies: We learned that some of those companies have popular offerings, but they don’t always have a well-architected digital platform. They are introducing new features and sometimes even new offerings through brute force (i.e., humans finding a way). They have not carefully designed reusable business, data, and infrastructure components. Instead of components, they have monolithic offerings.

When the leaders of these successful start-ups recognize that their monolithic offerings won’t easily scale, they may become anxious to sell their business. Those businesses, however, are unlikely to be a good buy. If the start-up built one or more products rather than componentized offerings, an established company might acquire a digital brand name, but the acquisition will not provide a digital platform.

Companies looking to buy a digital platform through acquisition should also remember that companies adopt different habits as they build a digital platform than they do when they are building an operational backbone. It won’t be enough to just acquire another company’s digital platform; the acquisition must bring onboard the people and their ways of working. To have an impact on the mothership, anyone engaged in building and configuring components must abandon old habits and adopt those of the start-up.

Getting Your Digital Platform Right

Currently, most companies with established, non-digital business models are allocating most of their resources to digitization—getting better at what they already do. Since they will likely rely on traditional sources of revenue for the foreseeable future and their digital businesses will depend on efficient core business processes, the investment in the operational backbone is wise.

But long-term success is dependent on digital business capabilities, so companies should allocate resources to learning how to componentize offerings and build a digital platform. In most industries, the pace of the shift from traditional products and services to digital offerings allows time for learning how to adopt new systems and processes that will accelerate development of digital offerings. That said, building and using a digital platform requires a very different organization, so companies need to get started on their digital platform building block. If they wait until they have an urgent need for digital offerings, it will be too late.

This chapter developed the following key points:

  • Componentization of digital offerings is what’s so different about digital. To build a digital platform that can support rapid innovation of digital offerings, you need to think of your business in terms of components. Do you have any digital offerings that are not componentized? Can you decompose those offerings into components that can be reused in future offerings?
  • Your operational backbone and your digital platform have very different design requirements. Are you architecting a digital platform with repositories of digital components?
  • The digital platform is distinct from, but works with, the operational backbone. Individuals responsible for the operational backbone will need to make data and processes accessible to your digital offerings. Do you have people responsible for linking the operational backbone and the digital platform?

As companies develop digital components and offerings, they become software companies. Software offerings change much more quickly than traditional products and services. Thus, a company’s ability to adopt rapid change is key to digital success. Rapid change will demand new decision-making accountabilities and work design. That’s what we’ll talk about in the next chapter.

Notes