Step 1: Develop Baseline Architecture for “To-Be” Context

It’s quite probable that, as yet, we don’t have anything about architecture itself in the information-stores, because most people won’t think of architecture as a subject for architecture. But if we do have any, we note that information, and perhaps build a small set of views and reference-models if it seems useful. In any case, we’ll only need to do this once, as a known baseline to return to if we get lost during the various iterations of the assessment.

We’ll use that as an initial baseline.

Step 2: Select Reference-Models, Views, Viewpoints, and Notational Standards

That should give us enough to start with for now.

Step 3: Create and Update “To-Be” Architecture Models

Here we expand the baseline architecture into a comprehensive architecture for the iteration context – in other words, the architecture of architecture.

We won’t do this in much detail here – just enough to get started, because the real changes will occur as we apply it in practice over the coming days, weeks, months, and years. What we look for here are ideas or themes that would describe our “architecture of architecture,” and core requirements for that capability within the enterprise.

This aspect of assessment is mainly about sensemaking, and is also going to be iterative and somewhat chaotic – so, at the start, we deliberately allow it to be “chaotic,” a free flow of ideas, and then allow some kind of structure to emerge from there.

We could summarize this visually, as shown in Figure 3-1:

An illustration of a context-space mapping. The four aspects are complicated in theory, ambiguous in hypothesis, not-known in idea, and simply in law.

This also clarifies the crucial distinction between architecture and design. They’re actually flip sides of each other, but architecture faces toward the big-picture, the abstract, the overall aim or purpose, while design faces toward the detail, the concrete, the practical. On its own, architecture does almost nothing – it’s only when it is literally “real-ized” through design that it becomes useful. Yet it’s also where we’re forced to be honest that everything we do is actually a subjective choice – whereas design can often pretend to be “objective,” because by the time we reach the design stage, we’re already following predefined rules. We could summarize this as in Figure 3-2:

An illustration of design and architecture in certain versus uncertain. It has four factors named complicated, ambiguous, not-known, and simple in certain and uncertain forms with design and architecture.

The outcome of this is that we need our practices to reflect where architecture sits within the overall functions of innovation and change: it’s clear that it must have a large element of sensemaking as a precursor to design.

Next, compare against the systems-theory principles.

First of these is rotation, which is clearly central to much of our work: we rotate between multiple views and viewpoints, or work our way through checklists. We will want to use this both in any architecture that we create, and in the processes of architecture itself. In terms of context-space mapping, it’s a Simple-domain technique: quick and easy, but with the risk that we have no certain means within the technique itself to assess whether the checklist is complete, or is the right one to use in that context. So while we will collect many different “rotations” for our architecture toolkit – another addition to our requirements-list – we would also need other techniques to select the appropriate ones for each context.

The architecture-development process is another “rotation,” in that it provides a step-by-step sequence to follow – though note that it, in effect, defines a default set of steps, rather than the sequence that we would actually follow in practice. So again, other techniques would be needed to decide when to deviate from the default path, and when to return to it.

The next systems-theory principles are reciprocation and resonance, which, in practice, act as a matched pair, mainly in the Complicated domain. These will form a much-valued part of the architectural assessment toolkit, particularly to model dependencies, feedback-loops, and delays to optimize balance and effectiveness across the enterprise. But they may not apply that much within architecture itself: it might be useful to model some of the loops and delays in the architecture process, but that’s probably all that we would do.

The final pair of systems-theory principles, recursion and reflexion, are fundamentally important to architecture itself – perhaps a key part of what distinguishes architecture from design. In terms of context-space mapping, they sit mainly in the Ambiguous domain, though also spread to other domains from there – for example, one of the key benefits of using recursion is that it can make designs a great deal simpler. The kind of architecture approach we’re using here is itself highly recursive, applying the same basic principles in every part and at every level of the context and enterprise, while the architectural notion of the unifying parti represents a highly desirable example of reflexion.

Next, compare against the five-elements lifecycle map. Architecture itself is primarily focussed on the dynamic relationships between structure and purpose, which tells us straightaway that there’ll be an emphasis on the Purpose and Preparation phases of the lifecycle. This in turn indicates the need for a great deal of attention on the People phase that acts as the bridge between them – which is what we see in architecture practice, of course, as shown in Figure 3-3.

A pentagon shape flow diagram of architecture emphasizes the lifecycle. People create a balance between emphasis, preparation and purpose have a natural emphasis. Process and performance do not have a strong emphasis.

Architecture has its own Process activities, though it’s not much involved in those of others elsewhere in the enterprise; but there would need to be significant attention paid to “bottom-up” themes coming from the production contexts, and also to metrics and the like both for and from the Performance phase. Note too that this five-element lifecycle is also an important example of architectural recursion – the same elements repeat at every level and in every context.

Finally, the segments-model framework. Back in Step 1 we noted the respective scope from the project-diary – mainly about people and capabilities, though we also need to look closely at information (virtual assets), at people-based events and, especially, motivation and decisions in general. These emphases are shown as the darker-colors in the segments-model diagram here (Figure 3-4).

A 3-dimensional block of a triangle represents a model of segments. The base displays an example of asset segments, height displays layer segments, and width is an example of component segments.

Architects also need to be consummate generalists, because they need to be able to link together every possible aspect of the enterprise, talk with anyone, and communicate meaningfully with the specialists in each area. (Soft-skills and EQ will often be even more important here than hard-skills and IQ.) The architects will usually need knowledge in breadth rather than depth – the respective specialists will handle most of the latter, although most enterprise-architects will also come from a specialist domain themselves. But even though the architect’s depth of knowledge in any one skill may be quite low – sometimes just a basic understanding of key principles and technical terms – the sheer range of skills that need to be learned at the full enterprise-level scope may take literally decades to acquire: so despite the claims of some training-providers, true competency in architecture is not something that can be picked up in a simple one-week workshop!

On assets, we’ve already listed the tangible information used in architecture: items such as glossary and thesaurus, governance-records, risks and opportunities, requirements, and many, many models. But in some ways, what’s even more important is the intangible information (a composite of virtual and relational asset, in framework terms): all those conversations and workshops and whiteboard-sessions that are so central to stakeholder-engagement and architecture practice.

If the only available architecture capabilities and competences are in IT, then ‘enterprise-architecture’ will appear to be IT-specific, and so on. Yet, to extend our enterprise-architecture to the whole business and beyond, we don’t need to change the architecture functions as such: we just need to extend the available capabilities – the range of skills experiences included within the architecture.

Architecture locations may be physical, virtual, or relational, but the latter are by far the most important of these – as in the old adage that “it’s not what you know but who you know,” and how and where to find those people. In the same way, we’ll also need to know how and where to find the right information, the right decisions, and so on. But for architecture itself, we most need to know the decision-makers – which, in practice, comes down to real people, and hence the locations of those people.

The events for architecture itself, again, are mostly “people-events” – relational events. (There may also be a few time-based events such as regular scheduled reviews.) These connections may come in many forms – emails, task-requests, and many, many meetings – but the notion of an “event” that triggers a request for action is useful here.

In principle, the decisions assessed and acted on by architecture should again be able to cover the entire enterprise scope, at every level, from “universals” to real-time action and review. The architecture will need some explicit means to describe the purpose, role, dependencies, and jurisdictions of any or every decision in scope – the domains of the base-frame (Simple, Complicated, Ambiguous, Not-known) being one such categorization we might use for this. We would also need mechanisms to enable us to create a complete audit-trail for any decision, all the way back to the core-“universals” for the enterprise.

For each of these entities in scope – assets, functions, locations, capabilities, events, decisions – we would need a complete, fully maintained RACI matrix (responsible, accountable, consulted, informed) of all related stakeholders. (That’s an ideal to aim for, anyway, though it may be impossible to achieve in practice.) This would tell us who would be affected by any architectural issue, who we should engage as active stakeholders in any assessment or review, and what clashes are likely where responsibilities and accountabilities overlap.

Given the models we started with, this would complete the first pass of the assessment. It might well be useful to loop back to the start and quickly scan through again to see if any other themes or ideas come up. In any case, we should document the results in the project-diary.

Step 4: Review “To-Be” Architecture Against Qualitative Criteria

The usual suggestion for this is that the core qualitative concern for capabilities is performance-management. Yet in practice, that’s only one of the concerns here: we also need to add “universals” such as security, health and safety, business ethics, knowledge management, and the like.

For each of these, we need to identify appropriate critical success factors (CSFs) and metrics for key performance-indicators (KPIs). Which is not going to be easy, because the whole point of architecture is that it’s about linking everything together – hence, in principle at least, its success can only be measured in terms of the whole.

Many of these metrics and suchlike will depend on the industry and enterprise, so I won’t attempt to list them here; but the final lists should be documented in the project-diary, as usual.

Step 5: Finalize Building-Blocks for Architectural Scope

This is a step that we will probably have to skip over here, because it’s not practicable in this context.

The “by the book” notion of Architectural Building Blocks and Solution Building Blocks, as patterns for re-use, is very useful in most parts of architecture. But architecture itself depends almost entirely on people-based capabilities – otherwise known as “skills” – and the concept of “re-use” doesn’t work in the same way with people as it does with software or machines or other physical “things.” One important reason is that people embody skills in very different ways to those in which we build capabilities into machines or software; another is that most of the architect’s skills are in the “uncertainty” domains, which are naturally not amenable to simple re-use. Either way, probably best for now to document it as “not applicable,” and move on.

Step 6: Conduct Checkpoint-Review for Stakeholders

If necessary, we could loop back to the preceding step 3 to re-assess our architecture-models and the list of requirements we’ve derived from them.

Once we’re comfortable with that, we’re ready to move on to do the same kind of assessment with our current or “as-is” context for “the architecture of architecture.” Before we do that, though, we need to do the first assessment for our example-project.

Step 1: Develop Baseline Architecture for “As-Is” Context

This is short and sweet – or not-sweet, rather, because as yet we have no information available from which to derive that baseline.

In principle, we could derive at least a partial baseline from publicly available documentation such as the organization’s annual report, together with some quick interviews with relevant stakeholders. In this case, however, it would have taken several days to do it, which we didn’t have available to us, and we didn’t have the permission to do it anyway.

Step 2: Select Reference-Models, Views, Viewpoints, and Notational Standards

Ideally, we would model for a wide range of viewpoints, both inside and outside the organization. Realistically, though, we’ll have to make do with whatever viewpoints we can derive from that pair of workshops, together with any information we can glean from other sources about the views of “outsiders.”

Step 3: Create and Update “As-Is” Architecture Models

The first stage of the assessment is the two workshops: we’ll then develop suitable models from the results.

Workshop for Executive-Team

This is organized as a half-day offsite session for the executive and other senior staff. Just under thirty people in all, of whom barely a third arrive on time – the remainder drift in over the next half-hour or so, without apology. Many of them ignore the no-phones rule for the session – including the CEO, who seems to be up and down like a jack-rabbit following one phone-call after another. The CIO even keeps her laptop open throughout the session, pounding away on an endless stream of supposedly urgent emails.

We use the five-element model as a central focus for discussion (see Figure 3-5). It soon becomes clear that, like many business organizations, they’re strong on Preparation and Process – planning and production – but not so strong on Performance – completions, follow-up, and strategic use of metrics – and frankly weak on the Purpose and People domains. The nearest equivalent to strategy, for example, seems to consist of receiving a list of quarterly financial targets from global headquarters and then hacking out a quick plan that might deliver the required results – which could hardly be called a strategy at all. And the “people” aspects of overall planning were no better: the CIO, for example, was visibly overloaded from the strain of trying to complete the integration of the former banks’ IT-systems, but she was doing so without any real support from the rest of the business.

A pentagon shape flow diagram of 5 elements for the bank. People and purpose are barely acknowledged, preparation and process have a strong emphasis, and performance doesn't have a strong emphasis.

The theme of “respect” provides some interesting views into the overall context. While it’s clear that professional respect between them is more than adequate, that’s not reflected in their mutual actions: people talking over each other, others talking among themselves, while someone is supposedly presenting to the whole group, and, of course, the ubiquitous iPhones and excuse-me-I-just-have-to-take-this-call. There are a few displays of oversized egos, of course, but overall there’s not as much political infighting as we’ve seen in other organizations, which ought to be a good sign – yet it seems extraordinarily difficult to get them to work together as a team. In that sense, respect is a serious problem here, right down to the way the senior management work with each other – or don’t work with each other, more accurately.

What’s not clear is what to do about all of this. But we shouldn’t concern ourselves about that at this point anyway, because, as noted in the project-diary:

must exclude any consideration of “solutions” during the assessment phase – document any ideas and sketches, but don’t discuss!

Instead, we simply take note of whatever information comes up, and hold back on any assessment until later.

Follow-On Assessment

We start with context-space mapping.

A quick summary, as shown in Figure 3-6, would suggest that – as is again common with many organizations – there’s been an assumption somewhere that everything fits within the “ordered” domains, with little allowance for the reality of “unorder.” Hence the too-Simple attempt to “take control,” trying to force the market to change its behaviors to suit the organization’s necessarily changed policies – and hence also an inevitable fallback to a market-context that has become “chaotic” in the wrong sense of the word. Much the same applies to the results of endlessly repeated cost-cutting within the organization itself: yes, it’s “lean and mean,” but there are now no reserves left to deal with the stress of change, and the strains are beginning to show, all the way up to the executive – not least in the CIO’s increasing difficulties in keeping up with her insane workload.

An illustration of collapse from control to chaos. Simple and complicated are marked as certain. Complex and chaotic are marked as uncertain. A one-line description is given for each domain.

Bank rules are usually structured for compliance and audit purposes. In principle they’re not particularly complicated, of course – but they’re often so vast, due to the nature of the controls, that they end up being experienced as complicated anyway.

Next, the systems-theory principles.

It’s clear that both recursion and reflexion are in play here, because the overall respect-problems and stress-symptoms are all too evident throughout the organization and enterprise (recursion), and can be seen in almost any point within it and from outside it (reflexion).

There’s evidence of failure to apply rotation, a consistent overview from every perspective – instead, each person seems to view the enterprise solely from their own standpoint, without much sense of the whole, or expressed feeling of belonging to a whole.

And there’s also not much evidence of reciprocation, in that the organization seems to have a very one-sided, even self-centric view of its relationship with its market: in the CEO’s eyes at least, “shareholder-value” comes first, with clients’ needs a very distant second. The market-model suggests that this would lead to a very destructive resonance feedback-loop that would lead to spiralling damage to the bank’s reputation – exactly as reported and as we’ve also seen for ourselves in those two workshops.

On to the five-elements lifecycle review.

This we can summarize direct from the executive workshop: the main emphasis is on Preparation and Process phases, with some on whole-system use of Performance, but nothing like enough of Purpose or People to provide much-needed balance. Seriously lopsided, in other words, if not unusually so for a commercial organization – but the longer-term impacts of that imbalance are now starting to show.

And finally, architectural entities in scope, in segments-model terms.

Almost all of this is about people, values, and feelings – or, in architectural terms, relational-assets (links with real people), “universals” (values), and the audit-trails of items and interactions (particularly feelings) that link them together. Architecturally, what’s missing here is an explicit description of values to which everything can be anchored – the vision, or, as one of our other clients put it, “the totem-pole to unite the tribes.” Just what that would be is far from clear at present: all that is clear is that “shareholder-value” isn’t it, if only because that’s of no interest to the bank’s clients from whom that supposed “shareholder-value” would ultimately be derived.

In the project-diary, we also carried forward two notes from the previous phase:

- for phase B/C: will need to identify policies, rules, and regulations that would apply to detail-assessment and implementation - for phase B (as-is): use POSIWID to assess implied-“purpose” of current systems

Policies, rules, and regulations may not apply until we start some kind of implementation – which may not happen in this case, and may not be our responsibility anyway. But we note an interesting clash of cultures: this country’s culture places a strong emphasis on the family, the collective, whereas that of the parent-company builds everything around the individual – and most of the bank’s metrics and bonus-structures reflect the values of the parent, not this place. That in itself might be a source of problems that need further exploration.

POSIWID is an acronym coined by the cyberneticist Stafford Beer, to describe the relationship between purpose and practice: “the purpose of a system is [expressed in] what it does.” In effect, the bank is a “system” whose current effective purpose is to create the problems that we’d seen in that assessment. No one designed it to create those problems, of course – though “design” is actually a key source of the problems here, because these issues cannot be resolved by tackling them piecemeal, but only by tackling them as a whole, as a single unified system. That doesn’t mean that we should try to do everything at once – that’s impossibly disruptive, and it never works anyway. What it does mean is that we need to think architecturally, in terms of the architecture of the enterprise, not just the organization. And one key item that’s most notable by its absence, perhaps, is the lack of any meaningful enterprise-scope vision – so that might well be a good place to start work.

But that’s a “solution” – and all would-be solutions should be shelved until we get to the appropriate point, which is not here. For now, though, we’ve finished this part of the assessment: time to move on.

Step 4: Review “As-Is” Architecture Against Qualitative Criteria

To the CEO, it seems, almost the only thing that matters is the quarterly figures. But that won’t work well enough in this context – not least because money won’t buy respect. The whole focus of this exercise is qualitative, not quantitative – but it’s still far from clear yet as to which qualities we’ll need to focus on. Something we’d need to note in the project-diary, but otherwise just keep going.

Step 5: Finalize Building-Blocks for Architectural Scope

If we were to do this “by the book,” we should look for re-usable building-blocks at this point. But once again that building-blocks concept doesn’t quite make sense here, because almost all of this is about people rather than “things.” Again, probably something best left to review in the next phase.

Step 6: Conduct Checkpoint-Review for Stakeholders

We finished all of the preceding review within about half an hour after the second workshop ended. Our client – the bank’s change-manager – was still helping the main presenter to pack up at that point, so we’re able to discuss the assessment so far. He’s very pleased with what sees, so we get his go-ahead for the next phase – the “to-be” assessment.