Architecture Repository/Domain/Patterns

From mediawiki.org
Jump to navigation Jump to search

Wikimedia logo Wikimedia Architecture Repository
Practice | Strategy | Domain | Systems | Components

Patterns[edit]

Patterns enable us to design for emergence

Last updated: 2021-05-12 by APaskulin (WMF)
Status: Draft

Patterns[edit]

Patterns enable us to design for emergence: create interrelated capabilities that can become greater than the sum of their parts. We focused on patterns that enable stable, predictable, changeable and encapsulated parts. Patterns that let us design a system by focusing on:

  • the data model (the shape of) "knowledge"
  • the parts that deliver the necessary capabilities (things the system does)
  • the relationship between those parts
  • and the structure of their interaction

Wikimedia architecture patterns

The patterns we've explored include:

Canonical data modeling[edit]

A canonical data model is a predictably-structured, technology-agnostic data structure that represents the system as a whole instead of each component having its own representation of the data. Discrete bits of information are interconnected based on relationships between them and contextualized with metadata. This allows users and machines to consume content easily without specifically caring about the underlying technologies driving the system.


Loose coupling[edit]

Loose coupling is the practice of organizing a system into independent, distinct subsystems that communicate with one another to support the complete operation of the system. The implementation of how to split the operation of the system into subsystems depends on the needs of the system, the capabilities it requires, the infrastructure, and the way product and technology teams work together.


Event-based interactions and event sourcing[edit]

The event-based interactions pattern defines the way that subsystems interact with each other in a loosely coupled system. Instead of querying a central database, separate subsystems exchange information publishing and consuming “events”. Each event contains information about a change that has occurred, regardless of where the change originated. These events can be consumed by the rest of the system, allowing each subsystem to remain distinct and encapsulated but still share, subscribe, and respond to operations done by other subsystems.

CQRS[edit]

Differentiating between reading and editing. In the PoV, the current structure inside of MediaWiki is left alone, it is the "trusted source". When changes happen in MW, the new system reacts by getting the necessary information and translating it into the canonical data model. This means the design works for reading but not for editing. If > 90% of the requests are for reads, can editing be a separate part of the system? We're looking at the editing workflow next.

Creates a page with the prefix: Architecture Repository/Domain/Patterns/

Leverage points[edit]

The scope of modernization -- transforming the the world's largest reference website into the world's largest knowledge system -- is monumental. To understand where to focus our time and attention, we've identified three leverage points.

"Folks who do systems analysis have a great belief in “leverage points.” These are places within a complex system where a small shift in one thing can produce big changes in everything." -- Donella Meadows

However we approach it, the first step is a doozy. There is no iterative path towards transformation. Neither is there a lift-and-shift migration option. We need to find capabilities in the system that we can decouple from the current day-to-day operations. As challenging as leverage points may be to find and to change, they unlock highly-valuable opportunities. While simultaneously laying a strong and cohesive foundation for the future system.

The leverage points explored so far include:

Giving shape and structure to Knowledge[edit]

Honestly, we don't know if it's humanly possible to "structure" Wikipedia content sufficiently. the knowledge we want to share with the world isn't made for modern distributions. We must try. Also, knowledge is currently shaped by the context of "web page" and that doesn't fit emerging contexts.

Designing inherent relationships between knowledge parts to create collections[edit]

Collections are relationships developed, programmatically or by editors, between pieces of knowledge. The way humans envision and plan these relationships shapes the way the knowledge is developed. The PoV pre-builds the knowledge payload (an answer to the queries) based on the relationships we know are the most valued. How would we expand this over time?

Building decoupled relationships between parts of the system[edit]

Rather than building capabilities into the software. This includes changing the choreography of essential activities ... in many ways, the paradigm itself is changing.

Exploring patterns and identifying leverage points helped us prioritize questions that need our attention.