Three Peaks
Mountains are massive, permanent, immovable structures. They define landscape, resist change, persist across timescales that render other features temporary. Systems have mountain-like components—core data models lasting decades, foundational architectures resisting modification, legacy systems outliving their creators. These mountains shape everything built around them. Routes go around mountains, not through them. Systems adapt to mountains rather than moving them. The mountain is not failure—it's reality. The legacy mainframe won't be replaced. The fundamental data model won't be redesigned. The monolithic core won't be refactored. Effective design acknowledges mountains and works with them. Futile design attempts to move mountains and fails exhaustively trying.
Mountains exist on geological timescales. They form over millions of years. They erode over millions more. Human timescales are irrelevant to mountain timescales. Systems have similar timescale disparities. Core banking systems operate on 30-year timescales. Mobile apps operate on 3-month timescales. The timescale mismatch creates architectural permanence.
The 30-year system is mountain to 3-month system. Attempting to change the mountain is futile. The mountain existed before current developers. It will exist after they leave. The effective approach is building around the mountain—wrapping it, routing around it, integrating with it—not attempting to move it.
Understanding timescales prevents futile efforts. This component is mountain—it won't change within project timeline. This component is temporary—it will change or disappear. The design should match timescale reality. Permanent components justify stable integration. Temporary components justify loose coupling allowing replacement.
Mountains are central features. Rivers flow around them. Roads wind around them. Weather patterns organize around them. The mountain is load-bearing structure for entire landscape. Systems have similar load-bearing components. Core databases everything depends on. Authentication systems all services use. Primary APIs entire ecosystems integrate with.
The load-bearing centrality makes changes expensive. Moving mountain requires rerouting everything. Changing core database requires migrating all dependent services. Modifying primary API breaks all integrations. The change cost is proportional to dependency count. The highly-central component is expensive to change.
Managing load-bearing components requires stability. Minimize changes. Maintain backward compatibility religiously. Version carefully. The stability enables dependent components to rely on mountain without constant adaptation. The unstable load-bearing component creates ecosystem chaos as everything depending on it must constantly adapt.
Mountains are visible from distance. Landmarks for navigation. Reference points for location. Systems have similar highly-visible components. The components everyone knows about. The systems mentioned in every architecture discussion. The services with universal name recognition.
The visibility creates political constraints. Changing visible mountain is politically difficult. Stakeholders have opinions. Users have expectations. The change becomes organizational issue, not just technical one. The invisible component can be changed quietly. The mountain requires communication, consensus, change management.
But visibility isn't burden—it's asset. The mountain's visibility makes it navigable. Users know where to find it. Developers know how to integrate with it. Documentation is available because mountain is important enough to document. The visibility creates accessibility that hidden components lack.
Mountains form through gradual accumulation—tectonic forces, volcanic deposits, sedimentary layering. The formation is slow but creates massive result. Systems have similar accumulation. Legacy code accumulates from many contributions. Technical debt accumulates from many shortcuts. Complexity accumulates from many features.
The accumulation is incremental. Each addition seems small. Over decades, the mountain emerges. The legacy system wasn't built as monolith—it accumulated into one. The technical debt wasn't created in single decision—it accumulated through many decisions. The complexity didn't emerge from single feature—it accumulated through many features.
Preventing mountain formation requires resisting accumulation. Don't add to legacy system—build replacement. Don't accumulate debt—pay it continuously. Don't add complexity—simplify while adding features. The prevention is ongoing discipline, not one-time effort. Without discipline, accumulation is inevitable.
Mountains erode but slowly. Weathering gradually reduces elevation over geological time. The erosion is imperceptible on human timescales but inevitable on geological ones. Systems have similar long-term degradation. Legacy systems gradually lose maintainability. Technologies gradually become obsolete. Skills gradually become rare.
The erosion resistance makes mountains seem permanent on human timescales. The mainframe seems immortal because its erosion happens slower than career timescales. But eventual obsolescence is certain. The question is when, not whether. The mountain will erode. The legacy system will retire. The timeline might be longer than individuals' careers but it's not infinite.
Planning for eventual erosion requires long-term thinking. The mainframe might last another 20 years. Plan gradual migration, not emergency replacement. The legacy system might persist through current project. Design new system to outlive legacy, not assume legacy disappears. The erosion timeline determines migration strategy urgency.
Mountains present choice—climb over or go around. Climbing is direct but difficult. Circumventing is indirect but easier. The choice depends on terrain and urgency. Sometimes crossing mountain is necessary. Often routing around is preferable.
Systems face similar choices with legacy components. Modify legacy system (climbing) or build around it (circumventing)? Climbing is direct—change what exists. Circumventing is indirect—work with what exists. The choice depends on change urgency and difficulty.
Climbing makes sense when modification is feasible and necessary. The legacy system must change. Changing it is possible. Invest in climb. Circumventing makes sense when modification is infeasible or unnecessary. The legacy works as-is. Build around it rather than through it. Wrap it. Integrate with it. Leave it unchanged while adding new capability around it.
Mountains have peaks and valleys. The peak is challenging to reach. Valleys are accessible. Systems similarly have difficulty gradients. Core functionality is summit—hard to reach, harder to modify. Peripheral features are valleys—accessible and modifiable.
The gradient determines approach. Summit requires preparation, planning, specialized skills. Casual changes fail. Valley permits experimentation. Rapid iteration works. The design should match approach to terrain. Don't attempt summit casual changes. Don't over-prepare for valley changes.
But summit holds critical functionality. The difficulty is not obstacle to ignore—it's protection for critical component. The difficulty prevents casual breaking changes. The barrier serves protective function. Make summit accessible when necessary but maintain difficulty barrier preventing careless modification.
Mountains exist in ranges—multiple peaks forming connected system. The range creates ecosystem with interdependencies. Rivers flow from range. Weather patterns organize around it. Wildlife adapts to it. Systems similarly have component ecosystems. Multiple legacy systems forming interconnected enterprise landscape.
The ecosystem perspective prevents isolated optimization. Changing one mountain affects others through water flow, weather, connected wildlife. Changing one legacy system affects others through shared data, integrated workflows, common users. The ecosystem must be understood holistically, not one mountain at a time.
Managing ecosystem requires coordination. Changes must consider cross-mountain effects. Migration of one system must account for integrations with others. The individual optimization that breaks ecosystem is failure even if individual component improves. The ecosystem health matters more than individual peak elevation.
Living near mountains requires adaptation. Build appropriately. Use mountain for resources. Work with terrain, not against it. Attempting to remove mountain is futile. Adapting to mountain's presence is practical. Systems should similarly adapt to legacy mountains.
The adapted architecture wraps legacy. Uses legacy for what it does well. Routes around legacy limitations. The adaptation acknowledges reality—legacy exists, will continue existing, must be incorporated into design. The adapted design functions despite legacy, not after legacy removal.
But adaptation isn't surrender. It's pragmatism. The mountain exists. Railing against existence is pointless. Building considering mountain's presence is effective. The adapted design might not be ideal architecture if starting fresh. It is best achievable architecture given actual constraints. Perfect is enemy of good. Adapted is superior to futile attempts at ideal.