One of the key attractions of Enterprise Architecture is that it can help address and manage the complexity of major transformations. However, EA is itself such a transformation. So, this creates a conundrum. Without EA, how do you succeed at the transformation needed to realize it in a daunting business-technology landscape? We are therefore confronted with a complex syndrome with complexity as both the “illness” and the “cure.” Put another way, one needs to embrace the fact that setting up an initially viable and ultimately successful and enduring practice is a paradigm shift. New thinking and confronting associated uncertainties are necessary and they must be addressed head on. But how to proceed?

One example of this using the TOGAF EA method is that the Preliminary Phase, where the EA Practice is set up (matured and managed), there is only one technique connected to the 7 steps: EA Principles. The other 13 techniques in TOGAF are in the Architecture Development Method (ADM) Cycle that begins in Phase A (Architecture Vision) and continues design work through Phase F (Migration Planning). It is rather obvious that the power of transformative thinking is captured in Phases A-F, so why not define a cycle to set up (mature and manage) an EA Practice? 

While this seems like a chicken and egg scenario, one starts to understand TOGAF’s method but using it right off, improving over time with iterative cycles enhanced by the learning of each preceding one, thereby helping the EA Practice to be successfully established. So, the basic approach to setting up an EA Practice, which seemed so daunting and complex, can be undertaken by using the method intended to tackle complexity: the ADM, even though this may seem illogical at first glance.

Without calling out the use of the ADM, though, the following steps are those recommended by the University of Helsinki about 10 years ago based on its establishment of its EA practice across 4 campuses:

• Define EA Goals; Short/Long Term
• Communicate; Emphasize Results, Not Concept
• Get Sponsors/Commitment from:
  • IT, IT Management
  • Administration
  • Business Management
• Get organized — EA Board, EA Governance, etc.
• Get EA Skills, Training
• Get Support – Peers and Consultants
• Create EA Principles
• Measure Progress with Regular EA Maturity Checks
• Document your journey
• Define The ’EA Big Picture’
• Get Networked — “Be so good they can’t ignore you”

Based on its experience establishing its EA Practice, it also published the following lessons learned:

• EA= A method aiming at the best possible [technology] solutions to support an organization’s key mission threads/core functions.
• EA is a target-oriented ’way of life’ and a mindset.
• EA itself is not a project, but rather a process.
• EA program requires skilled resources.
• EA modeling requires time and resources.
• EA does not offer ready answers but helps to ask the right questions at the right time.
• EA is a protocol, a communication tool that enables different organizational units to develop operations and technology systems concurrently.
• The use of the EA method should not increase workload because the work should be done anyway — EA just brings about a more sophisticated (holistic and comprehensive) method to do it.

The above recommendations and lessons learned seem so clear and basic, but neither of them provides information on the actual work involved or the connection between the startup phases and the takeaways. That is because it is all very context specific and complex.

To deal effectively with all the complexity EA is intended to target and manage, the journey is a continuous and complex one. Fortunately, GenAI is a powerful new collaborator to assist throughout the EA lifecycle. It, too, is very complex, but one needs to embrace the complexity in order to ultimately leverage its potential, just as with EA itself.

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