Now that we have the formal go-ahead to go and do something, we next need to plan out the fine detail of what we’re going to do to make that “one idea” become real.
In a larger-scale program of work we would start by defining our objectives: sort through the solution-designs, develop our project-plans and delivery-schedules, cross-check all the intended-benefits and interdependencies, and finalize a migration-strategy and Implementation Plan (with proper capital-letters in the title). And all of this needs to be done under program-governance, or change-governance: in that kind of program of work, the role of the architecture-unit is definitely one of decision-support, not decision-making.
In terms of the five-elements model, by the way, this is mostly about the People and Preparation stages of the lifecycle: finding the right people with the right skills for the job, and developing plans for action. That action itself happens in the Process stage that follows, while the work that preceded this – the solutions-architecture phase – fulfils the Purpose stage for the lifecycle.
As you’ll probably have noticed by now, architecture-assessment itself had its own lifecycle, of which the whole of this part of the work represents an outcome of its Process; both cycles join together again later in the final Performance stage. So in effect, what we’ve described as “the architecture-cycle” is actually two five-element lifecycles that intersect with each other, one focussed on architecture and the abstract, the other on design and the concrete world. Probably the key point here, though, is that there is explicit discipline and governance throughout the entirety of the cycle.
In a smaller-scale architecture-cycle – such as that which we’re running here – it’s probable that architects would be more actively engaged in the design and delivery as well. But it is important to remember that although the roles of architect and of designer are closely related – are flipsides of each other, in effect – they are also distinct and separate, and subject to separate forms of governance, which is the point that needs to be noted here.
In this phase, it’s also especially important to address any risks or issues that were identified earlier in the architecture-cycle, and also to take care to note any new ones that arise during this part of the work. Typical architectural activities here will often include advice on any inter-project conflicts and opportunities for shared facilities and other synergies – though again that would usually apply mainly in larger-scale projects or programs.
Step 1: Prioritize projects within the overall program
Step 2: Estimate resource requirements and availability
Step 3: Perform cost/benefit assessment of migration projects
Step 4: Perform risk assessment
Step 5: Generate timelined implementation roadmap
Step 6: Document the migration-plan
Step 7: Conduct stakeholder review of migration-plan
But again, that kind of structure might only be relevant in a large-scale transformation program: for anything smaller, we would usually aim to simplify it right down to the bare minimum that would still ensure appropriate governance, so as to minimize the performance-overhead of project-management.
We would usually expect to hold some kind of stakeholder-review at the end of this phase. But we might even dispense with that at times – especially for Agile-style development models, in which the equivalents of such reviews in effect are an inherent part of the overall process. We use whatever works, really – concentrate on effectiveness, but otherwise keep it as simple as we can.
Main Project: A Plan to Extend the Discipline
Link concepts from SCAN and OODA into architecture-cycle.
Purpose: Enhance speed, sensemaking, and decision-making.
Immediately usable in real-world architecture practice.
how to do this?? where do we start?? which aspects of architecture?? difficult to describe!! – hard to explain in words or in diagrams need to get the balance right: “hard line” vs. “soft line”; verbal vs. visual; theory vs. practice; depth; recursion, reflexion, etc. |
That note about “hard line” versus “soft-line” comes from the 101 Things About Architecture book – “soft ideas, soft lines; hard ideas, hard lines” – which is actually about certainty versus uncertainty, rather than easy compared to difficult. Most IT-architecture deals with themes that are “hard” in the sense of certain, the hard-edged, rule-based distinction between true and not-true, in or out. Hence most diagrams in IT-architectures will be hard-edged, angular, abstract, boxes-and-lines. But the themes we deal with in “people-space” tend to be fuzzy, blurry, full of subtle uncertainties: so we perhaps need to express those qualities in the respective diagrams – such as via the immediacy of the kind of hand-drawn sketches that most architects would rough out on a whiteboard, rather than the perhaps over-polished Visio-style diagrams that would end up on a Powerpoint or in a book. These qualities are something that we’ll also need to express in words as much as in diagrams, too. Something to think about, anyway.
The cyclic diagram includes orient, decide, act and observe.
Observe, orient, decide, act
We haven’t yet decided how we’re going to present the respective material – a workshop, a training-session, a book, or whatever – but whatever we do, we’re going to need to explain that loop, explaining the theory behind it but also showing how it works in practice.
We’ve also said that it would be useful to link this together with something like the SCAN framework (see the section on SCAN in Appendix B), as a consistent base to view any architectural context. Again, we would need to get the right balance between theory and practice: we’ll need to show, for example, how to put it to use immediately on a live architecture project, and demonstrate that it really does help in sensemaking and decision-making.
Observe: What is “the context” here? And how do I observe myself observing?
- Orient: How do I make sense of what I’m seeing? And how do I make sense of how I’m sensemaking?
What parts of the context appear to be Simple, Complicated, Ambiguous or Not-known? Map out the “problem-space” in terms of those categories.
Given that categorization, what cross-maps would be useful for sensemaking?
Using the categorizations from the cross-maps, what available tools and techniques are “situated” in what regions of the maps’ “solution-space”? What can I learn from this?
- Decide: Given what I have learned from sensemaking, what should be my “action-plan”? And how do I decide how I decide?
Select from the available tools/techniques.
Decide on a plan as to how, why, when, where, by whom, with what, and in what order each of the selected tools or techniques should be used.
- Act: What am I doing? And what am I doing as I am doing? – what do I see as I am doing?
Enact the desired action.
Apply the same overall OODA-loop to the action taken – recursively, where appropriate – for review, for further sensemaking, decision, and action.
Repeat as appropriate.
It’s perhaps important to emphasize here that the preceding is neither standard OODA nor standard SCAN. Instead, this needs to be understood simply as an illustration of the kind of thinking-processes that we go through in enterprise-architecture and the like, and the kind of context-dependent “mashups” from different ideas and frameworks and techniques that will arise from that work.
Problem-space: The context in which whatever we’re interested in is happening
Solution-space: The space in which we decide what to do about what’s happening
We work out what’s going on – Observe in problem-space, Orient to link problem-space to solution-space
We then select an appropriate way to respond – Decide in solution-space, then Act to link that abstract solution-space back into the real-world.
But all of this description is still too abstract: how do we apply it to the actual need, to deliver something that will help to “enhance speed, sensemaking and decision-making” within architecture?
The notion of “cross-maps” might help here: diagrams that link conceptually to other diagrams, providing different views into the same problem-space, or solution-space, or both, support the idea of “walking around” within that space to help make sense or make decisions. Examples might include different levels of repeatability compared to action-tactics, or to different types of decision-logic, or to cause/effect relationships; to quality-frameworks such as the Vision, Policy, Procedure, Work-Instruction model underlying ISO-9000, or the Plan, Do Check, Act (PDCA) cycle; to skill-levels, or to automatability; to timescales contrasted with levels of abstraction; to asset-types, or the layering of information and knowledge. These could also provide contextual “maps” where various types of tactics or tools or other “solutions” might align with specific types of problems, via cross-maps of respective characteristics and attributes. Something of that kind might help for decision-making here.
A diagram of problem space with parts of context has complicated factors, simple rules, human factors and ambiguous, non-repeatable, and a market of one.
Describing the problem-space
A chart of media from standardized to personalized. It has textbooks, videos, and audio, all connected to complicated, ambiguous, not known and simple. The core of all being reality.
Media for skills-development
In-person would seem to be the nearest to an ideal choice, but it isn’t an option that we would have here. Video is best for training, because of its immediacy and visual impact, but is also usually the worst option for skills-development, for exactly the same reasons; something more discursive, more fluid in its relationship to personal-time, would be a better fit for the actual requirements. So text and visuals would probably work well for this, especially if in a freer style – “soft lines,” so to speak. Language that engages, speaking with rather than to or at, creating space for others to find their own architectural “voice,” beyond all those by-the-book checklists. And “soft lines” in the form of hand-drawn sketches or the like, as a way to emphasize the speed at which architectural sensemaking and decision-making actually needs to take place – rather than the kind of polished “proper” diagrams which only arise after all the thinking-work is already complete.
We’ll need examples to illustrate how this all works: recursively, perhaps the best example would be this process itself. In itself, that might be too abstract: we’ll need to parallel that with another example, closer to the kind of architecture that actually happens within organizations – though it would be good to use an example that’s not the usual mainstream of IT-architecture and the like, but shows how the same architectural principles apply in other business contexts. So perhaps something more about values than “things” – the values-architecture that underpins the organization’s value-propositions to its client-base and its market.
- introduce a new conceptual tool for architecture: “context-space mapping,” linking the OODA decision-cycle and SCAN-like sensemaking into the standard architecture-cycle - introduce it in the form of text and visuals, using a “soft lines” approach and style for both - illustrate systems-principles concepts such as recursion by using the tool itself, and its usage, as its own example |
And in effect, we can use the technique itself to sense and adapt what we’re doing, while we’re doing it, in the midst of explaining it – completely recursive, even able to change the architecture of the architecture itself in real-time. An interesting challenge…
So that’s the project-plan: now we need to go ahead to implement it – which is what happens in the next phase.
But in the meantime, there’s still further work to do on the real-life example: what do we do to start reclaiming respect for a bank?
Example Project: Envisioning Vision at the Bank
Half-day workshop for senior-management and executive-level staff
Develop the basis for a high-level enterprise-architecture, without using the word “architecture” (because most of these executives still think that architecture is only about IT)
Ensure that it can be linked in to any other architecture and transformation activities already happening with the organization
Two components authorized: visioning exercise, and high-level functional business-model
Essential: must avoid anything that might be seen as politically sensitive, especially in terms of relations with the parent-company
And we have just one day in which to develop a complete plan for all of this.
Visioning Exercise
Visioning for enterprise-architecture ought to be straightforward, except that almost everyone gets it wrong. It’s not a description of some preferred “future state” – which is how TOGAF presents it – or, worse, a piece of marketing puff – which is how the Business Motivation Model presents it. Instead, it should be a very simple single-phrase summary of what the enterprise is and what it values – and that therefore acts as a permanent “guiding star” for everything the organization does in relation to its enterprise-ecosystem.
For example, as described in ISO-9000 – one of the few standards that does “get” the real role and function of enterprise vision – the vision-statement acts as the ultimate anchor for the organization’s quality-system; it provides the core-reference for all enterprise-relationships, for all internal relationships, and so on. And while it is also the core-reference for all marketing, it’s not about some kind of “image” or short-term “market-positioning.” In fact, if the vision ever does change, the organization is no longer in the same shared-enterprise, and even ceases to be the same organization – it’s that fundamental to what the organization is and does.
More importantly, for this context, it forms an explicit statement about what the organization stands for, and the core reasons and relationships it will share with others. Hence it also defines the values against which the organization expects to be measured – which, in turn, form the source for mutual respect. So if the bank wants to tackle its problem of respect, it must have a vision that makes immediate and practical sense, to everyone involved.
The catch is that it usually takes people days to get started on this, and months to build – and we’ll only have a couple of hours at most. But we do already have a standard framework for this kind of visioning-workshop: if we strip it back to a bare-bones version, we’ll be able to do something useful in that time – we can be fairly sure of that. What matters now is how it links in with everything else.
Functional Business Model
What we describe as a “functional business model” is also known by a number of other names, such as “business overview model” or “business capability model.” Often described as “the organization on a page,” it presents a summary of all of the core functions or capabilities of the organization, usually in visual form. Although it will generally use some kind of hierarchical layout, with functions nested inside “parent” business-functions, it is not the same as the usual org-chart: it’s about function, not management.
A model of Tier 1 of a generic function to manage and support the business, has contact customers, accept orders, process orders, deliver orders, and fulfil orders.
Tier-1 of generic functional business model
Organizations start to differentiate from each other as we go down into the next tier of functions, though there they’ll often follow the typical patterns of that industry – hence standard industry-models such as eTOM for telecommunications or SCOR for supply-chain operations. Once we get down to tier-3, though, the structure is usually close to unique even within the industry – a complete overview of what the organization does, and how it structures that work.
So if the vision describes what the organization is, the function-model describes what the organization does – its role within the enterprise-vision. And, like the vision, the role does not change much, if at all, because if it does, it will no longer be the same organization: so the function-model will stay much the same for as long as the organization does that kind of work. This means that the function-model is an extremely important document – because when it’s placed side-by-side with the vision, we have a “totem-pole to unify the tribes.”
Most enterprise-architects would build a function-model via some form of literature-search across the organization, working together with a few key “insider” stakeholders who know the business well. But for this project, we have an almost unique opportunity: the direct engagement of most of the key players in the organization. So here we’ll be able to do this as a live workshop, with direct feedback to make sure that we’ve got it right. We’ll only have time to do a two-tier model, but that should be enough for this purpose here; and to make it more engaging, we’ll ask each participant to bring a photograph of themselves to place on the model.
That gives us enough to work with for now.
Linking It All Together
- start by working with them to develop a two-tier functional business model - use the “organization and enterprise” diagram to introduce the notion of “enterprise” as an entity to which the organization must relate - introduce the concept of vision as an active bridge between organization and enterprise, and explain how it relates to respect - work with them to develop a preliminary vision |
We’ll also add a strong emphasis on how to identify what a usable vision looks like and feels like, and how to use it in practice, so that they can continue to develop it once the workshop is over.
It’ll be a tight squeeze to fit it all into a half-day, but it’ll be doable. Ready for tomorrow, then.
Application
What methodology – or methodologies – do you follow when developing a project-plan for implementation? In what ways does the methodology vary in different domains and for different scales of projects?
How do you decide what you will do in implementing a project-brief? How do you translate down from the abstract brief into concrete detail? How do you select from among all the various options? How do you find appropriate options? And how do you decide how to decide?
How do you know when it’s time to stop looking for solutions, and start to implement something? When does the project-plan stop being an abstract “plan” and start to become practical guidance for real work in real-time? And what do you need to do at the planning-stage to ensure that the plan can be updated and adapted to changing circumstances during implementation, while still maintaining appropriate governance throughout?
How would you go about planning a workshop to help an organization find out what it really is and does – the highest level of its enterprise-architecture? What safeguards would you need to build in to ensure that the participants stay on track, and not wander off on well-worn paths such as “not invented here,” “not in my job-description,” “the way we’ve always done it,” or “the money is all that matters”?
How would you deliver that workshop? What style would you use: for example, role-play, lecture, games, or other options? Why would you choose those specific options? What outcomes would you expect from using those options?
Summary
In this chapter, we explored how to expand a preliminary solution into a detailed plan for action that can be applied in real-world practice. The solutions discussed are specific to the two projects described in this book; the “Application” section at the end of the chapter provides a broader range of test-questions to use for other types of project in your own context.
The main deliverables here are the detailed plans for action for each project, based on the respective “preliminary solution” approved at the end of the previous day.
In the next chapter, we’ll put those plans into action.