By Leonard Greski, Chief Scientist, LiminalArc
I read Holt Hackney’s July 2026 article Researchers: CIOs Should Define Enterprise Architect Roles More Clearly shortly after it was published. He led the article by restating the main point from the Info-Tech Research Group’s report, “Build a Better Enterprise Architect,” organizations should define the enterprise architect role more narrowly and tie it to measurable business outcomes. [1]
Info-Tech’s original research recommends a three-phase process to developing and defining the role. Their research fails to address the fact that ambiguity in the enterprise architect role is a symptom, not a root cause of failures in the ability of enterprise architecture departments’ ability to demonstrate value.
Why?
If you pit a good performer against a bad system, the system will win almost every time.
- Geary Rummler & Alan Brache [2]
Adoption of the Info-Tech recommendations will not solve the absence of value problem for two main reasons:
- A systems problem requires a systems solution, and
- Architecture departments have little accountability for results.
A Systems Problem
Within the context of connecting an organization’s strategy to business results, we define a system as a mechanism to manage a flow of work with a clearly defined structure, governance, that is measured by a set of metrics. The Enterprise Architect role is a valid role within a larger system of delivery that builds and enhances the capabilities of an organization. However, specifying this role in isolation from the larger system (the other roles, the units of work being managed, the work states and definitions of done, and their associated measurements) is insufficient to make a significant impact on the larger system.
A Lack of Accountability for Results
The second major gap that the original research report fails to address is that in most companies, the Enterprise Architecture department is not directly accountable for business results. Therefore, Enterprise Architecture is not considered a major contributor to economic value in a firm. The function must earn its way to a seat at the executive decision-making table through indirect influence, a process that typically takes years to develop. The definition of one role does little to foster the trust necessary to establish influence.
Reality Bats Last
The consequences of Enterprise Architecture centric prescriptions to solving the problem of lack of access and influence with corporate executives are legion. Over the last twenty years, architecture departments have experienced multiple iterations of being established, marketed, grown and consolidated when anticipated benefits failed to be realized. Unless architecture leaders take a systems-first view of their credibility problem they are doomed to repeat the failure cycle.
A Different Prescription: Systems First
The way to break the cycle of failure in Enterprise Architecture is to start by fixing the system, the one that’s used to build and enhance products or capabilities within an organization. It requires a focus on three fundamentals: teams, work backlogs, and frequent delivery of working tested capability to customers and/or end users, as I previously described in The Future of Agile Isn’t ‘agile.’ [3]
The process starts with defining a future state system of delivery where teams are organized around products or capabilities. Establish its structure (roles, responsibility, accountability and authority), units of work and governance (Kanban states, definitions of ready and done), and metrics (measures of business outcomes as well as flow).
Pilot the new system with a vertical slice of the organization, staffed with dedicated team members from multiple disciplines to maximize accountability for results. As the pilot group begins to generate results, expand the implementation with additional vertical slices of the organization.
Notice that “enterprise architecture” isn’t named directly in the prescription. When enterprise architecture is effectively integrated into a larger system of delivery, it stops being the proverbial “fifth wheel,” and starts contributing to business results by serving as an objective guide to decision-making about business and technology capabilities.
Len has over 30 years of experience helping large organizations generate billions of dollars in economic value by leading high risk, high visibility business and digital
transformations. In his role as Chief Scientist at LiminalArc, Len leads the development of new service offerings that enable customers to organize around business capabilities, build products and services that customers love to use, and improve operational efficiency. He also leads engagements with large clients to implement AI-enabled legacy systems modernization. Len received Bachelor and Master of Arts degrees in Sociology from the University of Illinois at Chicago with concentrations in Organization Theory, Research Methods and Statistics.
References
[1] Hackney, H. (2026) Researchers: CIOs Should Define Enterprise Architect Roles More Clearly, Architecture & Governance Magazine, July 21, 2026, IASA Global, San Antonio TX.
[2] Rummler, G. and Brache, A. (2013) Improving Performance: How to Manage Whitespace on the Organizational Chart, Wiley & Sons, San Francisco CA.
[3] Greski, Leonard (2025) The Future of Agile Isn’t “agile,” Architecture & Governance Magazine, June 2, 2025, IASA Global, San Antonio TX.