Architecture Repository/Process/Services for projects and teams
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Services for projects and teams
[edit]Architecture process
Last updated: 2023-06-14 by APaskulin (WMF)
Status: Deprecated
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 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. We encourage teams to reach out early in the planning process so that we can help you shape the decision overview document.
Key concepts: There are three ways that we can help, when we engage with other roles designing change.
- 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?
- 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?
- 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
[edit]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:
- Including a brief top-down evaluation describing:
- Why a change is valuable and
- What the system will do to deliver that value and
- Who is the “user” gaining the value
- Modeling the work in the context of the system’s goals as a whole (breaking down siloed thinking)
- Workshopping “systems thinking” approaches
Capabilities
[edit]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
[edit]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.
Event modeling
[edit]We often engage teams in event modeling exercises using a virtual whiteboard tool such as Mural. Event storming helps us collaboratively model the domain of a system. It can also help us understand how components and capabilities fit into the overall system.