Wikimedia Architecture Team

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

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.