Next Architecture Workflow

Attributes

Problem Statements

1. Cross-functional prioritization framework allocates some amount of time towards maintenance activities. It is not prescriptive regarding how Engineering Managers and Engineers might coordinate across multiple teams to execute on large-scale cross-functional projects like those defined by architecture evolution blueprints.
2. Architecture Evolution Workflow is complex, and has many steps that make it difficult to adopt the workflow and to succeed with with using it to deliver larger, long-term initiatives.
3. In its current form, the Architecture Evolution Workflow is not leveraged for many initiatives within departments of Engineering. Without a unified roadmap of our own, it is difficult to weigh priorities against Product’s own roadmap.

Exit Criteria

The charter of this working group is to define and implement the next iteration of the Architecture Evolution Workflow.

We want to make it easier and more intuitive to use the Workflow, but also to improve the process itself, to position team members better for delivering great results by using it.

• Firm up the definition of “Architecture” and “Blueprint” in this context.
• Take inventory of current and historical Engineering Allocation initiatives and evaluate the extent to which such initiatives could be defined as blueprints, following the Architecture Evolution Workflow.
• Lower the entry barrier for creating a proposal in a blueprint.
• Establish criteria for when a blueprint should be used.
• Identify cross-functional touchpoints and consolidate upstream processes like production readiness, AppSec reviews, and creation of release posts.
• Develop strategy for incorporating this process and the Engineering roadmap into Product planning and prioritization via the Cross-functional Prioritization framework.

Context

• The Architecture Evolution Workflow is complex, spans multiple tools and projects, and is not something external contributors can participate in.
• Architecture Blueprints provide great context and detail, but they are completely disconnected from Product prioritization and thus rarely picked up into the workstream.
• Working Groups involving technical initiatives have a low rate of success. Many choose to produce blueprints as part of their exit criteria, but blueprints are not standard and do very little to ensure the work gets done.
• Cross-functional Prioritization aims to replace Engineering Allocations but is not prescriptive regarding how efforts involving engineers across multiple Product stages will be coordinated.

The following recording from the Rate Limit Architecture Working Group included some organic discussion around this topic as we attempt to redefine exit criteria that will result in a successful implementation after the working group concludes:

Note: the video is private. Try this link if the embedded video is not playable.

Prior Efforts

Architecture Kickoff Working Group

The Architecture Kickoff working group was primarily concerned with defining a 3/6/12-month technical roadmap. This working group picks up by further iterating on the process for maintaining this roadmap over time and better facilitating its implementation.

Special Interest Groups

We have previously attempted to introduce a new organizational structure for facilitating cross-functional work in the form of Special Interest Groups (SIGs) (see gitlab-com/www-gitlab-com!104378), but it was difficult to demonstrate incremental value with this approach.

We hope to see more success by focusing on the consolidation and streamlining of existing process and improving the success rate of working groups in their current form first.

Roles and Responsibilities

View page source - Edit this page - please contribute.