A few weeks ago, my colleague Stéphane Vanrechem published a blog announcing his new landscape report for enterprise architecture (EA) tools. Pointing to it in a LinkedIn post (as we do), he made the statement that “an enterprise architecture tool is essential for achieving a successful architecture practice.”
Well, that seemingly innocuous statement roused some interesting responses. A couple folks argued that an EA tool was in fact not essential. “An enterprise architecture can be done by hand on butchers’ paper,” one asserted. Others pointed out that such tools often had poor data completeness and quality.
While I agree that data quality is an ongoing issue for all tools intended to manage the “business of IT,” I’m going to argue that, increasingly, automated tools are essential to the modern EA practice, as it is evolving. What I see is that EA is going through a historic transition, from centering on design to focusing on data and insights to drive better portfolio decisions.
Recently, a senior architect said to me, “It’s really no longer about drawing pictures. It’s about analyzing reports.” This is consistent with many conversations I’m having with leading EA organizations.
The EA drawing and design tools (those based on UML, ArchiMate, and older visual notations) historically were sandboxes, not even production-class. They were and are primarily used to model future-state. Today, however, EA organizations increasingly are building dashboards and working more and more closely with their peers in portfolio management to understand critical concerns like technical debt, sprawl, and lack of resilience. They are collecting and integrating information from an increasing variety of tools: CMDB, discovery, software asset management, ITSM/ESM, availability, DevOps toolchains, and more. The resulting analysis is fed back into portfolio planning and even individual product backlog decisioning for powerful closed-loop support.
Forrester terms the overall data and systems architecture needed for this as the “IT control plane.” Longtime followers and colleagues will recognize this as related to the IT4IT framework to which I have contributed.
As the IT profession continues to mature, and digital portfolios become more and more critical, there is more and more interest in an insights-led approach. FinOps (and IT finance generally), value stream management, AIOps, strategic portfolio management (SPM), and data-driven EA are all expressions of this need. All are data-hungry and call for the integration of multiple production systems to support their analytics. EA and SPM in particular seem to be increasingly close, as SPM evolves beyond project portfolio management’s fixation on capex project delivery to longer-range strategic value including opex, as well.
And then came generative AI … genAI, and AI generally, are throwing gasoline on this fire. Their promise is immense for the IT control plane. But you need data. You need tools that can integrate and analyze significant volumes of diverse data, and vendors are stepping up to this demand quickly. Will you be left behind?
So yes, if you are operating EA at any kind of scale, you do need a tool. You should be measured and judicious in the data you choose to manage in it — a smaller set of well-governed data is far superior to a sprawling, incomplete mess, and there I agree with the critics. (If you have ongoing problems with data quality in your EA tool, spend some time with the Data Management Body of Knowledge.)
Where does this leave diagramming and visualization? Well, since a substantial portion of our brains are devoted to the parallel processing of our visual cortex, visualization will always be important. Integrating visual artifacts with tabular reporting will remain a bit challenging, since visualization is often used to model the future state and it might not make sense to represent speculative architectures in an IT portfolio. There’s no silver bullet for that problem. A design sandbox, by definition, is not a place to obsess over data quality.
But the large, complex IT portfolio in many cases isn’t a great candidate for visualization. Pictures abound on the internet of “messy” architectures with dozens or hundreds of boxes and lines. (Sometimes, people say such diagrams represent “bad” architecture. I’ll argue that the only thing we know is that they are poorly scoped visualizations, given the limitations of human visual processing.) At the very least, you need a visualization tool based on intelligent graph queries that only pull in the context that you are trying to make sense of — not the whole portfolio.
Rather than trying to make any sense of such artifacts, the wise, modern enterprise architect knows to start running reports: Technical obsolescence, sentiment, SBOM choices, availability and resilience histories, and so much more is available, if you invest the time and effort to integrate it into a valuable information store for analysis.
