From Building Towers, to Building Bridges

The ivory tower has fallen.
This is the era of JEJIT (Just-Enough-Just-In-Time) Architecture
Agile changed our understanding of what software development actually is.
As a consequence, the ivory tower had to fall. Agile-ism has rightly destroyed much of the architecture ivory tower, and we (architects) should celebrate that.
Fact: Architects must stop pretending that uncertainty disappears because someone has produced a detailed 200-page target-state document (after disappearing into a room for three or even six months!). Meanwhile, the product teams were waiting, the business was waiting, the market was changing.
Business IT systems live in environments full of uncertainty. Requirements change. Customers behave differently than expected. Technologies mature. Regulations appear. Acquisitions happen. Strategies change. Teams reorganise.
➡️ The alternative is what I call JEJIT Architecture: Just-Enough, Just-In-Time Architecture.
Just Enough:
· Don't solve architectural problems that aren't real yet.
· Don't introduce five layers because “we might need them.”
· Don't create a platform abstraction because another team might someday use it.
· Don't split a system into 37 services because the organisation may eventually scale.
· Don't build a comprehensive enterprise canonical model before understanding what data actually needs to be shared.
Just in Time: make it before the architectural decision at the last responsible moment, just before it becomes expensive to change.
Whilst the old ivory-tower model often treated architecture as a thing (a document, a target state, a set of diagrams, a governance process), JEJIT treats architecture as a continuous decision-making activity.
🌉 The architect's job changes too: the JEJIT architect is more like a builder or bridges.
The bridge represents architecture that connects: business and technology, strategy and execution, teams and systems, today’s reality and tomorrow’s possibilities.
The modern architect’s job isn't to sit above the teams and dictate how everything should be built; it is to create the connections, guardrails and pathways that help teams move safely and quickly from where they are to where they need to be.
Don't build towers of architecture. Build bridges that enable movement.
The bridge builder architect spends less time drawing the final system and more time creating the conditions for the system to evolve well. That's a much harder job.
Anyone can produce a giant architecture diagram. The difficult question is: What is the minimum architecture we need right now to avoid creating a future disaster?
⚠️ WARNING: JEJIT requires more architecture thinking, not less.



Comments