Content systems architecture: Approaches in a decoupled world

Modern content "management" systems are as conceptually challenging as they are technically difficult. Architecting them isnt (strictly) AWS configuring or software solutioning now. The work requires an evolution from strategic planning to collaborative strategic thinking. Diana Montalion explores "archistructure": enabling everyone to engage with the parts through the lens of the whole.

Ten years ago, content “systems” were primarily content management applications and their kin; wikis, commerce sites, closed-box print applications, etc. Architecture was software solutioning and scaling the infrastructure to handle more traffic. DevOps meant “add Jenkins". Eight months of development work generally required a week or two of architectural deliverables, even when third-party services were involved. Last year, as content systems architect for The Economist, Diana Montalion and her colleagues invested six months articulating the capabilities of the current system and crafting technology recommendations across the multiple engineering and architectural teams. Then they spent another six months designing the high-level target architecture. This work began after they’d delivered a major decoupling effort, so they weren’t starting from scratch. What changed between then and now? The difference between legacy and modern content systems is as conceptual as it is technical. Architecture, and the role of architect, isn’t simply AWS certification. The work requires an evolution from strategic planning to collaborative strategic thinking and everyone seeing the parts through the lens of the whole. It also means defining the technological relationships within an ecosystem, with both strict boundaries and valuable flexibility, while still delivering the work on time. Delivering requires the organization to mirror the desired qualities of the system (a.k.a. the hard part). Diana explores “archistructure”—crafting a project’s architectural portfolio that triggers “just enough” of the right discussions at the right time. You’ll learn about flexible and adaptive tools drawn from EA frameworks, UX approaches, Lean and Agile, with an emphasis on process modeling. How do you map the capabilities (rather than the features) of a system, and why is that important to do? How do you engage engineers, subject-matter experts, and stakeholders in this process until it becomes organic? The goal is to replace management with trusting relationships, inside the system and out.