Manu's Vault

Fallacy There Is Only One Administrator

6 min readStatus:Seedling

Core Idea

“There is only one administrator” is the sixth of the Fallacies of Distributed Computing—the false assumption that distributed systems operate under unified administrative control with consistent policies, configurations, and procedures. In reality, distributed systems span multiple administrative domains with different administrators, policies, access controls, approval processes, maintenance windows, and operational standards, requiring systems to handle administrative heterogeneity and coordination challenges.

What Is the “There Is Only One Administrator” Fallacy?

The False Assumption: The “there is only one administrator” fallacy is the assumption that a distributed system operates under unified administrative control where a single person or team makes coordinated decisions about configuration, deployment, security policies, and operational procedures.

The Reality - Multiple Administrative Domains: This assumption is false because distributed systems inevitably span multiple administrative domains:

  • Different teams manage different services
  • External vendors control third-party APIs
  • Cloud providers manage infrastructure
  • Security teams enforce policies
  • Network teams control routing
  • Database teams govern data access
  • Each domain operates with different priorities, procedures, change approval processes, and maintenance schedules

Monolithic vs Distributed Administrative Control:

  • Monolithic applications: Administrative control is relatively unified within a single organization
    • One operations team manages the application server
    • One DBA team controls the database
    • Changes coordinated through a single approval process
    • While not literally one person, the administrative domain is cohesive with shared communication channels, aligned incentives, and coordinated procedures
  • Distributed systems: Fundamentally cross administrative boundaries
    • Services communicate with external APIs controlled by other companies
    • Infrastructure spans multiple cloud providers each with their own support teams
    • Microservices owned by different product teams with independent roadmaps
    • Regulatory requirements create administrative separation between regions

Administrative Heterogeneity Dimensions:

  • Access controls: One team can deploy to production immediately while another requires multi-stage approvals
  • Maintenance windows: One service schedules downtime on Sundays while a dependent service maintains 24/7 availability
  • Security policies: One domain requires all traffic encrypted with specific cipher suites while another uses legacy protocols
  • Change management processes: One team uses continuous deployment pushing changes hourly while another follows monthly release cycles
  • Monitoring and alerting: One administrator uses Datadog with PagerDuty escalation while another uses CloudWatch with email notifications

Cross-Organizational Boundary Challenges: When integrating with third-party APIs:

  • No control over their deployment schedules, maintenance windows, or infrastructure changes
  • May deploy breaking changes without warning
  • May implement rate limiting that conflicts with your usage patterns
  • May deprecate APIs on timelines that don’t align with your roadmap

Cloud Provider Control:

  • Schedule VM maintenance on their timeline, not yours
  • Update hypervisors independently
  • Modify network configurations without coordination

Regulatory Compliance Administrative Boundaries:

  • GDPR requires data residency controls administered separately from performance optimization infrastructure
  • HIPAA creates security administration separate from general operations
  • Financial regulations require separated administrative access to audit systems

Conway’s Law and Administrative Domains: Within large organizations, team boundaries create administrative domains:

  • Payments team: Administers payment services with stringent PCI-DSS controls and lengthy change approval processes
  • Recommendation engine team: Administers ML infrastructure with rapid experimentation cycles and relaxed constraints
  • User authentication team: Administers identity services with 24/7 on-call support and zero-downtime deployment requirements
  • Each team optimizes for their domain’s priorities, creating administrative heterogeneity even within one company

Addressing the Fallacy - Coordination Mechanisms and Defensive Design:

  • Service-level agreements (SLAs): Formalize expectations across administrative boundaries, defining uptime commitments, response times, and maintenance windows
  • Circuit breakers and timeouts: Protect systems from administrative decisions in other domains—if an external API deploys a broken version, circuit breakers prevent cascading failures
  • API versioning: Allows gradual migration across administrative timelines—one domain can upgrade to a new version while another continues using the old version during their slower approval cycle
  • Configuration management systems: Provide visibility across administrative domains while respecting access boundaries
  • Incident management processes: Coordinate response across teams—when failures span domains, escalation procedures ensure coordinated resolution despite different on-call rotations and alerting systems

Why This Matters

Operational and Political Failures When Ignored:

  • Systems break when dependencies change without coordination: A database team schedules maintenance during peak traffic because they weren’t aware of business-critical processing windows
  • Deployments fail: Approval processes in different administrative domains aren’t synchronized—frontend deploys new API calls that backend hasn’t yet approved for production
  • Security incidents escalate: Access controls span multiple administrators—responding to a breach requires coordinating with infrastructure, application, database, and network teams, each with different access levels and procedures
  • Performance optimization fails: Administrators optimize locally without global coordination—one team adds caching that breaks another team’s consistency requirements

Multiplied Complexity in Distributed Architectures: The assumption of single administration becomes particularly problematic in distributed architectures because distribution inherently crosses administrative boundaries:

  • Monolith: Might have 2-3 administrative domains (application, database, infrastructure)
  • Microservices system (50 services): Might have 10 different product teams each with administrative control over their services, plus separate platform, database, networking, and security teams
  • Coordinating changes across these domains requires explicit communication and alignment that monolithic systems achieve implicitly through unified administration

Organizational Design Implications: This fallacy drives organizational decisions:

  • “You build it, you run it” models: Companies adopting microservices often distribute administrative responsibility where development teams become administrators for their services
    • Enables autonomy and velocity
    • Requires establishing common standards, service mesh infrastructure, and incident response coordination to prevent fragmentation
  • Platform team centralization: Alternative approach attempting to centralize administration through shared infrastructure
    • Trades autonomy for consistency
  • The choice depends on whether organizational priorities favor autonomy or coordination

Impact on Architecture and Governance: Understanding this fallacy shapes architectural governance and operational characteristics:

  • Architectures acknowledging multiple administrators: Build coordination mechanisms into the system design through SLAs, API contracts, and defensive patterns
  • Architectures assuming unified control: Sacrifice resilience to administrative heterogeneity, creating operational fragility when dependencies change unexpectedly
  • The choice depends on organizational structure and administrative boundaries

Sources

  • Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.

  • Deutsch, Peter (1994-1997). “The Eight Fallacies of Distributed Computing.” Originally articulated at Sun Microsystems.

    • Sixth fallacy in the original list
    • Identified through observing coordination failures across administrative boundaries in distributed systems
    • Widely referenced in distributed systems literature

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks