Undertaking an Enterprise Architecture (EA) program can seem like a daunting task. To begin one, many people assume they must start with an EA Framework, but that doesn’t necessarily simplify their task much because there are many different EA Frameworks. For example, in a recent posting on the EA tool vendor site, (https://www.avolutionsoftware.com/abacus/frameworks/), Avolution notes there are over 100 EA Frameworks/standards, listing about 35 of them. To give the illusion that mixing and matching them can be “easy,” it advertises that “Practitioners can configure, adapt or combine frameworks and metamodels using simple ‘right-click’ and ‘drag-and-drop’ commands”. Well, it is not that intuitive regarding how to decide what to use, adapt, or ignore. Customization is, in fact, an extremely complex challenge. Therefore, I offer here my list of ten essential building blocks for pursuing a formal EA program: the creation of an enterprise-specific approach must be done iteratively based on wide-ranging knowledge of leading practices. Here is my list in a general order of emphasis:
- Customization
- Business-outcome oriented
- Integrated governance
- Synchronization and harmonization of different frameworks, methods, and standards
- Explicit, flexible method
- Complementary visualization methods to address wide-ranging stakeholder concerns
- EA education enterprise-wide at appropriate levels of coverage for targeted stakeholders
- Effective communication across the EA landscape
- Continuous collaboration across the relevant ecosystem
- Incremental, measurable progress tied to traceable value added
In this article, I focus on the first building block, though, to set the stage for similar in-depth development of the others in subsequent articles. Also, customization, item #1 on the list, must also include consideration of the other 9 building blocks, although I don’t dive into them in this piece.
Customization of an Enterprise-Specific EA Program
The word “Enterprise” in EA is significant but often misunderstood. Without the concept of “Enterprise” tied to the targeting of architecture management or new or enhanced capability, then we would wonder what the connotation of the architecture work is. We would even wonder if we are referring to licensed architecture work, such as that of a building architect, so the adjective we use is critical for context. Put simply, “Enterprise” relative to architecture work is any organization or initiative pursuing or linked to a common set of goals and outcomes. Yes, that means the term “Enterprise” is broad, but, even so, it differentiates the EA work from that of licensed architects; solution architects; business, data, application, technology/infrastructure/network, and security architects; among others (I’ve recently heard of a Disaster Architecture position, for example, in the Federal Emergency Management Agency – FEMA, DevOp Architects, and Integration Architects). In fact, we see a proliferation of the types of architects, such as Cloud or even Multi-Cloud Architects and Digital Transformation Architects.
The danger (or maybe, in some cases, the opportunities) for EAs is that they may be expected to be conversant in any type of architecture. In other words, some organizations may only hire one EA and expect her to be able to do any kind of architecture work except that of licensed architects. If one considers that EA work could be very different in, say, government organizations compared to for profit or non-profit ones, then one could imagine specialized EAs (e.g., Government Enterprise Architect, Non-Profit, Conglomerate Architect, etc.) that requires specialized training and experience.
In fact, there has been general recognition that doing EA in government can be quite different from in profit-driven enterprises and therefore special frameworks training for government-centric EA may be appropriate. Nonetheless, the leading generic, openly available EA framework for professional certification is The Open Group Architecture Framework (TOGAF), which, with expert assistance, can be adapted to incorporate elements of both DODAF and the FEA Framework (FEAF).
With so many frameworks, methods, and standards to choose from, why is customization always required? Because every Enterprise will have different Stakeholders with their respective concerns/interests pertaining to the EA. EA programs must be designed and optimized to, at a minimum, align to the personas of the different enterprise roles and the different initiated contact specific goals.
There is no “out–of–the–box” EA framework that can be used as is. All EA frameworks need some degree of modifications to work in their target environments. Even a customized one that works great in one enterprise will not be usable in its present form for a different enterprise. It will even need to be further adapted in the first enterprise to stay vital and valuable. In other words, further modifications to what might be already a customized EA framework is essential for EA to mesh with the evolving target context of any enterprise. So how does one go about customizing an EA framework –– what are some of the leading practices and recommendations to achieve this?
Based on my 20–plus years of international EA experience, which has involved diverse, international consulting work, as well as educating and training approximately 10,000 individuals — often very senior enterprise and solution architects, as well as CIOs/Directors of IT, I have concluded that this is never an easy undertaking. As a point of departure, though, I strongly recommend certification training in TOGAF (The Open Group Architecture Framework) for all existing or prospective EA practitioners, as well as the ArchiMate EA modeling language, so one has a solid foundation in both method and modeling.
The core part of TOGAF is the Architecture Development Method or ADM, and the most essential element of that to master is how to do what is called Phase A: Architecture Vision. Phase A of the TOGAF ADM is the phase of the 8-phase ADM cycle in which the EA project is scoped.
Let’s assume that we are scoping the customization of an enterprise’s EA approach. To arrive at a properly scoped project for such an initiative, we would need to consider who would own the EA program, which goals, drivers, and outcomes would be expected from it, and how we would measure the value that would be derived from it. In a way, we would be addressing what gap in enterprise capability that the EA program addressing, in what way, with what resources, and with what value to whom. So, in effect, with TOGAF and its Phase A, we would be arriving at an aspirational vision of what an EA program would be initially and how it would evolve in the context of the overall enterprise and its current and planned management-related methods, standards, and tools.
Using other elements in TOGAF associated with Phase A, such as a business scenario, we would also come up with a high-level concept of the target EA approach, create an explicit Statement of Architecture Work that included a rough order-of-magnitude schedule for its major work packages. To arrive at this point, we would need to consider the overall Enterprise Business Capability Map, conduct a Value Stream analysis of what sequence of value-adding activities would facilitate incremental delivery of the new or enhanced capability.
In addition, we would want to produce an Organization Map that captured key roles and responsibilities, including for domain and solution architectures, as well as development, operations, and maintenance areas, to carry out life cycle activities across the enterprise. We would also conduct a stakeholder analysis, a readiness and risk assessment, and carefully consider how the EA program would be best designed to interoperate in the target environment, including perhaps the need to change other programs, methods, processes, and tools.
Clearly, TOGAF is not the only EA Framework that underscores the criticality of appropriate and explicit scoping of an architecture initiative, but no other open framework includes the panoply of items just highlighted that are not only essential to TOGAF thinking, but also invite the inclusion of other frameworks, methods, standards, etc., whatever makes the most sense to arrive at the targeted capability – in this case, a vibrant and sustainable, value-added EA program. Knowledge of the various structures and behaviors is critical regarding what already exists and will need to co-exist within an enterprise going forward, along with what potential insertions from other external frameworks that could contribute value, whether as part of the method or the modeling.
TOGAF’s Phase A infers the need to understand architecture, governance, management, transformation, and technology in a wide and relatively deep way. This would include the ability to consider other frameworks, reference models, reference architectures, standards, etc., and how they could be integrated to achieve the optimum approach to EA in any given enterprise overall or for a particular transformation initiative.
As noted earlier, TOGAF could be complemented easily with DODAF and FEAF, and is also typically done with the Project Management Institute’s PMBOK (Project Management Body of Knowledge). Overall, its blended approach of method and appropriate work products (which could be based on other bodies of knowledge as well) makes it an outstanding Integration Framework that can evolve over time.
Therefore, for our first essential building block for a successful EA program, TOGAF provides an excellent scaffold and can undoubtedly serve as a great springboard for the customization that will always be required when designing an EA program. A plenary speaker at a Gartner IT Symposium/Xpo a few years ago, when recommending that CIOs consider EA for innovation efforts, conceded to a skeptical audience of CIOs and IT practitioners that there are many ways to get EA wrong, and much fewer ways to get it right. Customization is the first step to get EA right. Combined with all the other elements listed at the beginning of this article, one has the essential building blocks needed to move forward to define and rollout a successful EA program.
