By this point in the architecture-cycle, we would hope to have achieved something. But what did we achieve? With what benefits, and for whom? What can we learn from what we’ve done? And what should we do next?
So we here return to architecture-governance to do a “lessons-learned” review – a Retrospective, in Agile terms – in relation to the respective business context, and identify any needs for further related architecture work.
In a conventional large architecture-project, this would be a major phase in itself. The TOGAF standard, for example, treats it almost as a project in its own right, with the main aim of defining key themes for the next multi-year architecture-cycle. A more mature architecture environment would be able to run several projects in parallel, all at different speeds, with implementations varying from hours to years. For the mid-range, a separate review stage here may make less sense, and this part of the work may instead be done as part of a regular review meeting, perhaps once a month, adjusting the scope to assess whatever’s been completed during that period. And when we get right down to the smaller scale, as in our examples here, it becomes best to lock the review to the respective architecture-cycle again, so as to ensure that the proper governance is applied in each case.
The “environmental-scanning” part of the work that TOGAF describes for here – assess changes in the business-environment, actual and potential developments in technology, and so on – still needs to be done, of course, together with the continual reassessment of the architecture itself. But in a more mature architecture-capability, that would typically be actioned as a distinct architecture-cycle in its own right, rather than patched onto other architecture-projects almost as an afterthought.
So the review here should concentrate mainly on the specific business-problem with which we started this cycle. The “holographic” nature of the overall architecture always allows us to include the broader context, but as an automatic side-effect of that review rather than a somewhat artificial focus on what may well be a separate topic entirely.
Here the two types of governance – architecture-management and change-management – will need to come together to share the exploration and reassessment of what’s been done. But while the governance may need to change a bit to suit the scale, the review-steps themselves are essentially the same in each case – and as usual, we need to keep it simple, and fast.
What was supposed to happen? – for which we need there to have been some kind of plan on which we would act
What actually happened? – for which we need to have been able to observe what was going on, while it was going on
What was the source of any difference? – for which we need to be able to orient ourselves and make sense of what was going on
What can we learn from this – for which we need to be able to decide on possible changes to the way we think and work, and commit ourselves to those changes
Which, as you’ll no doubt have noticed, is another variant of the OODA cycle, in effect offset by one half-step: we Decide what was supposed to happen; we Act, which makes things happen; we Observe what actually happened; we Orient ourselves to interpret the source of any difference; and we Decide what action to take, to change what should happen next time.
There are also two fundamental rules for an after-action review: “pin your stripes at the door,” and “no blame.” In essence, these are both about responsibility: whatever rank each person might have in their hierarchy, each had their own responsibilities, their own role to play; and we’re here to learn, not to blame. Those two rules may not matter that much in the work we’re doing in this specific context here, but they certainly do matter in the often-fraught, politicized contexts of most real enterprise-architecture: building those rules right into the core of architecture-governance really does help.
But on to our two projects, anyway.
Main Project: What Next for Our Architecture?
What do enterprise-architects do?
How exactly do they add value to the business?
Use architecture ideas, models, and methods to describe how to do architecture-development, in real-time.
The topic for the architecture-project is architecture itself.
Document this in book-form, as text and images.
Allocate a timescale of ten working days.
Our key references include the project-diary, the various diagrams and models, and any other notes we may have collected along the way. Overall, though, it’s probably simplest to review this in terms of the respective phases of the architecture-cycle.
Phase A: Set Up the Architecture-Cycle
Back at the start, we quickly settled the more administrative items, such as the purpose – “improve understanding of how to work with the architecture of architecture” – and the stakeholders for the architecture-cycle – us, mainly – along with other themes such as time-horizons, level of detail, scope, and so on. Those were straightforward. Less straightforward was the awkward feeling of uncertainty – “I don’t know what I’m doing” – which we resolved partly by sticking closely to the predefined process, and also just by doing something to break the initial inertia.
The “something” in this case was a brief wander around various ideas from other disciplines – in particular, a very close parallel with scientific investigation, which, as we saw, is itself more like an art or craft than a “science” as such. From that, we decided to include within the themes for this architecture-cycle rather more of an emphasis on “the technicalities of making the best use of the architect’s mind” – particularly those aspects that deal more with “unorder” and uncertainty, with which architects clearly need to excel.
One side-theme that came up was the importance of holding back on any supposed “solutions” until the appropriate time – not during assessment, but only after all assessment is complete.
And other themes that were of note included that emphasis on the importance of improving architects’ speed of response to clients’ needs; on overall effectiveness rather than local efficiency; and the need for the architecture to be able to cover a whole-of-enterprise scope, rather solely that of a single domain or sub-domain such as IT. We also described architecture itself as “a body of knowledge about enterprise structure, story, purpose and value.”
No particular “lessons-learned” there, probably, other than that it’s not often that we can be explicit about how uncomfortable it is to deal with that initial uncertainty – but we do need to be honest about it, and not pretend that it doesn’t exist.
Phase B: Assess the Primary Time-Horizon (“To-Be”)
We’d previously decided to do the assessment “future-backward,” starting with the “to-be” as the main focus for assessment. Again, this brought up quite a bit of that feeling of “spinning in circles, no traction, no place to start,” but we dealt with it simply by getting started, by following the suggested steps for this part of the process. This led to a focus on sensemaking and decision-making, with architecture usually taking a decision-support role for others; and also on four sets of tools or concepts that we would apply throughout the cycle: five-domain context-space mapping, five-element lifecycle-model, five principles from systems-theory, and a “segments-model” rework of the classic Zachman framework commonly used in existing enterprise-architecture.
Using one of those systems-theory principles – recursion – we then used those four tools to look at what we needed from the “to-be” architecture-of-architecture, including the four tools themselves, and the skillsets needed for the work.
It’s too early to describe any benefits as yet, though the main lesson-learned is the value of being able to wander off onto side-alleys as needed, yet still having a predefined plan to which we can return at any time if we start to feel lost.
Phase C: Assess the Comparison Time-Horizon (“As-Is”)
The overall structures for architecture at present seemed much the same as in our “to-be”; the main difference was in scope. Almost all of present enterprise-architecture centers around IT, although some may also extend toward or include more of the organization as a whole. Very little encompasses the entire extended-enterprise – the scope we’d identified as essential for the “to-be” architecture. Yet so dominant is this IT-centrism that often, the only way to explain what enterprise-architecture needs to be is by describing what is not a valid enterprise-scope architecture.
It was also clear that at present there seems very little public awareness of the actual processes of architecture – moving beyond mere method toward meta-methodology and meta-thinking, the “thinking about thinking” that’s essential to improve skills in practice.
The problems highlighted here can often be quite subtle, but their sheer scale is often a real eye-opener. Much of what passes for “enterprise-architecture” at present is little more than design for large IT-systems: the lesson-learned here is that there is still an urgent and mostly unaddressed need for a true “architecture of the enterprise.”
Phase D: Assess Gaps Between As-Is and To-Be
Other themes that came up in the gap-analysis include the value of recursion within architecture itself, and a huge list of items to address that come up from a closer look at that notion of “the art of architectural investigation.” From there, we noted also a need for our architecture to focus on overall effectiveness – indeed, that that theme forms a key part of the “value-proposition” for enterprise-scale architecture. But there are so many apparent requirements and options that we’re forced to prioritize: the need to enhance the speed and, if possible, the accuracy of those “art-like” processes for making sense and making decisions in architecture would seem to come to the top of the bill here.
Probably the main lesson-learned here, again, is the usefulness of systems-thinking principles in architecture, both for sensemaking and for preliminary designs. But there’s also the importance of avoiding “analysis-paralysis” – in this case, we did that avoidance by holding to a strict Agile-style time-box of a single day for the gap-analysis itself.
Phase E: Decide on What to Do About Those Gaps
Following the usual recommendations in the architecture-process, we did a literature-search, which turned up two likely candidates to match our requirements: the Observe-Orient-Decide-Act (OODA) cycle, and some of the underlying ideas from the SCAN framework. Neither of these could be used as a prepackaged “solution,” but it did seem that, with some adaptation for architecture, the two could be merged together as a kind of “inner cycle” for sensemaking and decision-making, within the main architecture-cycle. There would still need to be a focus on speed – a focus which is already built in to OODA – and also to ensure that the implementation is fast, too.
The main lesson-learned here is that the most useful options for this purpose have all come from outside of architecture itself: a point we should certainly remember for other more mainstream applications of architecture.
Phase F: Develop a Detailed Action-Plan
What quickly became clear during this phase was that using those two items as simple checklists will not be enough: we’d not only need to merge OODA and the SCAN base-frame, but also show how to use them in architecture. The point here is that this was about “intangibles” such as the feel of architecture as much as it is about process and practice: we would need to find some way to get the balance right.
This brought us back to a focus on architecture as a generalist skill, and thence to a brief exploration of the tactics needed to support the development of new skills and techniques. The result was that our “action-plan” would be to use text and visuals to describe – or perhaps imply, or allude to – the kinds of skills needed in order to enhance our architecture. We’d also need practical examples, to bring these ideas down into usable form. Recursively, one of these examples would be this discussion itself. The other example would emphasize the point about the true breadth of architecture scope by using a real business-problem with whole-of-enterprise impacts.
One lesson-learned here, again, is that that uncomfortable feeling of uncertainty is both normal and to be expected at the start of this phase. Knowledge of that fact can help a lot to reduce some of the inherent stress of this stage… Another extremely important lesson is the reminder that not every context needs an IT-based “solution” – in fact may not need any “solution” as such at all. The challenge is always to find an appropriate answer to the needs of the context – and not try to force the context to fit whatever “answer” we may happen to have at hand.
Phase G: Execute the Action-Plan
For large-scale enterprise-architecture, the role in implementation will often only be in decision-support or compliance-management. In this case, though, the architecture had been the core of the implementation, using architecture itself to explore what architecture is, how it works, and what we need to do to make it work better, make it work faster. And the way we did that here was by exploring in more depth the process of sensemaking and decision-making that underpins every aspect of architectural skill.
Some of the themes covered in that exploration included sources for sensemaking; how to deal with inherent uncertainty; and how and why to hold back from making decisions too early. We also looked at different types of base-maps and cross-maps for different tasks in sensemaking; the importance of being clear which maps we’re using at any time, and why; and the dynamics of “taking a walk” around these maps of context-space. Some of the base-maps also addressed specific themes such as business-architecture; there are other examples on this later in the book, in Appendix B. A further theme was on “problem-space” versus “solution-space,” and the need to keep them apart until the moment of decision – hence those explicit boundaries between assessment and solution-design in the architecture-cycle.
Lessons-learned? It’s difficult to say for certain, although reviewing the discipline of analysis and exploration has been useful in itself, I would hope. What’s clear is that it is still remarkably hard to explain what it is that we do as architects, or how we actually do it. Whether this has been of practical benefit to your own architecture practice is something only you can decide, and perhaps only over a much longer timescale than one reading of a book.
Phase H: Review Our Progress So Far
Which, in yet another kind of recursion, brings us to here, the review of the review.
At this point, it’d be worth skimming back over those preceding summaries, to take note of the lessons-learned at each stage. Another item for that list would be the reminder of why this “meta-thinking” is so important to the discipline of architecture – and also that yes, it is hard work, much more difficult than it may seem at first glance.
Perhaps most important, though, is that the benefits need to be assessed not in terms of theory, but in how we apply it in our real-world practice – such as through using architecture to tackle that pressing problem of respect at the bank.
Example Project: What Next for the Bank?
participants took key learnings from visioning into their strategy-session, became first real strategy-work they’d done in years people really talking with each other – photos on function-model as literal conversation-starters new focus on effectiveness across whole organization “better financial futures” vision-tagline did act as anchor/focus for strategy-session |
So yes, a lot of real value gained, he says. But he doesn’t quite see how this links in with that initial theme of respect – which is still as serious a problem as before – and he also wants to know where it should go onward from here.
To explain all of this, we need to do a brief lessons-learned review, quickly skimming through all that we’ve done, step by step.
The original brief, in what became our Phase A for the project, was around the problem of loss of respect, affecting the whole organization from the outside at least. So the initial idea was to develop something that could help the executive tackle this, yet with the minimum possible disruption, as the organization was already over-stressed from “change-fatigue” after a recent merger. The change-manager could see the cultural issues and impacts, but the current CEO was essentially a “numbers-man” who showed little interest in how his organization actually worked as long as it could deliver the short-term results that he wanted. So our aim, as we’d agreed, was to set up a suitable high-level “architecture of the enterprise” that the change-manager could then leverage in subsequent work.
Working with him, we’d set up a couple of workshops – our Phase B – to gather information about the current context. What those indicated was that the problem of respect pervaded not only the organization’s external relationships, but within the organization itself – a rather worrying “lesson learned” from that exercise. We’d then used architectural assessment techniques, such as POSIWID and five-element lifecycle-models, to identify and highlight some of the underlying systemic issues. From there, he’d given us the go-ahead for another brief exploratory session with selected staff, to gather further information about the current context, and the difference between past and present.
The results of that session, which again had some fairly painful “home truths” for our clients, became the basis for the “past to future” assessment – our Phase C. We had some good examples of what respect looked like in the past, and likewise its absence in the present. It quickly became clear that the conceptual structure of the organization was essentially unchanged between past and present; what had changed was policy, particularly a new near-obsession with “shareholder-value” from the parent-corporation. It was also clear, though, that this was an “undiscussable” issue: it had to be accepted as a “given.” The only practical option would be to find another way round the issue while leaving the policy itself unquestioned, no matter how much damage that policy might cause. The most likely clue for action seemed to be that this was essentially about people’s feelings in relation to the company and each other. As a qualitative issue, financial incentives or attempts at “control” would not work, but a more direct focus on feelings and commitments might have more success.
We’d reported on that to the client, and then turned to the gap-analysis – our Phase D. Given the unambiguous instruction to treat the policy problem as “undiscussable,” we explored various other avenues of difference between past and present, of which the best prospect seemed to be the theme of collective identity and unity – a “totem-pole to unite the tribes.” We’d done similar work in other organizations, and had found that the combination of a shared description of business-functions with a specific type of “vision-statement” would provide a common point of reference, enabling stronger respect for each other’s work, and also providing a focus around which external respect could accumulate.
We then set up another brief meeting with the client to present our findings, and then discuss options for further action – our Phase E. We’d suggested that we could perhaps present a seminar on function-models and visioning for his change-management team; we were somewhat taken by surprise when he instead asked us to present it as a workshop for the full executive and senior management team – in just two days’ time. The “lesson-learned” for us there was the necessity to be able to re-think an entire architectural approach at a moment’s notice…
So we then had to adapt or develop a complete half-day workshop for executives, in just over a day – the only time available for our Phase F, the detail-plan stage of the architecture-cycle. Our usual structure for a workshop of this type would run for several days, and for a group of architects, not executives; but by applying some radical pruning we arrive at a session-design that would fit within the half-day timeslot that was available to us. A useful lesson here, perhaps, is that it is possible to strip away many of the conceptual items that we would usually regard as “essential,” to derive that which really is the essence of that part of the architecture.
On to actual implementation and delivery – our Phase G – in a rather different role from the architects’ usual one for this part of the architecture-cycle. And while we’re eliciting the information needed for a high-level values-architecture for an organization, we’re also in effect teaching the basics of whole-of-enterprise architecture to a somewhat special audience – creating engagement in these otherwise abstract ideas by making it personal for them with their own photographs and their own direct involvement. In the process of creating the function-model, there are key lessons about overlapping responsibilities, and other areas which have almost no mutual support – and the model also enables, and invites, new conversations across the enterprise by the simple yet literal fact of bringing everyone together “on the same page.” The visioning process is challenging at times, but is likewise about connecting with other people, both within and beyond the organization. The key point here is that it’s not about marketing as such – a point that did take quite some time to get across to the executive – but is again about creating conversations, a “conversation-with” rather than the usual marketing “talking-at.” And through all of this, we still managed to avoid any of the “undiscussables,” and even the term “architecture” itself – even though all of it was actually about the architecture of the enterprise.
Which brings us to this follow-up meeting – in effect, our Phase H review for this project. There are really two areas of focus here: the respect problem, and architecture in general. Although they’re closely linked, it’s probably best to keep them separate at the start.
The core of the respect-problem is the change in policy, to focus on short-term “shareholder-value” at the expense of almost everything else. This has huge yet often subtle knock-on effects, particularly in terms of damage to trust, which in turn impacts on respect. Yet no-one can even discuss this policy, let alone challenge it. For the bank, as a subsidiary of a much larger organization, that policy – however destructive – is effectively a strategic “given,” almost as much as the laws of the countries in which they operate. So the only other option, such as described in economist John Kay’s book Obliquity, is to come at it from some other direction.
The key here lies in what we sometimes describe as the “performance paradox”: that we get the best performance in a given value by paying attention to everything except that specific value. It seems counter-intuitive at first, but as John Kay and many others have demonstrated, there’s plenty of hard evidence to show that that it really does work that way. And it’s actually what we would expect once we think in terms of terms of systems-theory rather than conventional linear analysis: the infamous “bottom-line” is a complex non-linear derivative from many non-reversible and non-replicable factors, which, in less technical terms, means there’s no way to run the calculations backwards from the desired bottom-line result to any of the factors that we can actually control.
So, for example, to get the best financial return, we need to keep the focus on something other than financial-return. Hence one of the main reasons for choosing to emphasize enterprise-vision: it provides exactly that kind of focus that we need here, a central reference-point around which all of the key factors that feed into that bottom-line will naturally coalesce. Within the organization, internally, the vision provides a consistent yardstick against which we can assess whether anything and everything is “on purpose” – which, in turn, will drive the bottom-line.
The other key point is that the vision is perhaps even more about external contacts: it gives people a reason to start a conversation with the company, and also, again, gives a clear test for others as to whether the company is “on purpose.” And it’s from those conversations that the desired respect – and, in turn, those needed transactions – should ultimately arise.
So there’s plenty of work right there for our client and his change-management team. The vision becomes the central anchor for a values-architecture that needs to pervade the entire organization: every metric needs to align with the vision, for example; every item of marketing; every aspect of training; all bonus-structures and performance-measures, for teams and for individuals. The only area, in fact, that would not need to be touched by this is the final financials: which means that, this way round, we can safely leave those “undiscussables” undiscussed.
On the other side, the work on the function-model, we suggest that it would be well worthwhile to extend that exercise quite a bit further, to fill in the remainder of the tier-2 overview and make a solid start on the tier-3 detail. Our experience elsewhere has been that a function-model diagram that’s fully populated at tier-3 has huge and immediate value throughout the business, as a tool for coordination and communication across all of the silos, and also for planning and project-management. We’ve seen it used for training, too, to show new staff where their work fits within the whole. We’ve even seen it used for cost-management, and cost-based prioritization of change-projects. Overall, it’s one artefact that immediately sells the idea – and the value – of architecture to the business in general.
Yet even more, as with the vision, it’s a tool for conversations. It places everyone on the same page – literally. When it’s physically large enough – as in our example – we can attach photographs or other items that personalize that picture, instantly enabling a more direct and human level of communication between people. And that kind of connection brings enormous returns, in time saved, in problems avoided, and in improvements in the general ease and flow everywhere across the organization. All of which eventually flows downward into the bottom-line.
What happens next? Well, that’s up to the client in this case: we’re only external consultants. But there’s a lot of work there that could be of huge value to them, as they can see: and we’ll be glad to help in that, any way that we can.
Application
How do you review the value of your architecture work? In particular, how do you identify benefits realized and lessons learned?
How do you describe and demonstrate to others those benefits of that architecture-work – especially if the benefits are not tangible, or cannot be described in simple monetary metrics?
What do you learn in this review-process? What challenges or changes does it suggest, for the architecture, for your own skills or actions, or those of others? What actions do you take on any lessons-learned? How do you ensure that you enact any commitments to change that arise from those lessons-learned?
How do you engage your clients and other stakeholders in these review-processes? What do you each learn from this? Perhaps especially, what do you learn about architecture by working with people who are not architects?
What happens when the architecture plan needs to change at a moment’s notice? How do you manage the sense of confusion and disorientation that arises from this? How quickly can you re-think your overall plan? What do you need available to you in order to do so?
If you’re used to working with system-designers, project-managers, and other architects, how does it feel when you’re suddenly asked to present to a group of executives? In what ways does the story need to change, and why? How does the architectural story change with other audience-groups too, such as operations-staff, or vendors, or business-partners and other direct peers?
How do you demonstrate the linkage between architecture and key business issues? In particular, in what ways would you use the architecture to resolve those key business problems while safely sidestepping any “undiscussables”?
Summary
In this chapter, we explored how to do an after-action review, and how to make use of the information gathered from that review. We went step-by-step through both projects, identifying the outcomes and lessons-learned from each phase of the respective project. The “Application” section at the end of the chapter provided questions to help you adapt those principles and practices for use on your own organization’s context.
The main deliverables from this chapter were the notes taken during the reviews, and the list of suggested follow-up actions.
In the next chapter, we’ll apply the same kind of review to the broader project of this book as a whole.