The Enterprise Architects' Toolkit

In this article, I want to share some of the TechArch2Ops “secret sauce”: a results-driven framework for Enterprise Architecture. Based on my years of study, experience and reflection, the TechArch2Ops EA toolkit offers a pragmatic approach to “Just Effectively Do It”

Origins & Evolution of Enterprise Architecture

To set the foundation, let’s briefly revisit the origins of Enterprise Architecture…

John Zachman is widely credited with putting together the first framework to describe Enterprise Architecture. The Zachman Framework, published in 1987 first in the IBM Systems Journal, proposes that enterprises can be described through the six key questions: what, how, where, who, when, why – each from the viewpoint of a different stakeholder.

Since 1995, TOGAF have been publishing updated versions of their methodologies and framework, evolving Enterprise Architecture concepts, models and references. TOGAF considers Enterprise Architecture as:

 “a strategic planning discipline that defines the structure and operation of an organization through four primary domains: Business, Data, Application, and Technology Architecture”.

Choosing and Using Frameworks

What these frameworks have in common is a structured way of capturing, analysing and presenting a range of viewpoints to support enterprise operations and change. Enterprise Architects apply this structure to navigate their way through organisational and technical challenges, leveraging existing models, patterns, and references where appropriate, such as those provided through traditional or newer frameworks.

Often, the choice of framework is made based on the EA’s experience but also existing tooling and models within the enterprise. In my experience, the chosen framework provides that important foundation stone to help consider the architectural problem and frame the challenge.

However, it is just that – a starting point. As a result, I believe that the “Just Effectively Do It” pragmatic approach means bringing more attention to the deliverables, rather than the frameworks that will be used to achieve those deliverables.

Defining the architectural challenge

When defining the architectural challenge, we first need to consider what we are trying to achieve. The organisation may be bringing in Enterprise Architects to govern technology capability, lead transformation programmes, or prepare a strategy for M&A or other organisational changes. Naturally, context, scope and mandate are usually covered within the Architect’s briefing, but at this point, the architect will need to consider how to approach the challenge.

There are a few common methodologies that Architects use to shape this journey.  TOGAF’s ADM is a familiar model designed to articulate the scope of Enterprise Architecture. More than a lifecycle-based delivery model (Define > Design > Develop > Deliver > Ops and Support), ADM activities follow a cyclical and increasingly detailed process of evaluating, designing and developing artefacts.

TechArch2Ops Architecture Methodology

While I have found the ADM to be consistently appropriate for projects large and small, it often requires significant tailoring to truly meet the needs of the enterprise. In essence, TOGAF is ubiquitous, and it is the Architect’s responsibility to strip this down appropriately.

TechArch2Ops simplifies the Core Architecture Method by showing that analysis is carried out across different areas: the current state, the target state landscape (the as-is and desired future condition of the enterprise) as well as the differences between the two. This data and analysis drive a realistic and achievable action plan.

TOGAF ADM

Core Architecture Method

Dimensions and Domains

When delivering Enterprise Architecture, the business challenge (reason for architecture) needs to be presented in technical terms. Experienced architects will recognise that the domains have evolved over time, for example, data was recognised by TOGAF as a domain in Version 9. These domains exist to help architects consider the full spectrum of technical considerations for the architecture. 

The TechArch2Ops Enterprise Architecture Approach (image below) considers the architectural domains and influences that impact the solutions. From experience, this provides a “Just Effectively Do It” pragmatic approach to creating architectures and artefacts that support stakeholders' needs.

Enterprise Architecture Approach

This model helps frame conversations, guide analysis, and structure stakeholder engagement. The Enterprise Architect’s skill and experience lie in navigating these conversations in a way that minimises impact to the client and continuously drives the initiative forward.

What do Enterprise Architects create to drive impact?

As I’ve discussed in my Vision and Strategy blog, it is imperative that Enterprise Architects create work products and documentation that enable:

• Communication

• Collaboration

• Capability

This will range considerably depending on the engagement; however, I have found the following list of Architecture Work Products provides a useful reference when considering appropriate models and deliverables. While it should be noted that there are additional technical and non-technical deliverables across domains and project phases, my focus is specifically on the specialist deliverables of Enterprise Architects.

Enterprise Architecture Products

Governance and Decision Making

In addition to deliverables, an Enterprise Architect’s role is to provide technology governance. This involves establishing and enforcing standards, policies, and processes related to the implementation and operation of an organisation's technology. Enterprise Architects ensure that technical decisions align with the overall business strategy and are responsible for navigating the business and technical stakeholders' expectations.

From my experience, establishing technology governance is one of the most important success factors in any organisation or transformation programme. Governance anchors architectural efforts in consistency, transparency and strategic alignment. The appropriate governance model should be considered that fits the organisation and teams. Usually, at least 2 levels of governance authority are needed – separating out those that are delivering, deciding and consuming the solution. The decision needs to be made with a level of removal from the emotions of day-to-day involvement.

Final reflections – focusing on the Big Picture, effectively

In this article, we’ve explored the Enterprise Architects toolkit:

1. Utilising references and frameworks

2. Framing the architectural journey

3. Exploring technical domains

4. Develop architectural work products

5. Establish and operate governance

   
   

One of the most interesting aspects of Enterprise Architecture is that this toolkit proves effective across a diverse range of industries, sectors, technology disciplines and projects. Enterprise Architects are relied on to be able to understand different technology challenges affecting important and complex environments, and to lead technological transformation and capability.

A key reason for the success of this toolkit, and the discipline of Enterprise Architecture are the practitioners who have evolved their careers along this path. By nature, architects will be thinking deeply about the Big Picture: context, target, progress and charted course. Architects are problem solvers and leaders, both flexible and principled.  Enterprise Architects draw on instinct sharpened through their skills and experience - the TechArch2Ops EA Toolkit embodies the scope and sophistication of this responsibility.