The term “hacking” has become part of our vocabulary to describe the process of illegal access to information but the term “hackathon” has a positive connotation and describes an event at which a lot of people come together to write or improve computer programs.

With this in mind, we really need to approach even “sacrosanct” EA frameworks and methodologies with a hacker’s perspective where nothing is sacrosanct. Again, success is determined by whether the outcome of their work can result in real improvement and practical applicability.

Over many years, TOGAF (The Open Group Architecture Framework) has become, for many EAs,  a synonym for a best practice approach to enterprise architecture. With the publication of the Digital Manifesto, we have seen a huge evolution of many agile methods. Some of them are very light and focus on processes at a team level, others like SAFe are much more comprehensive and try to cover all layers of an enterprise and provide recommendations on how to achieve progress in business agility.

The Open Group has also introduced O-AAF (the Open Agile Architecture Framework). However, it doesn’t include an associated method to customize TOGAF’s ADM (Architecture Development Method) so we can apply O-AAF in EA Management (EAM). However, who is going to synthesize even these two standards en route to something that would be practicable?

We need open minded people to tackle EAM and its associated digital transformation. They need a wide range of skills, not only covering rapidly evolving technology domains, but also areas such as change management and the redesign of organizations.

We consider that TOGAF is just a springboard in building EAM capability and that it doesn’t provide all recipes for customizing EAM practice or life cycles for architecture development.

To start with, after small cosmetic changes in TOGAF 10, the crop chart that is supposed to represent the ADM and its iterations is still confusing for many people as it attempts to see the process from the perspective of multiple phases, each with own inputs, outputs, approach and deliverables. It’s still perceived by many students as having roots from waterfall world.

TOGAF 10 has, however, done a good job in better integrating its foundational content with a number of guides that focus on specific domains or challenges. However, this “improvement” has tripled the size of the TOGAF 9.2 version. Covering this is beyond the reach of students’ knowledge acquisition in 4 days of teaching. However, it remains possible to “teach” it to the LLM ChatGPT 4.0 in one collaborative session. This will still remain a challenge for students because, in their interaction with ChatGPT, they need to have additional skills in crafting prompts and to evaluate ChatGPT answers.

The MSP (Managing Successful Programs) methodology has been more effective in depicting its scope and approach in one diagram. In the current MSP version 5.0, we can see a new diagram (it’s not a crop chart, it’s not a life cycle) to show program management delivery from a helicopter-view level. It refrains from a more prescriptive approach that could be useful for some contexts, but not for all.  Instead, it focuses on principles, themes and processes, which together imply that you need a skill set to adapt MSP for your enterprise to deliver real business value.

An enterprise architect about to start building an EAM (Enterprise Architecture Management) practice will likely face stiff organizational and personal challenges.  First of all, the architect needs to be able to explain and to demonstrate the business value of EAM.

The approach to build an EAM described in the ADM’s Preliminary Phase implies that the architect needs to have very comprehensive experience and knowledge of multiple frameworks and methods that may be already in use in their enterprise. Cataloging these comprehensively and accurately is a major challenge, not even considering the requirement to then merge them in an efficient and effective way with the organization’s EAM practice.

When you are just an EA rookie, 4 long days of the typical TOGAF training course is not sufficient to provide you with this set of skills, even though many people attending such workshops are looking for a cookbook for their own implementation of EAM. However, no two TOGAF adoptions are identical, as enterprises differ in terms of their size and complexity, the maturity of their relevant capabilities, the specificity of their industry sectors, existing company corporate cultures, frameworks currently in use, and their needs and motivation for transformation.

Therefore, there is no perfectly sequential, step-by-step implementation to pursue contextually appropriate EA maturity that can used right “out of the box” for anyone. However, there are certain patterns that should be considered for designing your own specific EAM journey.

For example, below is an excellent overview of how to proceed that was generated in collaboration with the Bard.Google GenAI:

“To effectively position EA as a critical enabler in even a skeptical environment, it is important to address the negative perceptions that often surround it. Here are some strategies that a potential, emergent Champion for EA could employ:

1. Emphasize the business value of EA: Clearly articulate how EA can help organizations achieve their business goals. Demonstrate how EA can improve agility, reduce costs, and increase innovation. Use real-world examples to showcase the tangible benefits of EA.

2. Focus on outcomes, not outputs: Shift the focus from creating EA artifacts to delivering business outcomes. Align EA initiatives with strategic objectives and measure success based on the impact on the business.

3. Make EA more collaborative and inclusive: Break down silos between business and IT stakeholders. Foster a culture of collaboration and shared ownership of EA. Involve stakeholders in the development and implementation of EA initiatives.

4. Simplify and streamline EA processes: Streamline EA processes to make them more efficient and less burdensome. Use technology to automate tasks and improve communication.

5. Tailor EA to the specific needs of the organization: Avoid implementing a one-size-fits-all EA approach. Adapt EA principles and practices to fit the unique context of the organization.

6. Continuously evolve and adapt EA: EA is not a static discipline; it should evolve to meet the changing needs of the organization and the business environment. Embrace new technologies and approaches to keep EA relevant and effective.”

Authored by Alex Wyka, EA Principals Senior Consultant and Principal