A presentation about the pros and cons of autonomous organization in software projects, its effects on architecture, the reasons it sometimes fails, and thoughts on what to do about it.
the rules and principles that govern their design and evolution Whatever the architect considers important enough to merit their attention Decisions that you want to be correct because they are costly to change
individuals what they can accomplish by their own initiative and industry and give it to the community, so also it is an injustice and at the same time a grave evil and disturbance of right order to assign to a greater and higher association what lesser and subordinate organizations can do. […] The supreme authority of the State ought, therefore, to let subordinate groups handle matters and concerns of lesser importance, which would otherwise dissipate its efforts greatly. Thereby the State will more freely, powerfully, and effectively do all those things that belong to it alone because it alone can do them: directing, watching, urging, restraining, as occasion requires and necessity demands. Subsidiarity Pope Pius XI, Encyclical Quadragesimo anno, 1931 Autonomy Centralization
teams Observation(s): • Lack of front-end expertise led to central UI/design team, bottleneck for development, deployment, operations, evolution Lesson(s) learned: • Local optimization needs can trigger centralization • Full stack teams require full stack capabilities
teams Observation(s): • Extremely inefficient UI integration runtime due to lack of standardization • Vast differences in API style, formats, documentation Lesson(s) learned: • Complete lack of guidance creates unproductive diversity
team Observation(s): • Potential for independent decisions in separated systems (almost) never exploited • Engineering effort spent on coordination Lesson(s) learned: • Premature modularization can lead to increased effort without matching benefits
teams Observation(s): • Common standard micro architecture at start of project • Gradual increase in degrees of freedom • Increase in actual diversity of tools, languages, architecture Lesson(s) learned: • Increased maturity allows for less dogma/fewer rules
teams Observation(s): • Inside-out development of rich, multi-faceted, highly functional platform, sophisticated tool support for developing platform applications • Teams resist perceived proprietary, complex, useless platform • Ultimate decommissioning of platform after MM€ investment Lesson(s) learned: • Platform development as high risk activity
teams Observation(s): • Common standard platform and team to support other teams • Standardized CI/CD pipeline & runtime platform • Severe inefficiencies due to one-size-fits-all platform (esp. DB) • Continuous fighting between teams and platform engineering Lesson(s) learned: • Platform teams can take on a significant life of their own
Observation(s): • Strategic decision to outsource platform to external party (public cloud provider) • 100% “all-in” strategy (no worries about vendor lock-in) Lesson(s) learned: • Significantly decreased emotional attachment to platform • Underestimated need for platform expertise