This episode of The Wired Garage with Pops is a roundtable with three “recovering” enterprise architects discussing what enterprise architecture really looks like in practice over a career. They frame EA less as a job title and more as a mindset that bridges business strategy with the messy reality of technology, legacy systems, and organizational behavior. The conversation covers recognizing “messy” enterprises, saying no (or “not yet”) to cool tech like AI and new platforms, governance and decision frameworks, empathy and frontline experience, and how their beliefs and communication styles have evolved.

• EA is a mindset, not a title. You don’t stop being an architect when the job title changes; it’s a way of thinking that follows you into leadership, platform ownership, and solution delivery. Architecture is as much about people, context, timing, and decisions as it is about diagrams and standards.
• What makes an enterprise “messy”? “Messy” isn’t just lots of tech; it’s unclear decision-making, weak governance, overlapping tools, and skills spread too thin across too many platforms. Mergers, half-in/half-out cloud moves, redundant monitoring tools, and fragmented information repositories all contribute to mess over time, often from good intentions. A clean decision structure and a clear plan can coexist with temporary mess; the real danger is unmanaged complexity and poor visibility, especially for security.
• Role of the architect: giraffe, not wizard. A good architect is like a giraffe on safari: they see farther, spot danger early, and buy the organization time to choose options instead of reacting in panic. The value is in anticipating issues, proposing options (hybrid models, phased approaches), and structuring decisions so mess is prevented or at least contained.
• Saying “no” (or “how”) to cool tech. Often the right call is to say “not yet” to AI, new SaaS, or hot platforms when knowledge management, data quality, or operating models aren’t ready. The architect’s job isn’t simply “no”; it’s reframing the conversation to “how do we get there?” with a realistic path, timeline, and alignment to business priorities. Start with business outcomes and capabilities, then choose solutions and platforms last; starting from tools locks you in and reduces long-term flexibility.
• Governance, frameworks, and alignment. Using themes, epics, and idea portals helps ensure every piece of work ties back to business strategy and prevents scattered, one-off projects. Any governance framework can work, but the critical part is using it consistently so decisions are traceable and you can understand and revisit past choices. Feedback loops and organizational change management are needed early and often, so you can see how decisions play out (e.g., a 3‑day install becoming 14).
• Empathy, communication, and frontline experience. They stress empathy: everything in IT is in service to someone, and it’s easy to forget that if you never see real users. Frontline roles (help desk, service desk, customer success) are invaluable; going back periodically keeps you grounded in how people actually experience your systems. One example: a CMDB/CSDM explanation was reframed as a ballet analogy tailored to an executive’s interests, which made the concept finally stick. Great architects practice empathetic storytelling—knowing the audience, choosing the right narrative, and over-communicating during change.
• Avoiding “villain” status between business and IT. Architects often sit between business leaders demanding outcomes and IT teams building and running systems, which can make them the perceived “villain.” Transparency in how decisions are made, involving engineers early, and allowing people to see and participate in the conversation builds trust even when the ans

Support the show