True. I wrote that post to try to engage with so many architects who are saying “TOGAF no longer fits into our world — it’s heavyweight. It’s waterfall. We want to use an agile method for everything.”

As you say, organisations are now using agile thinking for designing virtually anything: long-term business strategy, digital transformation, and the design and realisation of digital business technology solutions.

Agile did come out of software development, but agile thinking is now being used as a paradigm to plan, design, and deliver virtually everything.

Unfortunately, when one reads the TOGAF specification, it’s easy to make the inference that waterfall / big-requirements-up-front was in the minds of the people who wrote TOGAF. One has to make a significant effort to re-interpret TOGAF as agile-friendly.

On the other hand, some things are difficult to design and realise using an agile approach. Major infrastructure investments need to be planned, budgeted, and deployed over longer periods. So maybe we can’t get away from “big requirements upfront” entirely. Big-ticket investments also have myriad “interoperability dependencies” on many other things, and hopefully enterprise architecture assists in anticipating, and understanding those interoperability dependencies, and navigating through them.

The metaphor of enterprise architecture as “city planning” is still relevant. There needs to be long-term, whole-of-enterprise planning and governance. But within that “big picture” paradigm of principles and standards, we are still free to innovate on a wholly agile basis.

The agile theme of “fail fast, fail cheap” acknowledges that we’re going to make mistakes, and we shouldn’t attempt to overplan or be dogmatic. In other words, there is going to be an acceptable amount of risk, and an acceptable amount of wasted capital.