A recent Wall Street Journal article (https://www.wsj.com/articles/get-rid-of-the-it-department-11637605133) observed that the traditional Information Technology (IT) setup under a Chief Information Officer (CIO) has outlived its usefulness. One of the main drivers for this is that IT is no longer something that can only be the responsibility of a single department. Instead, because of the emergence of what Gartner calls “Business Technologists” who operate within the different lines of business, a new, much more federated approach to IT management (and therefore Enterprise Architecture as well) will be required in the future.

Within the traditional CIO-led IT department, EA has been a discipline difficult to understand and mature, even if started with initial, high-level support. Starting about 20 years ago, it has been promoted globally as a critical pillar to help organizations transform enterprise-wide instead of mainly within silos. Therefore, the implication was that it would be a centrally managed team of cross-domain experts (i.e., business, data, application, and technology architects) working most likely under the CIO/CTO.

However, even TOGAF (The Open Group Architecture Framework), which is the most widely known and taught EA framework, never explicitly indicated that such a central operating model was the default. The TOGAF Standard, Version 9.2 (https://pubs.opengroup.org/architecture/togaf9-doc/arch/ ) underscores that the decision on how to establish the EA team and organization is a critical one. However, TOGAF doesn’t lay out how to do so, other than to say the approach should be congruent with the other governance and management methods being used in the organization.

This gap in TOGAF has been addressed to a greater degree in some TOGAF Series Guides available at https://opengroup.org, (e.g., https://publications.opengroup.org/guides/togaf/togaf-series-guides/g186 ), but ultimately considered customization will need to be done for each organization. TOGAF does mention that a federated approach could be a good option for some organizations, while never explicitly explaining how to accomplish its recommended step to “Establish the EA Team and Organization.” I have seen many organizations switching from a centralized approach to a more federated one and then re-grouping to find a better balance.

An example would be where common standards for process and modeling (including common EA applications) are used and where the Principal and Domain Architects supporting the lines of business directly also dual report to a Chief Enterprise Architect.

It turns out that such customization is more of an art than a science, although one can experiment with different hypotheses surrounding some common architecture goals, services, and principles. Now, with the rapid expansion of agile approaches within specialty areas, and with increasing use of software-as-a-service in enterprises – often driven by the “need for speed” and specialized use, the future structure and role of IT and EA Management for Digital Transformation will remain in flux. Of course, IT and EA Management are not going away, but new business and operation models will require increasing innovation and flexibility and even more daunting governance challenges…for additional architecture enablers to possibly address.

Authored by Dr. Steve Else, Chief Architect & Principal Instructor