Wikimedia Architecture Team

If you are looking for information about a previous team that information is available at Wikimedia Architecture Team Legacy.

Members

 * Kate Chapman - Director of Architecture
 * Alex Paskulin - Technical Writer
 * Diana Montalion (contractor) - Architect

Working with us/Need help?
If you have a project that is cross cutting, touches other system components, is a new component or service (or is in other ways complex), please reach out to us at [mailto:architecture@wikimedia.org architecture@wikimedia.org]. We are here to help with design, modeling and designing system level capabilities. Think of us as the third part of the trio of product and engineering.

Defining architecture
In technology, there are as many definitions of "architecture" as there are "architects". This creates confusion about where architecture practices fit into daily life. In this document, we hope to ease that confusion by describing:


 * How we define the role and the practice of the Architecture Team at the Wikimedia Foundation
 * What we are currently focusing on

The role
Key concepts: integrator, sound solutioner, cohesive problem-solving processes developer, map maker, protoyper, experimentor, assumption challenger, creator of conceptual models and champion of healthy systems patterns

We view "architect" as an integrator role, working adjacent to other roles, building conceptual bridges between them. Rather than dictate and direct, we weave relevant expertise with best practices and strategies for systems into sound technological solutions that meet high-priority organization goals. We are not just focused on the tech. We engage change itself, continuously developing cohesive, actionable processes for solving systemic problems. Healthy interactions between people is the key to system success.

We are history aware but usually not focused on holding legacy systems together. Rather, we are future focused, mapping as-yet-taken paths by illuminating both icebergs and opportunities for meaningful change. Most of all, we change the mental models, system structures and patterns that define the behaviors of the software and system itself.

The practice
Key concepts: conceptual artifacts, systems best practices and point of view, different from engineering

The work may seem strictly "high level" but it's not; the work is grounded in logic-driven best practices (like coding) and focused on deliverables (like coding) that will be meaningful to the audience relying on them. We work together in sprints to deliver conceptual artifacts such as models, workshops, diagrams, strategic recommendations, prototypes, etc that will move the system towards its highest-value goals.

Unlike coding, our focus usually precedes literal implementation. Fred Brooks says that “conceptual integrity is the most important element in systems design.” By which, he means, the strength and integrity of our mental models dictate the strength and integrity of our solutions. We work with other roles to ensure that the sum of the parts (software, workflow tools) is greater than the whole.

Adjacent to engineering
Architecture does not replace or supersede engineering leadership. Among brilliant teams of engineers, there is usually no need to "architect" them. Architecture skills are adjacent to engineering and leave appropriate space for implementation design (engineering). Generally speaking, if something can be straightforwardly described and modeled within software, that’s engineering. If the question is "how do we implement this requirement?", that’s usually engineering. Implementation tools are (usually) the purview of engineering. If new functionality is being implemented inside the legacy system, in our case, that’s likely engineering.

Architecture bridges the gaps between one technology point of view and another, or between multiple technology points of view and other points of view, like product. More essentially, we bridge the gap between the solution and/or software and the system as a whole.

Establishing an architecture practice is especially difficult among teams, like ours, where there is little distinction between "software" and "system", or “process” and "product". We hope to draw boundaries and flows that will enable us to create new, emergent patterns.

What we are focused on
Key concepts: When we engage with challenges, we are looking for three opportunities (usually simultaneously):


 * 1) Leverage points: Is there a mental model or pattern that needs changing? For example, consider encapsulation, rather than expansion, of the legacy system. If so, how do we convey that change to others?
 * 2) Improving flow: Does the change improve the flow of knowledge? Does it reflect modern (content) systems best practices?
 * 3) Establishing boundaries and better relationships: Is there an opportunity to improve the relationships between subsystems? (Or, at least, establish the concept of “subsystem” within the current system?)

Discovering leverage points
Not everything can or needs to change today. We are identifying places in the technological (and organizational) system where we can make impactful, high-priority pattern changes that will unlock future potential. These types of changes are leverage points.

Leverage points are often three things: counterintuitive; protected by hyper-controlling systems because they are vulnerable; difficult to describe to people who share a common, opposing view.

Which means, finding and changing leverage points is hard. Much of our work, at the moment, involves saying things like "better encapsulation of MediaWiki is valuable" and then investing many hours demonstrating why that is true and what we can do about it.

Flows
“Knowledge" is our highest-value commodity and we are focused on how knowledge flows across the system. How it flows in; how it flows out and ways we can increase efficiency and effectiveness across the WM ecosystem. Some of the (work)flows are human and some are technology, most are both.

Initially, we are primarily focused on the structure of the knowledge (data) and improving communication patterns between parts of the system. The structure of “content” is the highest-value leverage point at the moment.

Relationships
We are designing better relationships between parts, which is what the word "modernization" usually means. Better relationships require better boundaries (in software and in life). This does not necessarily mean relationships between two pieces of (the same) software. The "wikifarm" model is one model of relationship and in many cases, works well. We are focusing on other types of relationship patterns that may strengthen and improve the system's flows as a whole.

We hope to also envision better ways to relate to, rather than consume, other services we rely on. For example, asking: “Are any of the capabilities and extensions integrated into MW better as standalone services we communicate with?”

How we can help
Key concepts: There are three ways that we can help, when we engage with other roles designing change.


 * 1) Strengthen conceptual integrity: Does the work align with the highest-value capabilities of the organization and its users? Does it contribute to the value of the system as a whole? Does it “hang together” well with other work being done?
 * 2) Deliver capabilities rather than features: Do we clearly understand how the work contributes to the highest-value capabilities delivered by the system as a whole?
 * 3) Decision making: Is the recommendation strong, sound and cohesive? Is the design and approval process clear, navigable and directly connected to relevant expertise? Is the recommendation sound and valid under the circumstances?

Conceptual integrity
The most essential architectural pattern to establish is integrative thinking: the ability to represent a strong, cohesive solution from multiple points of view. This is why we refer to architecture as “bridge building.” Another apt metaphor is “designing the ship everyone can sail in to reach their common destination.” To establish this practice, we are focused on nurturing three behaviors:


 * 1) Including a brief top-down evaluation describing:
 * 2) Why a change is valuable and
 * 3) What the system will do to deliver that value and
 * 4) Who is the “user” gaining the value
 * 5) Modeling the work in the context of the system’s goals as a whole (breaking down siloed thinking)
 * 6) Workshopping “systems thinking” approaches

Capabilities
We encourage describing what people DO, what the system will be capable of, and why that capability is valuable rather than creating “features” that are conceptually isolated. To enable this, we request the opportunity to weigh in on how the change impacts (positively and negatively) the system as a whole and clarify alternatives that may not have been considered.

Decision making
Conway’s Law is truth: The way we structure communication as an organization inherently designs our solutions and the system as a whole.

To be effective, we are strongly focused on improving the way we "architect" solutions by improving the structure of solutioning together. Beginning with structuring recommendations that are more integrative and tolerant of ambiguity, while still actionable and quickly iterative.

We are actively working with engineering and product to understand how best to support organizational decision making without inadvertently rebuilding the same structures that created our legacy system. We are also creating a “system view” framework in which people can position decisions and connect them to other decisions in a more meaningful way.