‎

Wikimedia Architecture Repository
Home | Artifacts | Process | Patterns

Enabling strategic product goals with architecture patterns

Shows how modern architecture patterns enable the strategic product goals

Last updated: 2022-12-16 by APaskulin (WMF)
Status: v1 published September 2021

Introduction

This document shows how modern architecture patterns can enable the delivery of new products that align with the strategic product goals.

We’ve included examples of experiences from products that can be enabled by the new systems architecture patterns and concepts. The examples follow the Product Strategy points, as potential narratives of products that will empower our users to contribute through these strategic perspectives.

Architecture patterns

An architectural pattern is a general, reusable approach to a commonly occurring problem in software architecture within a given context. The patterns in the sections below enable the system to be flexible, reusable, and to answer modern technological needs so that we can achieve our strategic goals.

Loose coupling

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.

Related to

While loose coupling dictates the action of separating the system into subsystems, the event-based interactions pattern defines how the subsystems communicate with one another.
A decoupled frontend is an example of loose coupling that relates specifically to the separation between the system behavior and the interface.

Product benefits

Clear domains: Each subsystem can be replaced or swapped with another easily and without disruption to the rest of the system.
Quicker turnaround: The independence of the individual subsystems means that as long as the event structure remains clear, adding or changing behavior is easier and requires less dependence on other teams or groups that manage other subsystems.
More product flexibility: Instead of relying on a single monolithic output that includes all possible views or interfaces, the system can have multiple independent subsystems, each responsible for a separate dedicated purpose.

Event-based interactions

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.

Related to

While loose coupling dictates the action of separating the system into subsystems, the event-based interactions pattern defines how the subsystems communicate with one another.

Product benefits

Clear domains: Each subsystem can be replaced or swapped with another easily and without disruption to the rest of the system.
Quicker turnaround: The independence of the individual subsystems means that as long as the event structure remains clear, adding or changing behavior is easier and requires less dependence on other teams or groups that manage other subsystems.
Preprocessed data: The ability to respond to events as they happen means products can process data asynchronously, constructing powerful, customized outputs to return to users on demand.

Canonical data model

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.

Related to

Knowledge as a service: This strategic initiative transforms knowledge created as a single web page into discrete units of predictably structured information that are interrelated.
Federated API: Defines a unified, consistent response to all API queries regardless of the module or product it requests, while allowing individual subsystems to evolve and change independently.

Product benefits

Structured content: Having an agreed-upon, standardized, technology-agnostic data structure enables the universal structuring of the content across our different products.
Interconnectedness: Each structured data piece includes information about how it relates to other pieces (for example, by keywords, by hierarchy, etc). This enables finding and utilizing context-related links between pieces of information to produce powerful product outputs.

Product examples

New editor experiences: Creating an article

Eleanor is a history student from Costa Rica. She wants to add an article about a historical figure that doesn't have an article in any of the Wikipedia languages yet. She knows many facts about the historical figure and has many references and citations, but she's not sure how to start actually writing.

Eleanor can receive suggestions for links and media that relate to the topic she’s working on, and use these pieces to build the article for her specific notable person. These related images, dictionary definitions, books, and sources can help Eleanor write the article in a way that truly represents the subject matter and demonstrates their contribution to history with citations and links to other topics.

Enabled by these architecture patterns

Canonical data model: Because the content is stored as pieces of information with metadata that interrelates them, the system can help Eleanor discover relevant, structured content based on tags and other metadata.
Loose coupling: The technical ability to have distinct subsystems means that we can use different subsystems to add context to the information for different products and tools, making it easier to iterate and experiment. These tools can assign topics to pieces of content based on Wikidata items, or use other machine-learning operations to contextualize the different pieces of content to be able to fetch specific information that is useful for the needs of the user.

New editor experiences: Editing citations

Jorge is a medical student from Mexico. He wants to add information about a medical condition that relates to the class he just finished. He has three books to reference. He inserts the details of the books into the interface and is presented with a list of pieces of information where the books are referenced within content and images. He uses that information to find other places where citations are needed and adds them.

Enabled by these architecture patterns

Canonical data model: Treating citations as a piece of knowledge rather than “just” metadata to other pieces allows us to utilize them in the search for information, and in the addition of strong verifiable and transparent information.
Event-based interactions: In an event-based interaction, an edit to a page triggers an event. Different subsystems can respond to this event and manipulate the data appropriately. Each edit can be processed to extract the citations as standalone objects, ready to be categorized and contextualized. This means that at the time of fetching, we can give the user a robust experience based on the relationships between the content and the citations themselves.

Campaigns

Beatrice is a lead member of the Women in Red group in France. She wants to organize an editathon on the topic of women in the French revolution. Beatrice uses an interface that allows her to fill in all the keywords, names, and citations that relate to this topic, and is presented with a list of topics and subjects that are missing from the content. She uses this list to construct a work list for the event, so she can easily help new editors joining the editathon focus on needed knowledge gaps in subject matters that are missing. The participants use this list as a guide to adding information that relates to the theme of the event and helps cover knowledge gaps.

Enabled by these architecture patterns

Canonical data model: Storing structured content with tags and other metadata can inform machine learning models that can help identify content gaps and collect relevant content to support content creation campaigns.
Loose coupling: When the system is separated into distinct subsystems, it is easier to add, remove and adjust the level of metadata that is added to individual pieces of content, and the analyses that are relevant for specific products.

Wikipedia in the classroom

Alice is a teacher from South Africa. She wants to write a lesson plan about king protea, the national flower of South Africa. She goes on Wikipedia and looks for the flower’s name and family. She is presented with relevant pieces of information contextually linked to the flower, family, and related information. Alice uses these pieces to build a handout with factoids, citations, and images she can send to her students. She then uses the information to help her construct the lesson plan.

Enabled by these architecture patterns

Canonical data model: Storing structured content with tags and other metadata allows us to create collections of information across projects and discover knowledge in new and surprising ways.
Loose coupling: When the system is decoupled, it’s easy to create another way to view our data, allowing new products and views to be created easily and quickly for a vast array of target audiences.

Conclusion

A paradigm shift into the consumption of knowledge

This document presents a set of architecture patterns and illustrates how these patterns enable new product experiences. The system changes produced by these patterns correspond to a paradigm shift, bringing Wikipedia (and sister projects) into alignment with future technologies.

In our changing technological landscape, consumption of knowledge has evolved away from consuming information as a complete web page to consuming structured, relational fragments of information that can be consumed according to the context. They can be presented sequentially in the context of a full web page, but they can also be consumed separately, as "pieces" of information that are related by contextual links.

As an example, we can see some of that behavior existing in today's internet consumption of our data. For example, Google's sidebar only presents a piece of the lead paragraph of a Wikipedia article, and Alexa and Google Home only speak out pieces of specific relevant sections that answer the question posed to them. The idea of dividing the information into "pieces of knowledge" gives editors the power to control how content is reused regardless of context.

The internet is already starting to treat our vast database of knowledge as distinct pieces, but the decisions about how those pieces look and who controls their content and context are outside of our control. By reconsidering our content as pieces of information (that can live as an article, or as distinct context-related pieces, whatever that may look like) we can reclaim control over our information, and empower our communities to do what they do best -- contribute valid factual information to the sum of all knowledge, to be consumed by modern technologies properly.

Next steps

Add product examples to the narratives section of the Architecture Repository!