Autonomy, Architecture Owners, and a Mandated Schema
Helios Health's member-claims team has nine people and an 18-month roadmap. The team's architecture owner is a senior developer who spends 60% of her time on the team and 40% on a platform group. The enterprise architect has published a mandatory event schema for the shared eligibility API; the team's architecture owner believes the schema will add about five weeks and block a six-week regulatory feature. The product owner wants to ship the feature on time and asks the team lead to 'use DA autonomy' and bypass the schema. The platform architect counters that DA gives architecture owners authority and that any deviation needs his sign-off. The team lead asks you to referee.
1. Who owns the architecture decision in DA, and how do you referee this dispute?
Read the worked answer
DA assigns the architecture owner role at the team level, but architecture is not sovereign within a team when a shared platform and enterprise standards are involved. The team's architecture owner owns the team's design decisions and is accountable for proving the design in code; the enterprise architect owns cross-team standards and the evolution of the shared API. The dispute is not 'autonomy versus authority' but a missing decision-rights agreement.
Referee by separating two questions: (1) Is the mandatory schema fit for purpose for this feature? (2) If not, what is the exception path and who bears the cost? Convene the team architecture owner, the enterprise architect, and the product owner; require a one-page decision record with options, cost, risk, and a review date. If the schema stands, the five-week estimate becomes a planning fact, not a negotiation. If an exception is granted, set a sunset date and a migration obligation.
2. The product owner wants to bypass the schema to hit a six-week regulatory deadline. What options do you put on the table, and what do you recommend?
Read the worked answer
Put three options on the table with explicit consequences. Option A: comply with the schema and re-scope the feature to fit six weeks; this protects the platform standard but may cut regulatory scope - verify with compliance whether the cut is permissible. Option B: request a time-boxed exception with a documented deviation, a migration plan, and a named owner; this hits the date but adds future rework and platform risk. Option C: split the feature so the regulatory-critical path uses the schema and a non-critical path waits.
Recommend A if compliance confirms the reduced scope is acceptable; otherwise B with a hard sunset. Do not recommend a silent bypass: it trades a short-term date for an integration defect and erodes the architecture owner's credibility. The decision record should state who accepted the risk and when it will be revisited. This is DA's pragmatism with transparency, not autonomy as veto.
3. What practices would prevent this from recurring, and how would you know they are working?
Read the worked answer
Establish an architecture owner forum that meets weekly with the enterprise architect, with a standing agenda of upcoming features, schema changes, and exception requests. Add an architecture runway item to the team's backlog so schema work is planned, not discovered. Require 'prove it with code' spikes for contested schema decisions, time-boxed to a few days, so estimates like five weeks are tested rather than asserted. Publish a decision log with owners and review dates.
Measure: number of exception requests, time to resolve architecture decisions, and rework caused by late schema changes. If decisions still take more than a week or exceptions rise, the forum lacks authority; escalate to the program level. Review after one quarter.