TOGAF is Agile! What? You Didn’t Know This?

I’m hearing a lot of people saying “TOGAF is waterfall. We want to be agile”.

Fact of the matter is:

TOGAF and the ADM is not inherently “waterfall”. But it can be made to be “waterfall” — if that’s what you want.

TOGAF and the ADM is not inherently “agile”. But it can be made to be agile — if that’s what you want.

Here’s why:

TOGAF and the ADM defines a highly generic, normative reference model for enterprise architecture.

What does “generic” mean? It means it’s so high level, you cannot immediately use it “straight out of the box”, as it were. You have to think about it, and do some serious work to figure out how you will adapt and implement TOGAF concepts in your organisation.

What does “normative” mean? It means “We think this is probably a good thing to do, and a good way to do it.” As in: “It’s normal. Normal is good.”

(For a lot of people, normative is aspirational. Lolz. Don’t ask me what “aspirational” means. Go look it up.)

So TOGAF defines a number of high-level concepts that are considered representative of valid architecture practice. “Better” practice, if you will.

TOGAF is a Big Bag of Parts

Metaphorically speaking, TOGAF gives you a big bag of parts. The parts can be used to assemble an enterprise architecture capability. How you assemble those parts is entirely up to you and your stakeholders. Which parts you use — which parts you don’t — it’s all up to you.

Don’t blame TOGAF if you screw it up.

The ADM, on the other hand, defines sequential phases in a generic architecture process. The ADM Phases are also “parts”. Again, how you use them, and which ones you use, is up to you.

Here’s a picture of the ADM, in case you forgot:

The TOGAF Specification states explicitly that TOGAF and the ADM need to be specialised, extended, adapted, abridged, transformed, customised, configured, edited, defined, re-defined, re-interpreted, rationalised, re-organised, re-sequenced, tailored, and modified as you think best meets your needs.

If you want to assemble the parts to be “agile” — you can do it. Go for your life.

If you want to assemble the parts to be “waterfall” — you can do that too.

Generic Makes Sense

The ADM phases, and the sequencing of those phases makes sense — in and of themselves.

The ADM phases make sense for agile. They would make sense for “waterfall” — but you don’t want waterfall, do you? No one wants waterfall anymore.

So what would an agile ADM look like?

Here’s one I baked earlier (I assume you already understand the ADM):

Phase A? Agile!

You need some consensus on “vision” before you start. That’s what you do in Phase A.

You might say that one Phase A defines an “Epic”. Alternatively, a different Phase A might define a “User Story”. Phase A could define the “Program Increment” for an “Agile Release Train”. Any of these things can map to Phase A: Architecture Vision at different levels.

If you’re talking specifically about SAFe Agile, Phase A could also map to — and be used to facilitate the definition of — “Enterprise Level Strategic Themes” or “Program Portfolio Management Level Value Streams” — which could equate to TOGAF’s “Capability-Based Planning”.

Stakeholders and Requirements

In any agile iteration at any level — and any ADM iteration at any level — you’re going to involve your stakeholders. The stakeholders can be thought of as “Epic Owners” or the “Persona” in a “User Story”.

In TOGAF, stakeholder management is crucial. If you fail at stakeholder management, you’re dead. If you somehow manage to get anything else right, it doesn’t matter if you’ve failed at stakeholder management.

Of course — Agile is all about stakeholder management, too.

In an agile context, “epic owners” will be directly engaged throughout the entire agile design process.

Agile says this. TOGAF says the exact same thing.

There Is No “Big Requirements Up Front” in TOGAF!

Your stakeholders will not be asked to “provide requirements up front”. THAT would be “waterfall”, and you don’t want that. Do you?

There is nowhere in the TOGAF 9.1 Specification that remotely suggests or implies “big requirements up front”. The exact opposite is true. Look at the ADM diagram. Look where “Requirements Management” is in the picture of the ADM! It’s the biggest circle, and it’s right smack dab in the middle of everything, isn’t it? See all those little arrows going back and forth between Requirements Management and all the other phases of the ADM? Bingo.

Requirements and design emerge as we iterate in agile sprints and ADM cycles. Always engaged directly and continuously with our stakeholders. Shoulder-to-shoulder. In the same room, in the same scrum teams. Right? Right.

That’s agile.

Phases B, C, D? Agile!

You need to decide how and whether Phases B, C, and D, are relevant, and what you need to do with respect to those architecture domains or “concerns”.

Phase D is kind of interesting. Maybe Phase D: Technology Architecture is a “given”. It’s not going to change. You’re going to re-use whatever technology environment you are targeting. So you just focus on Phase B and C in your sprint. You may often be leaving out Phase D concerns from your sprints.

Doesn’t HAVE to be this way, of course. You could just as easily be doing agile design and iteration for deploying an infrastructure technology or platform, but I don’t think agile was really designed for that purpose.

Maybe Phase D: Technology Architecture is some kind of “Architecture Epic” in it’s own right that you’re going to realise separately. I tend to think Phase D is not often going to be designed or realised in a sprint or program increment. So I think an agile sprint will be focused on Business Architecture, Application Architecture, and Information / Data Architecture. Phases B and C.

Having defined what you have (baseline) and what you want (target) is work that relates to Phases B and C. You’re not often doing “green field” development — so it may be good to know what your current state is. There could be constraints or requirements there that you need to know about. But you’re not going to waste time documenting your current state. Unless you need to. That’s your call too.

Phases B and C can certainly be mapped to “agile / scrum” practices.

You might say Phases B and C — undertaken in parallel — may define a “Sprint”.

You might say Phases B and C— undertaken in parallel — may define an iterative “Agile Release Train” (ART), so that’s a “program increment”.

You could be using wireframe tools like Balsamiq, Axure at this point.

You could decide you only want to do Phase B: Business Architecture in an agile iteration. This might especially be the case at the level where you define “Enterprise Strategic Themes” or where you’re thinking about changing those big value streams at the level of “Program Portfolio Management”. At this level, perhaps you’re more interested in the strategic “what” rather than the tactical “how”.

I think if you’re changing some aspect of business architecture, you’re almost always going to be changing some aspect of your application and information / data architecture. But not necessarily always, hey?

Most agile release trains I see combine — and focus almost exclusively on — business architecture, application architecture (presentation, business rules, workflow) and information / data. So they’re furiously iterating over Phases B, C and D only.

Phase E? Agile! And DevOps!

Having done a few incremental iterations of Phases B, C, and (maybe) D, you may feel it appropriate to think about a number of alternative options as to how you could realise the changes you’ve designed in your agile release train, or your scrum.

This might involve considering a number of different options for “assembling architecture building blocks”. Which bits best realise your “miniumum viable product”, which bits should be left out, or taken out and put back into the Kanban BackLog.

You get the picture.

This is what you do in Phase E. Sometimes Phase E might not be necessary. So you leave it out. Who knows? It’s your call.

Here’s an idea: Maybe you can just combine Phase E and Phase F. So in an Agile + DevOps environment, Phase E and Phase F become the same thing.

Is that legal? Can you do that? Can you delete a phase from the ADM? Hell yeah! TOGAF says you can. Go look it up. It’s in there.

Phase F and G? DevOps! And Agile!

What happens in ADM Phase F and G could be immediately and fully developed, implemented, tested, and deployed by a DevOps team. In theory, the same team doing an agile release train could be directly implementing and deploying the solution into the production envionment. I don’t think that happens a lot. But I know it probably does happen. Somewhere.

So for me — these days — I kind of think of Phases F and G as “the DevOps Iteration” of the ADM.

I just made that up. There is no “DevOps Iteration” in the TOGAF Specification. But it sounds good, doesn’t it?

And DevOps is agile. In fact, if you really want to be wholly agile, you’d better be trying to achieve DevOps. Amazon deploys new code every ten seconds.

See what I’m doing? I’m TAILORING TOGAF and the ADM MY WAY. I am “doing TOGAF”. I’m also “doing agile”.

Phase H? Agile!

Once you’ve deployed into the production environment, your team immediately looks at your Kanban Backlog, and starts planning and executing the next agile release train, the next program increment, the next epic, the next sprint. The next Phase A.

There is your agile interpretation of Phases G and H.

Phase H: Architecture Change Management? I think that could be your Kanban Backlog right there. I tend to think of Phase H as where you would also be accounting for “Architecture Debt”. Architecture Debt is not even mentioned once in TOGAF. But it’s a common term used by architects all over the world. Sometimes they call it “technical debt” or “enterprise debt”.

Rinse and repeat. Voila. TOGAF and the ADM are agile. QED.