Designed for Digital

How to Architect Your Business for Sustained Success
by Jeanne W. Ross, Cynthia M. Beath, and Martin Mocker; MIT CISR Research Team
A Chapter-by-Chapter Summary
Condensed to preserve the authors’ structure, logic chain, and argument arc.

About the Authors

Jeanne W. Ross spent the better part of three decades at MIT’s Center for Information Systems Research (CISR), where she served as Principal Research Scientist. Her career was defined by a single, stubborn question: why do some companies get more value from their technology investments than others? The answer she kept finding was not better software or smarter IT departments. It was design—the way organizations configure their people, processes, and technology to operate as a coherent whole. Her earlier book, Enterprise Architecture as Strategy (co-authored with Peter Weill and David Robertson, 2006), gave executives a vocabulary for that insight. Designed for Digital extends it into the era of digital transformation.

Cynthia M. Beath is Professor Emerita of Information Systems at the McCombs School of Business at the University of Texas at Austin. She holds an MBA and PhD from UCLA and began her career in private industry before moving into academia. Her research has long focused on the organizational and managerial dimensions of IT, and she has been a senior editor at the leading journals in her field. Her instinct throughout Designed for Digital is to keep the argument tethered to what managers can actually do on Monday morning.

Martin Mocker is Professor at ESB Business School at Reutlingen University in Germany and a Research Affiliate at MIT CISR. A German researcher embedded in an American institution, Mocker brought both European field cases and a systems architect’s precision to the collaboration. His fingerprints are most visible in the chapters on platform design and component architecture, where the argument is at its most technically exacting.

The three met through CISR’s ongoing research program into digital transformation and conducted more than five years of field work—300-plus interviews with senior executives across more than 30 organizations—before writing a word of the book. The cases they assembled span financial services, manufacturing, healthcare, logistics, and consumer goods, including Amazon, BNY Mellon, DBS Bank, LEGO, Royal Philips, Schneider Electric, and USAA. The book was published in September 2019 by MIT Press and was named one of Forbes’s Top Ten Technology Books of that year.

Table of Contents

Series Foreword
Preface and Acknowledgments
Chapter 1: Digital Business Design
Chapter 2: Building Shared Customer Insights
Chapter 3: Building an Operational Backbone
Chapter 4: Building a Digital Platform
Chapter 5: Building an Accountability Framework
Chapter 6: Building an External Developer Platform
Chapter 7: Developing a Roadmap for Your Digital Transformation
Chapter 8: Designing Your Company for Digital
Appendix 1: Committing to an Operating Model to Build an Operational Backbone
Appendix 2: Assessing Your Building Blocks for Digital Transformation
Notes
Index

Preface and Acknowledgments

[context and frustration]

Most of the executives the authors interviewed had deployed digital technologies. They had cloud infrastructure, mobile applications, analytics pipelines, and AI pilots. Many had launched innovation labs. What they lacked—almost universally—was the organizational design to make those investments deliver sustained value. Technology was moving. The companies were not.

[the research foundation]

The book emerged from five years of fieldwork through MIT CISR, including structured interviews with more than 300 senior executives and survey data from over 1,000 organizations. The authors were not looking for silver bullets. They were looking for patterns: what did companies that consistently delivered new digital value have in common that their struggling peers did not?

[the central finding]

The answer was architectural. Successful companies had made deliberate choices about how to configure their people, processes, data, and technology—choices that allowed them to rapidly develop and scale new digital offerings. Unsuccessful ones were optimized for a previous era. They had structures built for executing fixed strategies, not for adapting to fluid ones.

[scope of the book]

The book is organized around five building blocks of digital success, presented in a sequence that reflects how most organizations need to develop them. It draws on cases from a wide range of industries and geographies, and it is aimed at the leaders who own these decisions: CEOs, CIOs, COOs, and the business unit heads who either support or resist the transformation agenda.

Chapter 1: Digital Business Design

[the problem with how companies think about strategy]

Most established companies approach digital transformation as a technology problem: acquire the right platforms, hire data scientists, stand up an innovation lab. The authors open by arguing that this framing is wrong. The real constraint is not technology—it is organizational design. Companies are structured to execute fixed strategies efficiently. The digital economy requires something different: the ability to continuously discover what customers will value and rapidly deliver it. Those two goals require fundamentally different organizational configurations.

[definition]

The authors define digital business design as the holistic configuration of people—their roles, accountabilities, skills, and structures—alongside processes and technology, all organized to define value propositions and deliver offerings made possible by digital capabilities. The critical word is holistic. Partial changes produce partial results. Deploying a digital platform while leaving management structures, incentive systems, and data governance unchanged is like installing a racing engine in a vehicle with stock steering and brakes.

[what digital technologies actually make possible]

Three capabilities of digital technologies are driving the disruption: ubiquitous data, unlimited connectivity, and massive processing power. Together they create conditions in which personalized, context-aware, continuously improving offerings are not merely possible but expected. Customers who experience this from Amazon, Netflix, or their bank’s mobile app begin to expect it everywhere. The bar moves whether or not a company chooses to move with it.

[two types of digital value]

The authors distinguish between two categories of digital offering. The first is enhanced products and services: digital features layered onto existing core offerings—sensors in manufacturing equipment, apps for retail banking, connectivity in consumer goods. These improve the core proposition but do not fundamentally change the business model. The second is integrated solutions: end-to-end responses to customer needs that draw on data, connectivity, and partnerships across organizational boundaries. These can define entirely new markets. The first category raises the bar; the second redefines the game.

[the five building blocks]

The chapter introduces the framework that structures the rest of the book: five interdependent building blocks that companies must develop to deliver integrated digital solutions at scale. Shared Customer Insights is the organizational capacity to accumulate knowledge about what customers actually value—not through periodic research, but through continuous experimentation and feedback. An Operational Backbone is the standardized, automated infrastructure of processes, data, and systems that ensures operational reliability. A Digital Platform is the repository of reusable digital components that allows new offerings to be assembled rapidly without rebuilding from scratch. An Accountability Framework is the set of roles, incentives, and governance mechanisms that empowers teams to build and use the platform while keeping their efforts aligned. An External Developer Platform extends the digital platform to outside partners, creating an ecosystem of offerings built on the company’s core capabilities.

[design vs. structure]

The authors draw a sharp distinction between organizational structure and organizational design. Structure defines reporting relationships and functional ownership—the org chart. Design shapes how work actually flows: who has authority to decide what, how information moves, where accountability for outcomes sits. Most companies change structure frequently and design rarely. Digital transformation requires the opposite emphasis. Structure should follow design, not precede it.

Digital business design—not strategy or technology—is what separates winners from losers in the digital economy. Companies must configure their people, processes, and technology not for efficient execution of fixed plans, but for continuous discovery and delivery of new customer value.

Chapter 2: Building Shared Customer Insights

[the core challenge]

Defining a digital value proposition is, in the authors’ words, more art than science. You cannot conduct a survey and ask customers what digital solutions they would like. They do not know. What they know is their frustrations, their frictions, their unmet needs. The company’s job is to imagine a solution, test it, learn from the result, refine the idea, and test again. Repeat until you understand what customers will pay for. That process requires a specific organizational capability: the accumulation of shared knowledge about both customer problems and digital solutions.

[why ‘shared’ is the operative word]

Many companies generate customer data. Few generate shared customer insights. The difference is organizational. In siloed companies, the marketing department knows what campaigns converted, the product team knows what features were built, the service team knows what customers complained about—and none of them routinely combine what they know. Shared customer insights require cross-functional teams with shared data access, shared metrics, and shared accountability for outcomes.

[the test-and-learn imperative]

Companies that build this capability run experiments constantly. They ship minimum viable offerings, observe what happens, collect data at every touchpoint, and use the results to inform the next iteration. General Electric’s experience with Predix is the cautionary case: GE ambitiously developed its cloud-based industrial IoT platform but grossly underestimated actual customer demand—and what customers would pay. The company had invested billions before understanding the market it was building for. The insight deficit was not about data. It was about the organizational processes to accumulate learning.

[what building this capability actually requires]

Three things must happen together. First, companies need to develop digital offerings fast enough to generate real learning—not eighteen-month waterfall projects but rapid experiments with real customers in real conditions. Second, they need mechanisms to capture, record, and share what is learned across the organization—customer journey data, experiment results, feedback loops. Third, they need cross-functional teams—product, engineering, design, and business—that sit together, share ownership of outcomes, and iterate collectively. Without all three, insights stay local and learning stays slow.

[the intersection test]

The authors offer a useful frame for identifying where digital offerings actually live: at the intersection of what customers genuinely want and what digital capabilities make possible. Neither side alone is sufficient. Customer desires without digital enablement are just wishes. Digital capabilities without customer desire are solutions looking for problems. The discipline of building shared customer insights is the discipline of staying at that intersection—neither getting seduced by technology for its own sake nor anchored to product categories defined by the pre-digital era.

Shared customer insights are not a research function—they are an organizational capability built through continuous experimentation and shared learning. Companies that accumulate this knowledge faster than their competitors gain the only durable advantage in a market where customer expectations never stop moving.

Chapter 3: Building an Operational Backbone

[the table stakes]

Before a company can build anything distinctively digital, it must function reliably. The operational backbone is what makes reliable functioning possible: a set of integrated, standardized systems, processes, and data that ensure operational excellence in the core business. It typically includes enterprise resource planning (ERP) systems, customer relationship management (CRM) platforms, and the master data frameworks that keep information consistent across the enterprise. Without it, leadership is perpetually consumed with firefighting—too busy keeping existing operations running to invest in creating new digital value.

[the LEGO turnaround as illustration]

LEGO in the mid-2000s was in crisis—overextended, financially strained, losing coherence in its product portfolio. The turnaround began not with a digital innovation agenda but with a deliberate effort to standardize and simplify: rationalizing the number of unique plastic pieces, cleaning up financial data, standardizing processes across geographies. That discipline created what the authors call a foundation for execution. It is the same work described in their earlier book, Enterprise Architecture as Strategy, now reframed as the prerequisite for digital transformation. LEGO’s subsequent digital success—its platform, its apps, its ecosystem—was built on top of that operational clarity, not in spite of the unglamorous years spent building it.

[the two demands an operational backbone must meet]

The backbone must simultaneously support efficiency in existing operations and reliability in digital transactions. Efficiency is the traditional goal: automated processes, reduced errors, lower costs. Reliability in digital contexts adds a new requirement: digital offerings that fail, lag, or produce inconsistent data destroy trust faster than any operational failure in an analog world. Customers who experience a broken app or an inconsistent account balance do not call a service desk—they leave. The operational backbone must be architected with that asymmetry in mind.

[how it enables digital]

A strong operational backbone enables digital in two ways. First, it frees up management attention. When the core business runs well, leaders can think about the future rather than defending the present. Second, it provides the clean, consistent, trusted data that digital offerings depend on. Personalization, predictive analytics, and automated decisions all require reliable underlying data. Companies that try to build digital platforms on top of messy, inconsistent, siloed legacy data find that the digital layer amplifies the mess rather than resolving it.

[the sequencing issue]

Many companies want to skip the operational backbone work because it is expensive, slow, and unglamorous. The authors are blunt about this temptation: you cannot shortcut it. Companies that launch digital offerings without operational reliability find that customer expectations for both digital innovation and operational excellence cannot be met simultaneously from a weak foundation. The sequence is not optional. Operational backbone first, then build.

The operational backbone is table stakes for digital success—not a prerequisite you can skip or defer. Until core processes are standardized, automated, and data-reliable, digital investments will underdeliver and management attention will never fully reach the future.

Chapter 4: Building a Digital Platform

[the defining concept]

If the operational backbone is the reliable engine of the existing business, the digital platform is the innovation engine for the new one. The authors define it precisely: a repository of business, data, and infrastructure components used to rapidly configure digital offerings. The critical feature is reusability. Each component—a customer data API, a payment processing module, a logistics tracking service, an identity verification routine—is built once, documented, and made available for any team in the organization to use in assembling new offerings. The platform is the organizational asset that makes speed possible.

[what components look like in practice]

The authors distinguish three types of components. Infrastructure components are the cloud services, networking, and compute resources that host everything else. Data components are the data assets—customer records, transaction histories, product catalogs, sensor feeds—that digital offerings draw on. Business components are the capabilities with defined interfaces: a pricing engine, a recommendation system, a claims processing workflow. BNY Mellon’s practice of evaluating new services for reusability before beginning development illustrates the discipline: every component built is built to be used again.

[the role of APIs]

What makes components reusable is their interface—the API (application programming interface) that defines how other systems can interact with the component without needing to know how it works internally. Platform architects and technology leads are responsible for defining API standards that ensure components remain interoperable as the platform grows. This is not a technical detail—it is a governance question. Inconsistent APIs create integration debt that accumulates faster than the platform creates value.

[cloud as hosting infrastructure]

The digital platform rests on cloud services—public (AWS, Azure, GCP), private, or hybrid. Cloud provides the elastic capacity that allows components to scale with demand and the managed services that reduce the burden of operating infrastructure. The authors treat cloud not as a destination but as an enabling layer: necessary but not sufficient. Companies that ‘move to the cloud’ without building reusable components on top of it have paid for infrastructure without building the capability that matters.

[speed is the point]

The authors are explicit about why this architecture matters: time to market for new digital offerings is the competitive variable. Companies with mature digital platforms can assemble new products by combining existing components—often in weeks. Companies without platforms must build every new offering from scratch—often in months or years. The platform does not just reduce cost; it changes the speed at which the organization can respond to market signals and customer feedback.

A digital platform—built from reusable, API-accessible business, data, and infrastructure components—is what makes digital speed possible. Without it, every new offering requires rebuilding from scratch. With it, innovation compounds as each new component becomes raw material for the next.

Chapter 5: Building an Accountability Framework

[the central tension]

Digital organizations face a structural paradox. On one hand, innovation requires empowered, autonomous teams that can move quickly without waiting for approvals or negotiating priorities across silos. On the other hand, a digital platform is a shared resource—its value depends on components being reusable, interfaces being consistent, and governance being trustworthy. Unchecked autonomy produces incompatible components and a platform that fractures. Over-centralized control produces slow teams and a platform that never gets built. The accountability framework is how companies resolve this tension.

[the Spotify case]

The authors use Spotify as their primary illustration. Spotify organized its engineering and product teams into squads (cross-functional teams owning a specific domain), tribes (collections of related squads), chapters (communities of practice for a specific discipline across squads), and guilds (company-wide networks of practitioners). The design gave squads genuine autonomy over what they built and how while chapters maintained technical standards and tribes provided coordination. The accountability framework was not just an org chart—it defined who owned which components, who set which standards, and how conflicts between competing priorities were resolved.

[component ownership]

A key mechanism in the accountability framework is component ownership: assigning specific individuals or teams responsibility for maintaining, improving, and governing each component of the digital platform. Without clear ownership, components decay. Updates are delayed because no one is responsible. Interfaces drift because no one enforces standards. Dependencies become invisible because no one maps them. Component owners are accountable not just for building their component but for its fitness for use by others across the organization.

[incentive alignment]

The framework also shapes incentives. In traditionally structured companies, business unit leaders are measured on their unit’s P&L. This creates rational pressure to build proprietary solutions rather than contribute to shared platforms—because shared investment shows up as cost in my budget while the benefit accrues elsewhere. Designing an accountability framework for digital success requires rethinking how contribution to the platform is measured, recognized, and rewarded. Without that rethinking, the platform stalls because no one is individually rewarded for building it.

[governance for fast and aligned]

The goal is not consensus—it is coordinated autonomy. Teams make decisions quickly within their domain. Platform decisions—which components to build, which standards to apply, which APIs to publish—are made through defined governance processes that are fast enough not to be circumvented. The worst outcome is shadow platforms: teams that bypass governance because it is too slow and build incompatible capabilities that fragment the asset the whole organization depends on.

An accountability framework enables the paradox at the heart of digital organization: it empowers teams to move quickly while coordinating their efforts around a shared platform. Without it, speed and coherence trade off. With it, they reinforce each other.

Chapter 6: Building an External Developer Platform

[extending reach beyond the boundary of the firm]

The first five building blocks define what a company can do inside its own walls. The external developer platform (ExDP) extends the digital platform beyond those walls—making selected components available to outside partners, developers, and other organizations through APIs. The goal is an ecosystem of offerings that no single company could build alone. Amazon and Apple built the archetype: by opening their platforms to external developers, they enabled millions of applications they never wrote, creating value that vastly exceeds what their internal teams could have produced.

[two models for external platforms]

The authors identify two distinct approaches. The first is a partner-enablement platform, where a company makes its internal capabilities available to specific partners who use them to build complementary services. DBS Bank’s ExDP exemplifies this: it publishes APIs for payments, account information, and analytics that third-party developers use to build applications integrating banking services into other contexts—lending platforms, e-commerce sites, financial management tools. The second is an industry platform, where a company creates a marketplace for related offerings, positioning itself as the hub through which complementary products and services connect to customers.

[Royal Philips and the healthcare ecosystem]

Royal Philips’ HealthSuite platform illustrates the healthcare version of the model. Philips developed a platform that connects medical devices, health data, clinical algorithms, and care management applications. Rather than attempting to build all the applications itself, Philips opened the platform to partner developers who can build specialized applications on top of its infrastructure and data layer. Philips defines the standards, owns the platform, and provides access to the ecosystem. Partners bring domain knowledge and specialized functionality that Philips cannot economically build internally.

[the prerequisites]

The authors’ advice on timing is direct: do not start with the external developer platform. It is the fifth building block for a reason. An ExDP built on an immature digital platform produces an ecosystem of limited offerings. An ExDP built without a strong accountability framework produces governance chaos as external partners encounter inconsistent APIs, unclear ownership, and unreliable components. The ExDP amplifies whatever is in the digital platform beneath it. Build the platform first.

[the network effect logic]

The long-term logic of the ExDP is network effects. As more partners build on the platform, it becomes more valuable to each new partner. As it becomes more valuable, more partners join. The ecosystem compounds. But this dynamic requires that the platform provides something genuinely useful to external developers—data, capabilities, or customer access that they cannot easily replicate themselves. The platform must be permeable enough to attract developers and selective enough to remain coherent.

An external developer platform multiplies what a company can offer by extending its platform to partners who create offerings the company could never build alone. But it is the last building block to develop—because it amplifies whatever is in the platform beneath it, strengths and weaknesses alike.

Chapter 7: Developing a Roadmap for Your Digital Transformation

[no universal sequence]

If a reader has been hoping for a step-by-step implementation guide, this chapter delivers both validation and frustration. The authors confirm that there is no single roadmap that works for all companies. What a company should build first, how fast it should move, and which capabilities it should prioritize depend on three factors: what offerings it is trying to create, what capabilities it already has, and who its leadership team is. The research found two constants, but beyond them, variation is the rule.

[the two universal starting conditions]

Two things held across all the companies studied that were successfully progressing toward digital maturity. First, they had at least a basic operational backbone—not necessarily a world-class one, but enough to ensure reliability in core operations and access to clean enough data to start learning. Second, they had begun developing some form of shared customer insights, even informally. Companies that had neither of these were not yet on a digital transformation trajectory; they were still in preparation. Companies that had both were ready to accelerate.

[four archetypes of transformation paths]

The authors present four company archetypes that represent different starting conditions and therefore different roadmaps. The Industrial Company enters the digital era with a strong operational backbone built around manufacturing or logistics excellence—LEGO and Schneider Electric fit this profile. Its challenge is building shared customer insights and a digital platform on top of operational discipline it already has. The Service Provider starts with customer relationships but often weaker process standardization—USAA and DBS Bank are examples. It can move to digital offerings quickly but must simultaneously strengthen operational infrastructure. The Born-Digital Company, like Spotify, has platform DNA from the start but must learn to manage complexity as it scales. The Diversified Corporation faces the hardest challenge: multiple legacy businesses with different operational backbones, requiring portfolio-level decisions about which units to transform first and at what pace.

[the danger of simultaneous transformation]

The authors document a consistent failure mode: companies that attempt to develop all five building blocks simultaneously. The reasoning seems sound—why would you wait to build shared customer insights if you could start that work now? But in practice, organizations have finite leadership attention, change management capacity, and investment budgets. Trying to do everything at once typically means doing nothing well. The research finding is blunt: focused, sequenced investment produces better outcomes than distributed, simultaneous effort.

[portfolio management as a roadmap discipline]

For diversified companies, the roadmap is not just a technology plan but a portfolio decision: which business units get investment priority, which capabilities are built centrally versus locally, and how the holding company governs the pace and direction of transformation across its portfolio. These decisions require the same discipline applied to a capital investment portfolio—expected returns, risk tolerance, sequencing of dependencies.

There is no universal roadmap for digital transformation—the right path depends on what you’re building, what you have, and who is leading. But the research is clear: sequenced, focused investment in building blocks produces better outcomes than simultaneous transformation attempts.

Chapter 8: Designing Your Company for Digital

[the synthesizing argument]

The final chapter draws the argument together and confronts what the authors describe as the deepest challenge in digital transformation: it is not a technology problem, not a strategy problem, and not an execution problem. It is a design problem. Companies that succeed are not necessarily the ones with the most advanced technology stack or the most ambitious roadmap. They are the ones whose organizational design—the configuration of their people, processes, and technology—allows them to consistently do three things: build new infrastructure and data components, test and learn what customers value, and enable individuals to deliver on those capabilities while keeping their efforts aligned.

[four operating models]

The authors introduce four operating models that represent different positions in the digital design space, differentiated by two dimensions: the degree of business integration (how tightly connected the company’s value chain is) and the degree of standardization (how consistent processes and data are across the enterprise). The Unification model—high integration, high standardization—suits companies where a single, consistent customer experience is the core value proposition. The Diversification model—low integration, low standardization—suits holding companies where each business unit operates independently. The Coordination model—high integration, low standardization—suits companies where different business units serve a shared customer. The Replication model—low integration, high standardization—suits companies that replicate a proven business model across many geographies or segments. A company’s operating model determines which components of the digital design need the most attention.

[the role of senior leadership]

The authors are explicit about where responsibility for digital business design sits: with senior executives, not with the IT department. CIOs and technology leaders are essential partners, but digital business design is a management discipline. It shapes what people are accountable for, how decisions are made, what is measured, and how investment is allocated. Those are not technology questions. They are governance questions, and they belong at the top.

[the evolving nature of strategy]

One of the book’s most pointed arguments concerns how the relationship between strategy and design has changed. In a stable environment, strategy precedes design: leadership defines a multi-year plan, and the organization is structured to execute it. In a digital environment, that sequence inverts. Because customer desires and technology capabilities change faster than multi-year strategies can track, strategy must emerge from organizational capability. Companies that are designed for digital do not wait for strategy to tell them what to build. Their design enables them to discover what to build through continuous experimentation—and then scale it.

[the closing imperative]

The book ends not with a checklist but with a disposition: embrace digital technologies as part of a coherent strategy to build the organizational capabilities that make continuous innovation possible. The enemy is random acts of digital—app launches, AI pilots, and blockchain experiments that consume resources without building the platform, insights, and governance that create compounding value. Digital transformation is not a project. It is an ongoing organizational design challenge. The companies that recognize this distinction are the ones that will still be winning in a decade.

Digital success belongs to companies designed for it—where people, processes, and technology are configured not to execute a fixed strategy, but to continuously discover, develop, and deliver what customers value in a world where both technology and expectations never stop changing.

A Note on Using This Book

Ross, Beath, and Mocker are not management theorists writing for other academics. They are researchers who spent five years in the field with executives trying to solve real problems, and the book reflects that. Its value is not in the elegance of the five-building-block framework—though the framework is genuinely clarifying. Its value is in the cases that populate each chapter: what LEGO actually did when it rebuilt its operational backbone, what Spotify actually built when it designed its accountability framework, where Philips succeeded and where it struggled in building its healthcare ecosystem.

The framework gives readers a map. The cases give them permission—evidence that organizations like theirs have navigated this terrain before. The combination is the most useful thing a management book can offer: a way of thinking about the problem and proof that the thinking can be put into practice.

The most important single idea in the book may be its least dramatic: sequencing matters. Companies that try to do everything at once typically succeed at nothing. Those that focus on building a single capability—a reliable operational backbone, a coherent digital platform, an accountable team structure—and then build the next one on top of it, are the ones that arrive at digital maturity. The urgency is real. But the path is iterative.

— End of Summary —