Now that we have architectural assessments for both the current “as-is” context and one or more probable “to-be” contexts in scope, we now need to establish the gaps between them, so as to identify requirements for change, and then document those requirements in whatever form we need for subsequent analysis and design. This is where we find out what’s needed to make things work better by helping them work together, on purpose.
Note that this is only about requirements – not “solutions.” Solutions are the way we implement requirements: they are not the requirements themselves. No doubt many ideas for solutions will present themselves during this period, but we still have to be very careful throughout this phase not to mistake a potential solution for any actual requirements. So whenever an apparent solution suggests itself – which will often happen here – our task is to note it on the project-diary, or the requirements-repository, or whatever else we’re using to store that information, and then return straightaway to the quest for real requirements.
Another reason why this is so important is that the act of enquiry is itself sometimes the only “solution” that the context will require. All too often, I’ve seen IT people rush off to build or buy some complicated software system to “solve” some communication problem, when in fact the most practical, and cheapest, solution there would be the humble Post-It note – or just getting the relevant people around a table to talk for ten minutes. New technologies are like new toys – they’re always fun for the first ten minutes or so. But once we’ve gotten over the glamor of the latest gadget, there’s still the same work to do – and to make that work well, and be worthwhile, we need to keep the focus here on the requirements, and the effective gaps from which they arise.
Architecturally speaking, there are an enormous number of places where gaps can arise: people-gaps, process-gaps, tools-gaps, data-gaps, information-gaps, metrics-gaps, finance-gaps, facilities-gaps, security-gaps, dependency-gaps, value-gaps, and meaning-gaps, to name just a few examples. (Some of these gaps may not be in our scope: if not, we still need to record them somewhere from where they can be retrieved later as required – such as for the baseline-architecture of a new architecture-cycle.) The point is that each gap implies requirements for change, and thence some kind of action to create the required conditions for that change.
The aim of the gap-analysis here is to identify services, functions, data-elements, capabilities, applications, and the like which may need to be developed, changed, or even eliminated entirely. We also need to assess the probable impacts of qualitative or “non-functional” criteria such as performance, cost, confidentiality, security, reliability and service-levels, and their whole-of-organization impact.
This applies especially to the many cases where one part of the architecture may need to change to cater for changes in another part of the overall architecture – and hence another reason why it’s so important that the enterprise-architecture really can hold a true whole-of-enterprise view.
We need to do a gap-analysis between each pair of contexts – so if we have intermediate time-horizons between the main “as-is” and “to-be,” we’ll need to go through this process several times.
Most of this is straightforward: it’s only about finding gaps, so it doesn’t have anything like as much of the I’m-lost-I-don’t-know-what-I’m-doing feel of the assessment phases. The only catch here is that the first couple of steps of the “by the book” version of the process are based on a “building-blocks” concept: we’re supposed to construct and validate a matrix of the “as-is” and “to-be” architectures, and derive our change-requirements from that matrix. But while this works well for IT-systems and machines, it doesn’t really work for people-based processes, skills, and capabilities. Despite the classic dreams (or delusions) of “scientific management,” we can’t partition real people into “building-blocks” in the same mechanistic way. So if – as is the case with both of our examples here – most of the architectural themes we’re dealing with revolve around people, we have to tackle the gap-analysis in a different way. What I’ve used here is an architect’s equivalent of the old “blink-comparison”: place pairs of models on top of each other, and see what differences show up.
The main output from this will be a set of change-requirements, which we then use in the next phase to decide what actions to take and what – if any – “solutions” we need to develop, buy, build, or modify. We might need to create a model or two, and we’re likely to identify additional out-of-scope requirements and issues: all of those should end up in a shared-repository, or at the very least should go into the final report for this cycle.
At the end of all this, we’ll need to do another stakeholder review to confirm that we have the right requirements to go forward.
Main Project: Architecture Gaps
What we look for here are any gaps between what we already have in the architecture – the structure and purpose – of our existing enterprise-architecture, and what we’ll need to embed in an architecture-of-architecture that can cover the entire enterprise scope. We’ll need a special emphasis on tools and techniques that would help us in “the art of architectural investigation” – because those descriptions are what are most often missing from conventional frameworks and methods for enterprise-architecture.
Step 1: Compare “As-Is” to “To-Be” Architectures
Probably the simplest way to do this gap-analysis is to compare the “as-is” we identified in the previous phase against the following “to-be” checklists:
Scope
A diagram of an enterprise of subdomain has enterprise, markets, and partners go to providers and consumers connected to the organization.
Visual checklist for “enterprise” of a sub-domain
A whole-of-enterprise architecture would need to be able to cover the complete scope of the enterprise: in other words, the literal interpretation of that diagram in Figure 5-1, with “my organization” representing the whole organization, and so on. For a sub-domain such as IT architecture, “my organization” would be the IT unit or the segment of IT within the respective sub-domain; “my providers” and “my clients” would be IT’s own clients and providers; “my partners” would be the business-units and their business-needs that IT serves; and “my market” would be the overall business.
A table of architecture of business into people, knowledge, machine, manual process, information process and machine process. Purpose, people, knowledge, assets and architecture are its dimensions.
Visual checklist for internal context of a sub-domain
To do a gap-analysis here, we compare the “as-is” against each of those preceding visual checklists – and even for a sub-domain, we’ll need to confirm that we can build an audit-trail all the way back to the key drivers for the overall enterprise. We identify any gaps, and then document them in the project-diary.
The Art of Architectural Investigation
Preparation: Study; setting about the problem
Experimentation: Architectural experiments; planning and assessing experiments; misleading experiments
Chance: The role of chance in discoveries; recognizing chance opportunities; exploiting opportunities
Hypothesis: Use of hypothesis in architecture; precautions in the use of hypothesis
Imagination: Productive thinking; false trails; curiosity as an incentive to thinking; discussion as a stimulus to the mind; dangers of conditioned thinking
Intuition: Examples of intuition; psychology of intuition; technique of seeking and capturing intuitions; architectural taste
Reason: Limitations and hazards of reason; safeguards in use of reason in architectural investigation; the role of reason in architecture
Observation: Examples of observation technique; general principles of observation; architectural observation
Difficulties: Mental resistance to new ideas; opposition to innovation; errors of interpretation
Strategy: Planning and organizing architectural investigation; different types of investigation; specific methods of investigation; tactics
Architecture and architects: Attributes required in architects; incentives and rewards; the ethics of architecture; different types of architects; architecture as a way of life
We need to identify any of the preceding themes that are not already adequately covered in the existing methods and approaches for architecture. As in the preceding section, we should then document any identified gaps in the project-diary.
Tools and Skill-Sets
Suitable reference-models, standards, techniques for architecture
Checklists and other “rotations” for the assessment toolkit
Fluency in sensemaking to select checklists, views, and “rotations”
Fluency in identifying recursion, reflexion, and similar patterns
Fluency in strategic assessment
Fluency in “soft-skills” and people-skills
Fluency in analysis and modeling skills
Familiarity and practice with architecture methodology
Appropriate performance-metrics for architecture
We need to identify any of the preceding items that are not already adequately covered in the existing architecture tools and skillsets. We’ll document in the project-diary any gaps that are identified.
Architectural Entities for Architecture
Assets: Workspace, computer, whiteboard, etc.; information-sources and information–stores; access to people; executive support for architecture
Functions: Processes for architecture, including governance, quality, process-improvement, engagement, and delivery
Locations: Social-networks across and beyond the organization
Capabilities: Generalist-level skills for all competencies across enterprise scope; specialist-level skills in architecture itself, such as modeling of value-streams
Events: Contexts and interface-specs for architecture-events and triggers
Decisions: Categories for decision-types; facility for dependency- and validation “audit-trails” for decisions, etc.
RACI matrices associated with all architectural entities
Appropriate set of metrics (KPIs), etc., and success-factors
We can use that too as a checklist against which to compare the “as-is,” and document any gaps that arise from the comparison.
Must have
Should have
Could have
Can Wait until some later time
This prioritized list of gaps will then form the basis for everything else that follows.
Step 2: Derive Change-Requirements from Comparison
Given the gaps, what is it that needs to change, in order to achieve the required “to-be”?
Given the required changes, what are the requirements to create those changes?
While doing this derivation, we may also note various constraints and other dependencies that may be relevant for solution-design and the like – for example, some changes may only be possible when others have already taken place.
Once this step is complete, we document the resultant requirements and constraints in the project-diary.
Step 3: Review Requirements Against Existing Dispensations
This step won’t apply if we’re doing this assessment for the first time, but may well be relevant if we’re revisiting it at some future time. A “dispensation” is a record that some choice had to be made that went against the agreed rules of the architecture: a classic example in IT-architecture would be an essential software package that will only run on Unix, when the architectural guidelines assert that only Windows operating-systems should be used. In effect, each dispensation represents an item of architectural risk; so each time we revisit the same context, we should also check if any dispensations can be resolved. It’s a governance discipline, nothing more than that, but it is useful as a means to monitor and mitigate long-term risk. That’s what this check is for.
So here we should search the Dispensations register – if we have one – for any existing dispensations that cover or intersect with the context of this iteration – “the architecture of architecture.” If we find any relevant dispensations, we should then review them against the “to-be” architecture, to identify potential requirements that could resolve those dispensations. In this case, those requirements would end up in the project-diary, as usual, though in a larger-scale exercise, they would be recorded in the respective registers and in the formal Statement of Architecture Work.
Step 4: Review Requirements Against Qualitative Criteria
This is where we check everything against the various qualitative criteria that we set up in Step 4 of the assessment phases. Back there we used those qualitative criteria to help us refine what we would need in the “to-be”; but here we’re now dealing with change-requirements, which is a rather different game, hence some of the criteria may need to be different, too.
Assets (“What”): Inventory-management
Functions (“How”): Yield-management
Locations (“Where”): Capacity-management
Capabilities (“Who”): Performance-management
Events (“When”): Time-management
Decisions (“Why”): State-of-change management
Given the IT-orientation of the original Zachman model, that set may be a bit incomplete for every type of scope and scale in whole-enterprise architecture, but it’s still useful as an initial check. Of these, the one that comes immediately to mind is performance-management: we need our architecture responses to be fast, in the real hours or minutes or seconds of business-time – not merely dawdle along in the months or years of academic-time, as in the “Waterfall”-style architecture-cycles of some of the better-known enterprise-architecture frameworks.
We would also need to take note of those “universals” that apply to everything in the enterprise – criteria such as security, ethics, environment, health and safety, and so on. And we should also test each of our requirements against the performance-indicators and success-criteria defined for our own discipline, our business-unit and the organization as a whole.
Efficient: Makes the optimum use of available resources
Reliable: Can be relied upon to deliver the required results
Elegant: Applies and enhances the human factors in the context
Appropriate: Aligns with and supports the indicated purpose
Integrated: Helps to link everything into the greater whole
The whole point of this review is to find out if any of our change-requirements need to be amended to align with those qualitative criteria. Any updated requirements should be documented in the project-diary, as usual.
Step 5: Conduct Checkpoint-Review for Stakeholders
Working “by the book,” what we should do here is collate the results of all of the previous steps, then present these to the stakeholders for formal review under the governance procedures. But in this case, the main stakeholders are us, so this should again be straightforward.
highest priority: - enhance the process, speed and accuracy of sensemaking, especially in architecture-assessment: needs to cover the whole enterprise scope and to link in with the “art of architectural investigation” list |
We’ll then use that as a base for solution-requirements and choices in the next phase of the architecture-cycle.
Example Project: Change-Requirements for the Bank
These are the differences between the architectures.
These are the implications of those differences.
These are the change-requirements that would seem to arise from those implications.
These are the types of choices, arising from those change-requirements, that would need to be made in order to move from “here” to “there.”
These requirements need to be reviewed, approved, and prioritized by the client.
The final authority for all of those choices rests with the client – not the architect.
That’s also why we do the stakeholder-review at the end of each of the assessment phases: it means that the client has already agreed that the two (or more) architecture-summaries are correct, hence all we’re doing here is explaining the differences between them, and implications that arise from those differences. It is true that, by its nature, requirements-derivation is in part an interpretation, but we’re not adding anything new to what they’ve already approved, and we’re definitely not attempting to override their authority. For our own safety, we need to ensure that that point is clear to everyone before we move on.
Step 1: Compare “As-Is” to “Past/Future” Architectures
Change of fundamental policy by parent, from assisting clients with risk-management to maximizing short-term profit returned to parent
Loss of clarity about collective identity, in part resulting from the takeover of the other regional bank
Changes in relationships with clients, from risk-management, to near-abandonment of risk-management (especially in the general credit-card market), to increasingly strident attempts (often perceived as intrusive and bullying) to regain “control” rather than management of risk
Two cyclic diagrams of the past and the present have 5 elements as people, preparation, process, performance, and purpose. In the past the cycle is unidirectional. In the present the cycle is bi-directional.
Five-elements: balance in “past,” imbalance in “as-is”
A cyclic diagram of purpose, people, preparation, process, and performance. An arrow from performance points to preparation, leaving purpose and people out of the loop. Monetization happens in short term to maximize profit to preparation.
Five-elements: the “quick profits” cycle
This is actually the structure of classic “scientific management,” and it does sort-of work, for a while at least… More dangerously, it will also seem more profitable for a while, because it doesn’t have to carry the “overhead” of Purpose and People. Yet those two “unnecessary” phases in the cycle are what enable adaptability and resilience – and without them, that short-circuit version of the cycle is guaranteed to fail in the medium- to longer-term. To put it bluntly, any over-focus on short-term profit is now a proven death-sentence for a commercial organization: as Michael Porter put it, the obsession with shareholder-value is “the Bermuda Triangle of strategy, where corporations sink without trace.” So in architectural terms, the parent-company’s demand to focus on immediate profit represents a huge risk to the survival of the bank. Yet it’s also clear that this is likely to be an “undiscussable,” the elephant-in-the-room that no one dare mention. Perhaps all we can do here is to note the fact and its implications, and move on.
Step 2: Derive Change-Requirements from Comparison
Change of fundamental policy by parent
Loss of clarity about collective identity
Disruptive changes in relationships with clients
Given the gaps, what is it that needs to change, in order to achieve the required “to-be”?
Given the required changes, what are the requirements to create those changes?
What the gap-analysis shows is that what most needs to change here is a shift away from the suicidal policy of the parent-company. But clearly, that’s right up in the realm of the “undiscussables,” and is not even within the CEO’s remit here: there’s nothing we can do about that in itself. But even so, we should list it as a requirement, because some option may come up during the solution-design process in the next phase. The constraint that we should record with that requirement is that we know we can’t do anything about it directly – but that fact doesn’t prevent us from finding some way to tackle it indirectly.
The other two items are more accessible: a requirement for some kind of metaphoric “totem-pole to link the tribes,” and something to stabilize and improve the relationships with customers – both of which themes need to be described at first in architectural terms.
We document the results of this intermediate step in the project-diary, as usual.
Step 3: Review Requirements Against Existing Dispensations
This is very simple, because there aren’t any dispensations in this context – or rather, if there are, we don’t have access to them, so won’t be able to take any into account. We note that fact in the project-diary, and move on.
Step 4: Review Requirements Against Qualitative Criteria
The simplest criteria to test against here are the “effectiveness” set: efficient, reliable, elegant, appropriate, integrated. We note that the key-theme for this specific architecture-cycle is “respect,” hence we’ll need to add a requirement that the human-factors strand of effectiveness – “elegant” – will need to be assigned a high priority when we assess our options for action in the “Solutions” phase. We also note that there’s a real constraint of time: whatever we create as our “solution” in this cycle will have at most a mere couple of days in which to action something that will start to make a real difference.
These notes go into the project-diary too.
Step 5: Conduct Checkpoint-Review for Stakeholders
- minimize impact of short-term/profit-focussed policy of parent (constraint: direct change of policy is not possible) - provide some means to anchor collective identity and unity - provide some means to stabilize and enhance business relationships - prioritize “human-factors” dimension in proposed solutions |
Ordinarily, for such a politically sensitive context, we would set up a formal requirements-review, to move step-by-step through each part of the derivation, clarifying the reasoning at each stage. But in this case – partly from the client’s own time-constraints, partly because this is a very quick consultancy-project anyway – the client has said that he’ll skim through the list of requirements with us when we come to the “solutions” discussion on the following day. Nothing more to do until then.
Application
How at present do you do gap-analysis between two architectures? How does this differ when the architectures relate primarily to “things” or IT, to when the architectures are primarily about people-issues and people-related themes?
How do you link and test your gap-analysis to the organization’s strategic and tactical goals, and its other “universals” such as vision, values, standards and suchlike?
What processes do you go through to derive architectural and other implications from the respective architecture-gaps? How do you verify and validate those implications, and the processes used to derive them?
How do you derive change-requirements from the implications? What kind of discipline do you apply to keep your own opinions in check while you do this interpretation?
What processes, tools, and formal structures – if any – do you use to document, monitor, and manage the various requirements that arise in your architecture-work? With whom do you share those requirements, and how, and for what purpose?
How do you derive and document politically sensitive requirements? How do you present them to your clients? What do you need to do to protect yourself against the classic “shoot the messenger” syndrome?
Summary
In this chapter, we explored how to do a gap-analysis between paired sets of assessments, and to derive change requirements from a gap-analysis. We again emphasized the importance of avoiding any jump straight into solutioneering at this stage. As before, the example-project also brought up “political” challenges for the architecture: we explored more about how to manage these. The “Application” section at the end provided us with a review about the process of gap-analysis.
The main deliverables from this day’s work were the respective gap-analyses, and the sets of requirements derived from them.
In the next chapter, we’ll use the derived requirements to start to map out potential solutions for each of the two project-contexts.