Many organizations assume that adopting The Open Group’s Architecture Framework (TOGAF) as the foundation of its EA method, means to tackle it “hook, line, and sinker” (pun intended). However, such an approach would be doomed to failure. In fact, TOGAF gives a lot of guidance about how to consider doing the essential customization in the Preliminary Phase and Phase A (Architecture Vision).

Below I have inserted extracts from both of these phases to underscore the guidance (and by doing so, I’ve also revealing the considerable overlap in a key step of the Preliminary Phase and the Approach part of that phase.

Step 5 of the Preliminary Phase in TOGAF’s Architecture Method (ADM), it says to “determine what tailoring of the TOGAF framework is required. Consider the need for:

• Terminology Tailoring: architecture practitioners should use terminology that is generally understood across the enterprise

Tailoring should produce an agreed terminology set for description of architectural content. Consideration should be given to the creation of an Enterprise Glossary, to be updated throughout the architecture process.

• Process Tailoring: the TOGAF ADM provides a generic process for carrying out architecture

Process tailoring provides the opportunity to remove tasks that are already carried out elsewhere in the organization, add organization-specific tasks (such as specific checkpoints), and to align the ADM processes to external process frameworks and touch-points. Key touch-points to be addressed would include:

• Links to (project and service) portfolio management processes
• Links to project lifecycle
• Links to operations handover processes
• Links to operational management processes (including configuration management, change management, and service management)
• Links to procurement processes
• Content Tailoring: using the TOGAF Architecture Content Framework and Enterprise Continuum as a basis, tailoring of content structure and classification approach allows adoption of third-party content frameworks and also allows for customization of the framework to support organization-specific requirements.”

In the approach section of the Preliminary Phase, TOGAF provides the following guidance regarding the need and approach for customizing the use of the framework: — in some cases redundant or inconsistent guidance from Step 5 of the phase:

“In order to make effective and informed decisions about the framework for architecture to be used within a particular enterprise, it is necessary to understand the context surrounding the architecture framework. Specific areas to consider would include:

• The commercial models for Enterprise Architecture and budgetary plans for Enterprise Architecture activity; where no such plans exist, the Preliminary Phase should be used to develop a budget plan
• The stakeholders for architecture in the enterprise; their key issues and concerns
• The intentions and culture of the organization, as captured within board business directives, business imperatives, business strategies, business principles, business goals, and business drivers
• Current processes that support execution of change and operation of the enterprise, including the structure of the process and also the level of rigor and formality applied within the organization

Areas for focus should include:

• Current methods for architecture description
• Current project management frameworks and methods
• Current systems management frameworks and methods
• Current project portfolio management processes and methods
• Current application portfolio management processes and methods
• Current technology portfolio management processes and methods
• Current information portfolio management processes and methods
• Current systems design and development frameworks and methods

• The Baseline Architecture landscape, including the state of the enterprise and also how the landscape is currently represented in documentation form
• The skills and capabilities of the enterprise and specific organizations that will be adopting the framework

Review of the organizational context should provide valuable requirements on how to tailor the architecture framework in terms of:

• Level of formality and rigor to be applied
• Level of sophistication and expenditure required
• Touch-points with other organizations, processes, roles, and responsibilities
• Focus of content coverage.”

In Phase A (Architecture) of the ADM, Step 1 reads:

“Establish the Architecture Project

• Enterprise Architecture is a business capability; each cycle of the ADM should normally be handled as a project using the project management framework of the enterprise. In some cases, architecture projects will be stand-alone. In other cases, architectural activities will be a subset of the activities within a larger project. In either case, architecture activity should be planned and managed using accepted practices for the enterprise.
• Conduct the necessary procedures to secure recognition of the project, the endorsement of corporate management, and the support and commitment of the necessary line management. Include references to other management frameworks in use within the enterprise, explaining how this project relates to those frameworks.”

The above extracts underscore the need for customizing TOGAF but don’t provide any templates, worksheets, or even suggested artifacts to facilitate the task. To complicate things, one would have to revisit the above items over an over again if an explicit pattern for the customization is not designed, published, and operationalized.

As part of working to customize TOGAF for one organization, EA Principals surveyed about every major method related to EA, Service Management, Architecture Description, Portfolio/Project Management, Maturity Models, and Skills Frameworks. In short, it is very difficult to just extract selected building blocks from such frameworks, thereby missing the overall, related elements and their proper implementation if TOGAF were not injected. It is not difficult to come up with a fairly compelling, integrated approach on paper, but to actually operationalize such a hybrid of building blocks is far from simple. To make things simpler, in fact, one would need to obscure any of the “EA speak” and put all aspects of the approach into business terms as a unique and easily explained way to blend leading practices. In short, building a customized EA approach can be done, but it requires agility and a way to scale the principles from a smaller to larger scope over time.

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

Authored by Alex Wyka, Senior Consultant and Trainer, EA Principals