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 fallacy assumes a distributed system operates under unified administrative control where one person or team makes coordinated decisions about configuration, deployment, security policies, and operational procedures.
In practice, distributed systems inevitably span multiple administrative domains:
- Different product teams manage different services with independent roadmaps
- External vendors control third-party APIs with their own deployment schedules
- Cloud providers manage infrastructure on their own timelines
- Security, network, and database teams each enforce domain-specific policies
These domains differ across several dimensions:
- Access controls — one team deploys to production immediately; another requires multi-stage approvals
- Maintenance windows — one service schedules Sunday downtime; a dependent service maintains 24/7 availability
- Change cadence — one team uses continuous deployment (hourly); another follows monthly release cycles
- Security policies — one domain requires specific TLS cipher suites; another still uses legacy protocols
By contrast, monolithic applications operate within a more cohesive administrative scope. While not literally one person, a single operations team, one DBA group, and one change approval process share aligned incentives and communication channels. Distribution breaks this coherence.
Cross-organizational boundaries add further complexity: third-party APIs may deploy breaking changes without notice, implement rate limits that conflict with your usage patterns, or deprecate APIs on timelines misaligned with your roadmap. Within large organizations, Conway’s Law creates analogous boundaries—a payments team with PCI-DSS controls and a recommendation team with rapid experimentation cycles are administratively heterogeneous even within one company.
Addressing this fallacy requires coordination mechanisms built into the architecture:
- SLAs — formalize expectations across domains (uptime, response times, maintenance windows)
- Circuit breakers and timeouts — protect against decisions made by other administrators
- API versioning — allows gradual migration across different teams’ release timelines
- Incident management processes — coordinate response across teams with different on-call rotations
Why This Matters
Ignoring this fallacy produces operational and political failures: a database team schedules maintenance during peak traffic because they were unaware of business-critical processing windows; frontend deploys new API calls that backend hasn’t approved for production; a security incident requires coordinating access across infrastructure, application, database, and network teams with different procedures and access levels.
The complexity multiplies in distributed architectures—a microservices system with 50 services may involve 10 product teams plus separate platform, database, networking, and security teams. Changes requiring cross-domain coordination are routine rather than exceptional. Architectures that acknowledge multiple administrators build coordination into the design; those that assume unified control become operationally fragile when dependencies change unexpectedly.
Related Concepts
- Fallacies-of-Distributed-Computing — The complete set of eight fallacies this belongs to
- Fallacy-The-Topology-Never-Changes — Related fallacy about infrastructure change assumptions
- Monolithic-vs-Distributed-Architectures — The architectural decision this fallacy impacts
- Conway’s-Law — Organizational structure creates administrative boundaries
- Architectural-Governance — Governance mechanisms coordinate across administrative domains
- Operational-Characteristics — Maintainability and deployability affected by administrative boundaries
- Trade-Offs-and-Least-Worst-Architecture — Administrative coordination exemplifies architectural trade-offs
Sources
-
Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Chapter 9: Foundations
- Discusses the Fallacies of Distributed Computing and their architectural implications
- Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
-
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.