Designing Value-Based Platforms: Architectural Strategies Derived from the Digital Markets Act

This paper analyzes the technical implications of the Digital Markets Act (DMA) through qualitative methods to propose eight high-level design strategies and 15 specific tactics for building value-based platform architectures that ensure fairness, contestability, and user choice.

The Gist

Imagine the digital world as a massive, bustling shopping mall.

In this mall, a few giant landlords (like Apple, Google, and Meta) own the entire building, the security system, the electricity, and the only way to get in and out. They also happen to run their own shops inside the mall.

For a long time, these landlords could play by their own rules. They could:

• Hide the signs pointing to your favorite small shops.
• Force you to use their security guard (and their data collection) to enter.
• Say, "If you want to shop here, you must buy our brand of milk, not the one from the farmer down the hall."
• Keep the blueprints of the mall secret, so no one else could build a better shop.

This paper is about a new set of Mall Rules called the Digital Markets Act (DMA). The European Union wrote these rules to stop the giant landlords from being unfair and to give the small shops (and the shoppers) a fair chance.

But here's the problem: The rules are written in "legalese." They say things like "ensure contestability" and "guarantee user choice." Software engineers and architects (the people who actually build the mall and the shops) needed to know: "Okay, but how do we actually build that?"

This paper answers that question. The authors took the complex legal rules and translated them into 8 Blueprints for Fairness.

The 8 Blueprints (Strategies)

Think of these as the architectural instructions for building a fair digital ecosystem:

1. The "Opt-In" Switch (Controlled Personalization):

   • The Old Way: The mall landlord tracks everything you do and forces you to use their personalized ads.
   • The New Blueprint: You get a big, clear switch. You can choose to let them track you, or you can flip the switch to "No Thanks" and still use the mall. You are in control.

2. The "Changeable Default" Dial:

   • The Old Way: The mall forces you to use their map app and their browser. You can't change them.
   • The New Blueprint: When you walk in, the landlord asks, "Which map do you want to use? Ours? Or the one from the small shop?" You can pick any, and you can change your mind later.

3. The "Open Door" Policy (Equal Access):

   • The Old Way: The landlord's own shops get a VIP pass to the back door, while small shops have to climb a fence.
   • The New Blueprint: Every shop, big or small, gets the exact same key to the back door. If the landlord's shop can talk to the security system, the small shop must be able to too.

4. The "Fair Ranking" Sign:

   • The Old Way: The mall puts the landlord's shop at the very front of the hallway and hides the small shops in the basement.
   • The New Blueprint: The mall must use a fair, transparent list. If a small shop is the best, it gets the front spot. The landlord can't cheat the list just because they own the building.

5. The "Moving Truck" Service (Portable Data):

   • The Old Way: If you want to leave the mall for a new one, the landlord locks your stuff in a vault and says, "You can't take your photos or contacts with you."
   • The New Blueprint: The landlord must give you a moving truck. You can pack up all your data (photos, contacts, history) and drive it to a new mall easily.

6. The "Business Data" Receipt:

   • The Old Way: Small shop owners can't see who is buying their stuff because the landlord keeps the sales records hidden.
   • The New Blueprint: The landlord must hand over the sales receipts. Small shops get to see their own customer data so they can run their business better.

7. The "Secret Sauce" Library (Training Data):

   • The Old Way: The landlord uses all the data from the mall to train their AI to be super smart, but they won't let anyone else see that data.
   • The New Blueprint: The landlord must share a "sanitized" version of the data (like a cookbook with the secret family recipes removed, but the cooking techniques kept) so small shops can train their own AI to compete.

8. The "Price Tag" Transparency:

   • The Old Way: The landlord charges for ads but won't tell you exactly how much they are taking or how they calculate it.
   • The New Blueprint: Every fee, every surcharge, and every ad performance metric must be written on a clear, visible price tag that anyone can check.

The "Tactics" (How to Build It)

The authors didn't just stop at the blueprints. They looked at how the giant landlords (Apple, Google, etc.) are actually trying to follow these rules right now. They found 15 specific construction techniques (Tactics).

For example, to follow the "Open Door" policy, a landlord might build an "Alternative App Store" (Tactic). This is like building a side entrance to the mall where you can bring your own shops without going through the main security gate.

Why This Matters

The paper argues that we can't just write laws and hope technology magically fixes itself. We need to design the technology with these values (fairness, choice, openness) baked into the foundation.

• Before: The architecture was designed to lock people in and make the landlord rich.
• Now: The architecture must be designed to let people out, let new people in, and keep the playing field level.

In a nutshell: This paper is a guidebook for software architects. It says, "The law says the mall must be fair. Here are the 8 blueprints and 15 tools you need to build a mall that actually works that way." It bridges the gap between "The Law" and "The Code."

Technical Summary

Here is a detailed technical summary of the paper "Designing Value-Based Platforms: Architectural Strategies Derived from the Digital Markets Act" by Stiehle et al.

1. Problem Statement

The platform economy is dominated by "gatekeepers" (e.g., Meta, Apple, Alphabet) that control quasi-monopolistic digital markets. These entities often leverage network effects, data accumulation, and vertical integration to engage in unfair practices, such as self-preferencing, restricting interoperability, and locking in users. This harms contestability (the ability of competitors to challenge market power), fairness, and user choice.

While regulations like the Digital Markets Act (DMA) have been enacted to address these issues by imposing specific obligations on gatekeepers, there is a significant gap in software architecture research. The technical implications of the DMA have not been systematically studied. Specifically, there is a lack of guidance on how to translate abstract human values (like fairness and contestability) mandated by policy into concrete, actionable software architectural designs.

2. Methodology

The authors employed a qualitative research approach based on systematic coding and thematic analysis, following guidelines by Saldaña and Cruzes & Dyba. The study followed a five-phase process (illustrated in Figure 1 of the paper):

1. Phase 1: Coding of Recitals: The researchers analyzed the 109 recitals of the DMA to extract underlying problems, intentions (do's and don'ts), and values. They used open coding to identify specific issues (e.g., "increases switching costs") and in vivo coding to extract values (e.g., "contestability").
2. Phase 2: Thematic Analysis: The extracted codes were synthesized into higher-level themes to form preliminary design strategies.
3. Phase 3: Matching Obligations: The researchers mapped the specific legal obligations (Articles 5–7) of the DMA against their preliminary strategies to ensure completeness. No new strategies emerged, validating the initial set.
4. Phase 4: Compliance Report Coding: To ground the strategies in reality, the authors analyzed approximately 650 pages of compliance reports from five major gatekeepers: Alphabet, Amazon, Apple, Booking, and Meta. They used deductive coding to match these reports to their strategies and open coding to derive specific Gatekeeper Tactics.
5. Phase 5: Synthesis: The preliminary strategies and the derived tactics were consolidated into a final set of 8 Design Strategies and 15 Tactics.

3. Key Contributions

The paper makes three primary contributions to the field of software architecture and value-based engineering:

• Translation of Policy to Architecture: It bridges the gap between legal regulation (DMA) and technical design, providing a systematic method to convert abstract values into architectural concerns.
• Eight High-Level Design Strategies: The authors derived a taxonomy of strategies that serve as fundamental approaches to achieving DMA goals.
• Fifteen Concrete Tactics: By analyzing real-world compliance reports, they identified 15 specific architectural tactics currently being implemented by gatekeepers, categorized by their influence on system architecture and the "affordances" (new opportunities) they create for third-party developers.

4. Results: Strategies and Tactics

The core results are organized into four strategy groups, containing 8 strategies and 15 tactics (summarized in Figure 2 and Table I of the paper):

A. Controlled Personalisation

Focuses on user control over data to prevent lock-in.

• S1: Opt-In to Personalisation: Users must be able to choose less personalized alternatives.
  • Tactics: Consent Management (T1), No Inter-Platform Data Processing (T2).
• S2: Changeable Defaults: Users must be able to uninstall default apps and change default services.
  • Tactics: Allow Uninstallation of Default Apps (T3), Default Service Management (T4).

B. Equal Services

Focuses on ensuring non-discriminatory access and visibility.

• S3: Equal Access & Interoperability: All services must have equal access to platform features and users.
  • Tactics: Open Interfaces and Protocols (T5), Interoperability Requests (T6), Opt-In Interoperability (T7), Alternative App Distribution (T8), E2EE Service Interoperability (T9).
• S4: Equal Ranking: Search results and listings must be non-discriminatory.
  • Tactics: Non-Preferential (Ranking) Criteria (T10).

C. Portable & Accessible Data

Focuses on data portability to reduce switching costs and barriers to entry.

• S5: Portable User Data: Users can export and transfer their data.
  • Tactics: Portability Tool (T11), Direct Data Transfer to Third-Parties (T12).
• S6: Accessible Business Data: Business users can access their own data and their customers' data.
  • Tactics: Link Business and User Data (T13).
• S7: Accessible Training Data: Third-parties can access anonymized data used to train algorithms.
  • Tactics: Provide Anonymised Training Dataset (T14).

D. Transparent Practice

Focuses on transparency in advertising and fees.

• S8: Transparent Advertising: Ad performance and costs must be verifiable.
  • Tactics: Two-Sided (Ad) Transparency (T15).

Affordances: The paper highlights that these tactics create new design opportunities for third-party developers, such as the ability to distribute apps via alternative stores (T8), integrate with core services like payments (T7), or compete on equal footing in search rankings (T10).

5. Significance and Implications

• Filling a Research Gap: This is the first work to holistically investigate the technical implications of the DMA, moving beyond legal analysis to software architecture.
• Value-Based Engineering: It provides a concrete framework for "Value Sensitive Design" (VSD), showing how to operationalize values like fairness and contestability in system architecture.
• Dual Perspective: The study addresses both the Gatekeeper (who must implement these changes to comply) and the Third-Party Developer (who gains new affordances and design options).
• Future Design Guidance: The derived strategies and tactics serve as a blueprint for architects designing new platforms or refactoring existing ones to meet regulatory requirements while fostering innovation and competition.
• Trade-offs: The authors note that implementing these tactics often involves trade-offs with other quality attributes, particularly security, privacy, and confidentiality, which must be carefully managed during the design process.

In conclusion, the paper establishes a foundational link between regulatory policy and software architecture, offering a structured approach to building "fair" and "contestable" digital ecosystems.