A Summary of Architecture Part 3: How do we do it, and how does it fit with everyone else?

8 min readMay 6, 2022

Overview

This is a 3 part series looking at architecture in all its forms, and asking:

Part 1: What is architecture and what does it involve
Part 2: Who is doing architecture, and why
Part 3: How do we do architecture, and how does this fit with all the other roles, delivery methods and frameworks (this part)

Recap

Part 1 introduced architecture, why we do it, and the constituent parts (models, domains, layers, cross-references and RAIDDs), then Part 2 broke down the different kinds of architecture:

This part is going to discuss how architectures are created, or at least how Enterprise, Solutions and Systems architecture are created when using The OpenGroup’s Architecture Framework (TOGAF).

How do we do architecture?

TOGAF is a cross-industry attempt to create a standard repeatable method for creating an architecture and using that architecture to govern implementation projects. Having such a standard method helps to avoid mistakes and forgetting things and ensures everyone speaks the same language / follows the same process, meaning projects are likely to go faster, and people can onboard to the project quickly.

TOGAF contains several parts:

An architecture development method, which is a process for creating architectures
A content framework and meta-models, which describes the models to be produced for each architecture
An architecture repository to store and index the many artefacts created (and downloaded) when producing architectures
A skills management & capability framework and process for running an architecture practice, ensuring everyone understands their responsibilities

The Architecture Development Method (ADM) is a process centric method for creating an architecture: it describes a set of activities which must be undertaken to create the architecture, and groups those actives into a number of phases. How does this fit with everyone else?

TOGAF’s Architecture Development Method (ADM)

The ADM comprises the following phases and major activities:

Preliminary, which acts as the mobilisation phase, where the team gathers and ensures they understand their sponsor’s (person paying the bills) “ask” — by creating the “request for architecture work” document outlining what is required.
Vision phase, which turns the ask into a high-level solution concept, which is used to build consensus on the vision, before investing significant effort fleshing it out. This vision is then recorded in the “statement of architecture work” document, which lays out what the architecture team is being asked to achieve and describes how they will achieve it; essentially acting as a response to the “request for architecture work” created in the preliminary phase.
Content Creation Phases, which use an iterative process to record the baseline position (what the works looks like prior to the vision being realised) and the target (what the work will look like when the vision is achieved), with coverage given to the business architecture, the information systems (i.e. applications and data architectures), and technology (i.e. infrastructure architecture). Each of these architectures are recorded in the Architecture Definition Document, which act as the main deliverable of the architecture team.
Solutions and Migration Planning, where a roadmap is created enabling the company to get from the baseline position to the target, using a series of solution options, each of which will be delivered by a project (i.e. will eventually have solutions architecture of their own)
Governance and Change Management, once the individual solutions/projects have their solutions architectures created, they are passed to delivery. Therefore governance and change management processes are employed to ensure the delivery teams correctly realise architecture, or where this cannot be done, the changes / corrections are reflected back into the architecture. This is extremely important, because no architecture survives first contact with reality, and even if it did, the end user would quickly change their minds on what they wanted; thus the architecture must be a living document, able to accommodate a steady stream of updates.

Note: there may need to be a handover from the enterprise architect creating this architecture, to each of the solutions architects implementing each step on the roadmap. That handover might require additional architecture cycles to fully flesh out the required solution. If this is the case, the handover is done by the enterprise architect issuing a “request for architecture work” on the solutions architect, who initially responds with a “statement of architecture work”, and as the architecture is completed with the “architecture definition document”

“But this sounds very proscriptive and document heavy!” people often say; and this is a fair criticism of TOGAF. The key to successful use of TOGAF is “tailor, tailor, iterate”, or in other words:

Tailor: throw away as much of TOGAF as you possibly can, and only keep the bits that will genuinely help produce your architecture / solve your business problem.
Tailor: of the bits you keep, tweak them, to make them as applicable to your problem as possible.
Iterate: do not think of this as a waterfall method. Sketch out architectures, validate them in proof of concepts, and repeat the ADM cycles with new information. Iterate frequently, revisiting the business architecture domain once you have created the application architecture domain to validate all required services have been created.

The TOGAF content framework describes how architecture modeling should be done, and links to a meta model that describes how each element in the content framework interacts

As an example, the diagram below, taken from the business architecture meta-model shows how act Actor, performs a role to complete a process. As modeling progresses, that process might be mapped on to an IT service that an application will need to implement, and provide some further requirements for infrastructure services.

Not every TOGAF project uses the TOGAF metamodel however. Many prefer the Archimate model (also owned via the OpenGroup) or alternative modeling approaches like IAF

TOGAF describes how to set up an architecture repository to store:

All the documentation and models created when following the ADM
Externally created reference models and external standards guiding the architectures (ie stuff you found on google)
All the administration content created as a result of running an architecture practice: decision logs, evidencing of compliance requirements, the architecture team’s skills assessments & training plans, and the list of in-flight solutions that are realising the architectures

Lastly, TOGAF includes the Architecture Capability Framework, which provides guidance on how to set up and run an architecture practice. How to assess and develop architecture skills and knowledge, how to assign architects onto projects and governance roles, and how to run governance boards.

Can we just not do TOGAF?

Of course! there are many alternatives to enterprise architecture: DODAF and MODAF (flavours of TOGAF), Zachman and IAF being common examples.

Many organsiations have in-house methods, others don't do enterprise architecture at all, focusing instead on building services fast, or consuming cloud SaaS/PaaS services.

The important part has never been doing TOGAF, rather it’s ensuring the solutions being built actually solve end-user problems in a reliable, repeatable and sustainable way.

What about for the software side? TOGAF really doesn't suit software architectures. Other frameworks are much more popular, whether its the traditional UML, visualisation heavy approaches like Simon Brown’s C4, or the architecture approaches outlined in agile frameworks like SAFe

The fit with other roles and models

Enterprise Architecture has huge synergy with Management Consulting, and are in effect solving the same problems for the same people (i.e. addressing long term business strategy)

The Business Architecture domain has strong synergy with requirements management and frameworks like SEMBA. Ideally the levelling should be slightly different however. Architecture should be at a higher level: less detail, more breadth, and tighter integration with other architectural aspects: the non-functionals, the application and technology technology domains.

System, and Software architectures have huge synergy with software engineering, and the software architect will often be a hand-on engineer writing the code to implement the architecture. There will always be some tension between architecture and engineering, with careful thought needed to ensure just enough architecture is completed, and that the architecture is aligned with the code. The text-book pitfall is the 10,000 page architecture document sat on a shelf, never to be read by the engineering team. To avoid this, there must be strong collaboration between architects and engineers, and a ruthless focus on “just enough” architecture to facilitate effective development.

Architects must work hand-in hand with Project Management, to ensure the plan includes architecture activity, that the solutions defined in the architecture are delivered, and than the constant stream of requirements changes are properly captured and incorporated into the architecture.

Quality assurance and testing will be required both to validate the architecture (i.e. review the models) and to validate the delivery projects have properly realised the architecture meeting its functional and non-functional requirements.

Most organisations employing architecture will also have an operational focus, and a strong culture of Service Management, using a framework like ITIL. The architects will need to ensure the requirements from ITIL are satisfied by the architecture, catering for event, indecent & problem management, change & release management, and so forth within the architecture (i.e. dedicated business, information, application and technology services)

Conclusion

This post introduced TOGAF as a framework for creating architectures, and explained its parts: the Architecture Development Methodology, the Content Framework and Meta-Models, the Architecture Repository and the Capability Framework.

It stressed the importance of tailoring and iterating TOGAF (rather than following the whole thing in an architecture-by-numbers way), and the importance of accommodating changes to the architecture alongside delivery.

It then explained how the architects must work with other teams, including development, testing, project management and the operations team to ensure the architectures do not end up as 10,000 page documents sat on a shelf gathering dust.

Context