Architecture practice

How we define architecture and the role of the architect

Last updated: 2023-06-14 by APaskulin (WMF)
Status: Deprecated

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, prototyper, 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-untaken 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. A built system has integrity when all of the key decisions (those decisions that influence the system's identity as a whole) emerge from a shared understanding of, and commitment to, a system vision. We work with other roles to draw out and clarify the system vision, the whole that is greater than the sum of the parts, and further work with them to conceive of the parts and their relationships such that their dynamic functioning realizes the desired outcomes of the whole system.

Adjacent to engineering

Architecture does not replace or supersede engineering leadership. 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):

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?
Improving flow: Does the change improve the flow of knowledge? Does it reflect modern (content) systems best practices?
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?”