At a Gartner ITxpo/Symposium a few years ago, the top analyst for Enterprise Architecture told the audience of CIOs that they should not spend more than 30 minutes thinking about Architecture Frameworks. After all, they would ultimately need their own customized approach for it to succeed in their context. I think this was very poor advice and that, in fact, he should have instead pointed out how much research Gartner had done on different frameworks and methods related to EA and modernization. Based on that research, which Gartner should have been happy to share to its paying clientele, Gartner could have explained the best building blocks to consider from multiple standards as implementation choices (Solution Building Blocks or SBBs). Based on the particular issues and opportunities for an organization seeking to enhance its overall architecture landscape through the better-informed decisions that EA could make possible, certain SBBs should be selected. The decision- making process should also have considered the optimum capability roadmap being followed in light of targeted areas of increasing maturity over time.
In short, it is not easy for any single enterprise to undertake a thorough analysis of EA frameworks and related, intersecting management approaches, but Gartner could have contributed greatly in this regard and then have impacted the EA discipline is a very positive way over the past decade or so. Instead, unfortunately, because Gartner apparently wanted to be the best SBB for complex EA consulting, it undermined the value of EA frameworks in particular.
EA Principals is an avid researcher into all the major EA frameworks in order to see where they intersect and how they can be differentiated from each other. Our belief is, that a customized EA method, just like a customized EA tool landscape, must be built based on an integration of the best building blocks of different options. Like Gartner, EA Principals doesn’t espouse a single EA framework, but is a champion and evangelist of customized EA for organizations, taking into account the existing and target Management Ecosystems in which EA would have to contribute and show value.
For example, TOGAF offers some excellent, overarching guidance on how to establish an EA team and organization in light of the gap it would fill in an organization’s modernization capability and governance. In light of such considerations, the design of the EA team and organization would have to also consider how to enable EA with the right guiding principles, patterns, tools, and techniques for a variety of relevant use cases.
However, TOGAF doesn’t have a ready-made knowledge repository of all the factors and building blocks to even be considered, so this leaves many people lost when they try to apply TOGAF. Therefore, it is clear that in order to succeed at even using TOGAF, one must go outside of its framework. Where can one go? That depends on many factors and requires becoming familiar with bodies of knowledge related to the wider EA ecosystem, such as Digital Transformation (DT). Better yet, examples of well-designed EA practices that currently exist to tackle DT and other modernization challenges are available and well worthy studying. A couple of examples are the IndEA Framework (, which is based on TOGAF but goes well beyond it and which provides numerous exemplative documents describing its approach. Of course, the U.S. Federal Government Architecture method (FEAF, v.2) also offers some useful reference models, the group of which has been further refined by the IndEA Framework. In addition, the Scaled Agile Framework (SAFe) offers many prescriptive guidelines to integrate agile and lean approaches to architecture at scale and must also be factored in.
Another great benchmark is the EA program of Queensland, Australia ( , which endorses and builds mainly about the AXELOS best practice methodologies:
  • ITIL
  • AgileSHIFT
  • Management of Risk
  • Management of Value
  • Management of Portfolios
  • Portfolio, Program and Project Offices
  • Managing successful programs (MSP)
  • PRINCE2 Agile.
In EA Principals’ EA consulting work, we analyze how, as just illustrated, applied examples of the use of leading change methodologies can be leveraged for new organizations in terms of EA methods. We also look at various EA modeling standards to help recommend the best blend of standards, such as ArchiMate and BPMN as overarching, extremely valuable foundations on which to further build a budding EA modeling practice. Such a combination covers both a capability/service-oriented approach with an end-to-end business process one that together can ultimately lead to the development of wide-ranging modeling skills that can be further extended with knowledge of the FEAF overall, as well as the DODAF, MODAF, NAF, and TRAK viewpoints. In addition, some basic knowledge of UML and SysML can be important for more mature practices. In addition, more knowledge of Model-Based Systems Engineering (MBSE), included as supported by the open source Arcadia method and associated, free systems architecture tool, Capella.

In conclusion, much more than 30 minutes of consideration about the universe of EA frameworks and associated management standards are needed to do a responsible job of designing an enterprise’s method and modeling approaches to help design and govern transformation. We suggest organizations seeking to build/mature their EA practices seek out architects who can bring such leading practices to bear, as well as ones who, collectively, have an excellent understanding of the main platforms an organization is currently using or perhaps should be moving toward. In other words, a thoughtful blend of EA and Solution Architecture, as well as Systems Architecture, is highly recommended to build a successful, customized EA practice that considers both method and modeling.

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


Can't find what you are looking for? Call (703) 333-6098 or Contact Us.
If you are having issues with our website, Contact our Webmaster.