What Was Supposed to Happen?

That, in effect, was what was supposed to happen here.

What Actually Happened?

We did use architecture-methods to describe various key aspects of enterprise-architecture, in what was effectively a simulation of real-time work – subject to constraints imposed by the book-style format.

So, for the purposes of this exercise, those three actually form sub-projects or layers of the same overall project – in effect also illustrating the point about recursion.

This is, as you can see, documented in book-format. The text-style and content were aimed at enterprise-architects and, especially, for other architects who might want to explore the enterprise-architecture domain. Although some of it was fairly theoretical, it should still make sense for most strategists, project-managers, and others who work with a larger-scale scope – in other words, the typical clients for enterprise-architecture. So that part was in accordance with the plan, too.

We did also use the existing Agile-architecture development-process. This was loosely based on the well-known TOGAF Architectural Development Method (ADM), but adapted for a more Agile-type style, explicitly iterative and recursive, and usable for any scope. We demonstrated part of this recursion with a cycle that contained an embedded second cycle, which itself included two further sub-projects.

We wanted to emphasize the processes of sensemaking and decision-making in architecture, using methods such as context-space maps that describe the natural layering, recursion, and reflexion within enterprise-architectures. We’ve probably achieved this, with two fully worked examples and upward of 50 diagrams, though perhaps still with not quite enough explanation as yet of the real dynamics that apply in the use of context-space maps. But it’s enough with which to get started, we would hope.

The timescale of ten working days was probably realistic enough for this purpose. The real work described in the two sub-projects in fact took less than that – particularly the “bank example,” whose real-world components were compressed into barely half of that time. (In our own work, we’ve done complete architecture-cycles in as little as two hours, rather than the two weeks allowed here – though that didn’t include much of an implementation, of course. But this here is still a lot faster than the two-years-to-business-benefit usually expected for a classic TOGAF-style architecture-cycle…) The writing took rather longer than ten days – almost three times as long, in fact – though that was somewhat to be expected, for reasons we’ll explore in a moment.

We had several reminders throughout this period that architecture is necessarily generalist and eclectic. Most of architecture is about decisions of some kind; and many if not most of those decisions are emotional at root, about feelings and “gut-feel,” a sensitive awareness of tendencies and trends. It’s about “big-picture,” about finding common unifying-themes within the ways that everything connects with everything else. Which means that we need a good understanding of how everything connects with everything else – which in turn leads to the need to be generalist and eclectic in our approach to architectures.

Architecture, design, and engineering are all closely related, but have different concerns, different emphases, different approaches to any given context. Engineering will focus on the fine details, on the tangible, the concrete, on that which purports to be “objective,” on “things.” Architecture will emphasize overall scope and scale, the intangible, the feel of things, the subjective, the connections between things. And the role of design is to bridge the gaps – hence architects need design in order to realize their ideas, and engineers need design in order to make their work usable and to connect with the work of others. Engineers and the like can usually remain specialists throughout their careers; but architects must be generalists, to link across all of those specialist domains that make up their respective “world.”

The point here is that many business-folk – perhaps most – have a mindset that is closer to that of the engineer than the architect: the specialist rather than the generalist. Someone in the business must hold the generalist view, and in principle that’s a key part of the role of the CEO. But as we saw in the bank example, the CEO may also be solely a specialist, a “numbers-man” in that case. Somewhat bizarrely, the only person there who maintained the generalist view was our client, the change-manager – but he didn’t have the authority to do much within that role. This kind of situation is not unusual in large organizations, and is a common source of serious enterprise problems: so architects, as some of the few generalists around in the business, can often find themselves placed in the awkward role of arbitrator between warring specialists. It’s another way in which the job can become “relentlessly political” – as one of my colleagues put it – and another reason why we’ll definitely need strong “people-skills” to do this work well.

The relentless politics of business, important though they may be, are only one of the sources of inherent uncertainty in architecture. We came across a lot of this during this worked-exercise, particularly at the start of each phase, where that sense of “I-don’t-know-what-I’m-doing” will often hit hard for a while. That feeling can be uncomfortable in the extreme: but it is part of our role as architects to work with it, in order to find the designs and structures and solutions that we need. And it is also a normal part of the work, hence should be no surprise – in fact is actually a sign of success – whenever we come across it again.

During this cycle, we had several reminders that systems thinking is one of the most valuable approaches to architecture, and one that will often also help in dealing with that inherent uncertainty. It’s especially useful in navigating through the “uncertainty” domains – particularly the Ambiguous, perhaps less so in the Not-known.

Note that the type of systems-thinking referred to here is what’s sometimes known as “soft-systems theory,” which particularly relates to human systems. There’s a quite different type called “hard-systems theory,” which is more about feedback loops and delays, and which more properly belongs in the extreme end of the Complicated domain. It’s important not to confuse the two approaches, because they work in very different ways: for example, hard-systems theory assumes repeatability – in principle, at least – whereas soft-systems theory doesn’t.

We started out looking at enterprise architecture, but quite soon came across the fundamental distinction between “organization” and “enterprise”: an organization is bounded by rules, but an enterprise is bounded by values. Failing to grasp this distinction was a key source of problems for the bank, for example: they’d viewed their market and the broader enterprise as an extension of their own organization, and hence as something subject to their “control” – which it wasn’t. And the enterprise itself comprises people, hence person-to-person communication really does matter – both in the bank-example, and also throughout our own architecture.

Finally, the enterprise has and is a story – for which the core of that story is the enterprise vision. And as we’ve seen, architecture has a fundamental role in identifying that story, in linking it to the structures and purpose of the organization, and in promoting that story throughout the enterprise as a whole.

What Was the Source of the Difference?

The aim was to use architecture methods and related methods to describe how to do real architecture-development in real-time. And the topic for the architecture-project was architecture itself; and the intent was to document all of that in the form of a book – this book. The stakeholders for all of this were architects, and clients of architects; and we did follow the defined Agile-style architecture development-process. All of that we did indeed achieve here: no real difference between plan and execution.

The production of the book did take a fair while longer than the nominal ten days – just under 30 days from start to finish, in fact. The reason for the difference is that all of this does take a lot longer to write than it does to say… And although the intent had been to use hand-drawn diagrams, to convey the immediacy of the real-time work, the idea unfortunately didn’t work in practice – all of the diagrams needed to be redrawn to make them more readable within the much tighter space-constraints of the printed page. It is true, though, that all of the actual architecture work was completed within the stated time: ten working days, one day per stage, exactly as shown here.

There was a lot more repetition and revisiting of the same themes than is usual in this kind of book. I’ll admit that, as a writer, this amount of repetition can feel somewhat disconcerting at times, but it does seem to be required by the nature of the work itself – iterative, recursive, re-entrant, reflective. We often arrive back at what may seem to be the same place, yet each time it’s from a different direction, and with a slightly different view – hence adding more detail, more depth and richness, to the holograph-like map of the enterprise.

Another theme was that while a conventional textbook would follow a standard order and structure, here our aim is to illustrate the uncertainty of architecture – which, almost by definition, must sometimes force us into somewhat strange places. The standard architecture-process is usually described as a Simple sequence of steps, but the moment we touch the real world, those steps – and the process itself – will soon become Complicated, Ambiguous, and even Not-known. And that is how it should be – otherwise it wouldn’t be much use in the real world. Much of the process of architecture is inherently uncertain – and there are real difficulties that arise from that fact. Likewise the results of that architecture-process are always somewhat uncertain: we should know beforehand what we aim to achieve, but that really is almost the limit of our control over the results themselves. If there isn’t at least something that’s unexpected, we probably aren’t doing architecture. In that sense, the development of the architecture-story here does reflect the sense of inevitability of uncertainty and ambiguity – even though that structural uncertainty was not part of the original project-plan.

The bank-example was also not part of the original plan. It soon became obvious, though, that the project needed a concrete real-world example of the use of these ideas and themes, rather than only one that should make sense to experienced architects but perhaps be too abstract for other people elsewhere in the business. This extra example added another facet to the overall layering within the project, yet without disrupting the intended timescale – a definite bonus.

There’s one aspect of sensemaking with context-space maps that may not have been adequately covered here, namely, the dynamics of sensemaking. “Go for a walk around the map” is a good overall summary of what happens, but perhaps not enough to describe the way in which the focus and even the mindset will change – and need to change – as we move around within that conceptual space. The tactics that we use in the Simple domain, for example – sense what’s going on, choose an option from a checklist, and act on it straight away – are crucially different from those we need to use in the Not-known domain, which will often oscillate wildly from the old “don’t just stand there, do something!” to a more Zen-like “don’t just do something, stand there!” so that the new information that we need can arise in its own way and time. Yet this is not at all easy to describe in words: it does seem, unfortunately, that it is one part of architecture that’s so personal that it’s best explained through experience alone.

What Can We Learn from This?

This is where architects’ experience comes into the story, because we need to know how to “walk around” among these domain-views of the process in order to use the process in architecture. The process becomes a context-space map of itself, which we must then use as a context-space map to help us to use other context-space maps – a lovely example of the kind of extreme recursion that’s all too common in architecture-work. And trying to explain that kind of recursion to others, without sending their heads spinning, is not easy at all: that’s probably one of the less-helpful lessons from this overall exercise. Must Do Better Next Time, perhaps? But this is the process, however chaotic it may seem at times – and we do need to follow it as best we can, wherever it may lead us in the end.

In contrast, the architectural notion of the parti is one of the most useful items that came out of this exercise. In some ways it’s like a “solution,” though not a solution as such – more an architectural motif that arises seemingly from nowhere, yet acts as the constant mirror against which everything else is reflected. Importantly, it’s likely to turn up right at the start of the architecture-cycle, at that moment where we’ve understood the project-brief and make the first move outward from “the unknown” into a subtle, almost-chaotic space where, for a very short time, it seems that anything and everything could be possible. That motif is often only visible for one fleeting moment, so we need to allow ourselves to become quietly aware of it – which is rarely easy in the circumstances. But if we can allow this parti to appear, it makes all of the work much, much easier, because it acts as a central unifying theme around which all other information and ideas can coalesce.

In his book The Secrets of Consulting, the great computer-industry consultant Gerry Weinberg alludes to the same kind of motif occurring in consultancy-practice. Whenever he goes on an assignment, he says, “I always get the answer in the first five minutes” – though it can often take him hours, or days, or weeks, to recognize what it was that he saw in those first five minutes…

In one example in that book, the first blurted greeting by a young staffer was a near-frantic “How can you get away without wearing a tie on business?” – the problem in that company turned out to be excessive formality, sticking to the rules even when the rules didn’t work.

One of my own best examples was from many years ago now. It was in a trouble-shooting job for a typesetting bureau: the stench of film-developer chemicals literally slammed into my nostrils as soon as I opened the front door. The company was excellent in its handling of the computing side of the business, but slapdash in almost anything to do with the physical world – which meant that much of their output was ruined by poor-quality film-processing and the like. “I get the answer in the first five minutes”: one of the most valuable lessons I’ve ever learned in consulting – and in architecture too.

The parti in this case, for example, was that tag-line that came up almost at the start of Day 1: “things work better when they work together, with clarity, with elegance, on purpose.” Everything here has in some way been about purpose, about being on-purpose, about clarity of purpose. It’s certainly been true of the worked-example of sensemaking and decision-making; and especially so for the bank example, because, as we saw, respect is intimately interwoven with clarity of purpose – hence, in their case, the importance of that focus on vision and purpose.

But it’s also important to note that the parti is not a solution: it’s more about a feeling or focus or overall direction, rather than some kind of explicit action. That initial feel of the parti is often right, but initial ideas about implementations usually aren’t – which is why we must take care to shelve all would-be “solutions” until the time is right to look at our options for implementation. And while the feel of the parti will usually remain much the same throughout the process, its outward form may change a lot – hence the iterative nature of so much of architecture-work, over and over, turning and returning, watching carefully while the details of the picture subtly change around the constant core of the parti.

These are the “lessons learned” that I’ve derived from this overall exercise. What you’ve found will no doubt be somewhat different, because each of us comes at the work from our own background, our own specific experiences, and each of us will learn in our own different ways.

Yet for all of us, there’s always more to learn – always. In some ways, that’s the whole point of architecture, really: to create, and to learn. And to find new ways to make things work better, work together, with clarity, with elegance, and on purpose.

Application

Summary

In this chapter, we again explore the use of an after-action review, this time applied to the book-project as a whole. This presents a further illustration of how architectures can and often must change as we go through from initial idea to assessments to plan and final implementation. The “Application” section at the end of the chapter provides questions to help you apply this in your own work, and to review what you’ve learnt throughout this book.

The main “deliverables” for this chapter are the changes in your own view and experience of architecture and architecture-practice.