In this day’s work, we do exactly the same kind of assessment as in the previous phase, exploring how “things work together,” but this time, with the “comparison” time-horizon rather than the “primary” one. (We might need to do this more than once, if we need to assess architecture-requirements at various intermediate points.) So the fact that much of what happens here looks much the same as the previous phase is deliberate, and not a mistake. The whole point is that we need to ensure consistency throughout, hence the only thing that should change in scope is the time-horizon, from “as-is” to “to-be,” or “to-be” to “as-is.”
If we find that anything other than the time-horizon does change here – for example, exploring the comparison forces us to consider a wider scope in framework terms – it might be wise to review the results of the previous phase, and perhaps revisit that assessment to address the revised scope. It’s essential that we can create a like-with-like comparison between these two phases, so that the gap-analysis in the next phase can make meaningful sense.
The steps shown are guidelines, not rules – expect to iterate back-and-forth, or even change the sequence.
Watch for possible “solutions,” but take care not to get attached.
Expect to be viewed as “in the wrong!”
We do also need to be careful not to let ideas from the assessment we’ve just completed for the “primary” time-horizon to blur over into this part of the work: our gap-analysis takes place in the next phase, not this one.
Main Project: Architecture “As-Is” Assessment
architecture as-is, or “where are we now?” – probably no real baseline most existing frameworks (TOGAF, FEAF, etc.) are IT-centric, perhaps moving slowly to business-centric: not enterprise, no standards, not much advice on what the discipline is - “kind of get info together” – visuals, conversations, discipline? |
The scope, obviously, is the same as before: anything to do with “the architecture of architecture” – particularly about the skills and capabilities that underpin the architecture disciplines.
As before, we’ll start off by following the standard process “by the book,” but expect to veer off somewhat as appropriate.
Step 1: Develop Baseline Architecture for “As-Is” Context
As with the “to-be” assessment, there probably won’t be much of a baseline that we can create here. Existing enterprise-architecture frameworks such as TOGAF and FEAF are often very strong on models for architecture-content – particularly for IT – but are not so strong on practices or capabilities, which is the theme in scope for this assessment.
The TOGAF specification does include some useful sections on architecture skills and capabilities – particularly the chapters on Architecture Skills Framework and The Architecture Board. (The chapter-numbers may change between versions, but the chapters themselves are likely to be in each new version.) Note, though, that almost all of that material is still strongly skewed toward IT-architecture rather than enterprise-scope architecture: some “translation” may well be required for here.
A body of knowledge about structure, story, purpose, and value throughout the organization and enterprise
Used in decision-making throughout the organization and, potentially, the broader enterprise
Used to guide designs that contribute toward the aims of the organization and enterprise
We’ll take that as a working-definition of enterprise-architecture for this assessment.
Step 2: Select Reference-Models, Views, Viewpoints, and Notation-Standards
Context-space mapping
Systems-theory principles
Five-elements lifecycle
Four-dimensions segments-model framework
Again, the main viewpoint that matters here is our own, but we’ll need to be able to look at our “architecture of architecture” from many different directions.
Step 3: Create and Update “As-Is” Architecture Models
Much of the detail of this assessment will depend on your current architectural context and skills-base, but a quick scan with those same base-models – context-space mapping, systems-theory, five-elements, segments-model – will almost certainly show that there’s nothing that’s fundamentally different between “then” and “now.” The difference will usually be in the detail: not the type of skill or capability, for example, but the scope that each would cover.
One point that comes up here is that we have almost everything we could want for our architecture – models, methods, frameworks, theory, tools, the lot – except for the one thing we need the most: what to do with it all. As we saw Beveridge describe earlier, the same problem occurs in other disciplines too: “It is true that much time and effort is devoted to training and equipping the scientist's mind, but little attention is paid to the technicalities of making the best use of it. There is [as yet] no book which systematises the knowledge available on the practice and mental skills – the art – of scientific investigation.” Almost exactly the same could be said for architectural investigation: we have the “science,” but not the “art” that makes it work.
It’s like we kind of get information together till it sort of makes sense, then draw a picture, and then argue about it a bit, and then draw another picture, and take that to show it someone else, who tells us we’ve got it all wrong and it should be this way round instead, so we draw another picture, for another conversation, for another picture, for another conversation… We’re bringing together all these disparate views about the same thing – and people often don’t realize that they’re actually looking at the same thing. |
The other key point is a problem about scope. Almost everything in current enterprise-architecture still revolves around IT: indeed, many practitioners would still believe that it is only about detail-level architectures for IT, and governance of IT-implementations. It’s IT-centric in the sense that every conversation seems to end up being about IT, or IT-related aspects of a much broader problem such as security-architecture or knowledge-architecture or service-architecture. Although it is getting somewhat better these days, for a long time so-called “business-architecture” was little more than a kind of randomized grab-bag of “anything not-IT that might affect on IT.” And much of that “business-architecture” was, and sometimes still is, so jumbled-up that almost no distinction would be made between business-strategy and run-time business-processes, even though they occupy very different slots even in the original Zachman framework, and represent what are fundamentally different viewpoints in the business-architecture. Even now, there’s still often not much awareness of business as business, and even less of enterprise as enterprise. In that sense, it’s questionable whether much of what purports to be “enterprise-architecture” is actually enterprise-architecture at all.
This mis-naming is also reflected in what’s happening – or not happening – at present in the recruitment market. Even now it’s still rare to come across a job-advert for an “enterprise-architect” that describes anything resembling a true enterprise-scope architecture role: almost all are actually describing IT-architecture roles, many of them very low-level indeed. Often the give-away clue is the job-title itself, such as “SAP Enterprise Architect”, or “Java Enterprise Architect”: a simple rule of thumb is that if there’s a technology mentioned in the title, it ain’t enterprise-architecture.
One way to resolve some of the arguments about what enterprise architecture is would be to ask what it isn’t. We could do this by deconstructing that earlier description of the role of enterprise-architecture: that it’s “a business-capability that manages a body of knowledge about enterprise structure, story, purpose and value.”
If it doesn’t manage an explicit body of knowledge used in organization-wide decision-support, it’s probably not enterprise architecture.
If it doesn’t provide executive-level advice, it’s probably not enterprise architecture.
If it doesn’t have the ability or authority to tackle a whole-of-enterprise scope, it’s probably not enterprise architecture.
If it doesn’t deal with the intersection of structure, story, purpose, and value, it’s probably not enterprise architecture.
All of these “not-enterprise” architectures are extremely important in their own right, of course. All of them are technically subsets or sub-domains of enterprise-architecture, and many of them will also have an enterprise-wide scope at times – which is where the “enterprise” misnomer came from in the first place. But the real danger is that if we call them “enterprise-architecture,” it will often block awareness of the need for an architecture at a true enterprise-level – and that absence can cause real damage to an organization.
Step 4: Review “As-Is” Architecture Against Qualitative Criteria
This is essentially the same as in the previous phase: the same emphasis on performance-management and qualitative factors of the core-universals, and the CSFs and KPIs identified earlier. We need to do a quick check to see if there’s anything else to add, but it’s more likely that if there’s any difference, it’ll be because this “as-is” is a subset rather than a superset of the previous list.
Step 5: Finalize Building-Blocks for Architectural Scope
As in the previous phase, it’s unlikely that the “building-blocks” concept will be of much use here: document it as “not applicable,” and move on.
Step 6: Conduct Checkpoint-Review for Stakeholders
- requirements, etc., essentially same as for phase B other points noted: - need emphasis on what and how to do architectural assessment - potential dangers of IT-centrism, etc. - need to ensure that domain-architectures (business, security, applications, capabilities, data, IT-infrastructure, etc.) are not mistaken for whole-of-enterprise architecture |
As before, we might perhaps need to loop back to the preceding Step 3 to re-assess architecture-models and the like, and the requirements we’ve derived from them, until we’re comfortable that this is a true picture of the as-is context. Once we’ve done that, we then need to move on to identify the gaps between “here” and “there.”
Example Project: Bank Past/Future Assessment
respect existed in past, need to recreate it in future |
What the bank wants as its future “to-be” is actually the same level of respect that it used to have in the past – or, perhaps more to the point, the results that were associated with that level of respect. So while we might describe this as a “to-be,” what we actually need to assess here is more the real architecture of the past – as “as-was” – rather than solely an imagined architecture of the future. That makes this exercise somewhat different from the usual – but it’s also that difference that makes it easier to see what’s really going on during the creation of the architecture itself.
challenge: “what does respect look like?” – use narrative, anecdote, etc. |
After discussing this with our change-manager client, he gives us the go-ahead to hold another short exploratory session with some of the previous workshop participants. As usual, though, we start the assessment-process with the “by the book” sequence for this phase.
Step 1: Baseline Architecture for “Past/Future” Context
As before, there’s really no information available to us from which to build a baseline: hence it’s simplest just to skip over this for now.
Step 2: Select Reference-Models, Views, Viewpoints, and Notation-Standards
Here, we’ll again use the same viewpoints and base-models as before: context-space mapping, systems-theory, five-elements, and segments-model, as described and illustrated back in Day 1. If some other frame comes up that makes sense in this context, we’ll use it, though we need to take care that it will still support the like-for-like gap-analysis in the next phase.
Step 3: Create and Update “Past/Future” Architecture Models
The core information we’ll need to collect is about what pertained in the past, and what’s different between then and now.
Exploratory Session
What did respect look like, or feel like, in the past?
In what ways do you notice its absence now?
Why was respect important to the bank?
What else can you see that’s changed between then and now?
What suggestions would you have about how this can be improved?
- Relationships with clients:
We used to help people get what they wanted in life, now it feels like we’re just trying to stop them getting what they want.
People think I’m only here to rip them off, you’ve no idea the hate I get down that phone-line.
The trust is gone – people don’t trust us anymore, and we don’t trust them.
It’s not about service any more, it’s about making money.
- Relationships within the bank:
We’ve got too big too fast – I don’t know anyone any more.
There’s just the two of us in our booth in the supermarket, I’ve no idea what’s happening anywhere else in the bank.
Is there an “us”? I know we’re supposed to be part of this big bank and all, but I don’t feel it.
There still isn’t a merger – we’re still two separate banks, going our own separate ways.
I’m proud to be part of our team. I just wish I were proud of working for the bank – but the other banks here are worse, so what’s the point?
- Relationships with the broader community:
I used to be proud to say I’m a bank-teller, now I have to hide what I do, pretend I’ve changed jobs.
Who would trust a bank these days? Do you? I don’t – and I work here!
People think I’m one of the enemy for working here.
We used to be the very first people the government would come to, to ask for advice, now we almost have to go in on bended knee before they’ll listen to us at all.
We spend a lot of money on social projects, and we always have, but no-one seems to hear about it – they don’t know the good we do for business, for the community, for everyone.
- Changes in policy, and their effects:
Reckon we’ve lost the plot somewhere – don’t know where or how, but you can feel it everywhere.
Something happened back at the parent company about five years ago – suddenly the only thing that mattered was shareholder-value. Must have been their bonuses or something, because all they wanted to hear from us was how much profit we’d made this quarter – they didn’t care about anything else at all.
They used to help us back at head-office, but they’re just not interested in any of our problems any more – all they want to know about is the money we make for them. We used to feel like we were partners, now we’re just servants, and they treat us like that, too.
Up until a few years ago we did a lot of credit-checks before we let anyone have a card. Then it seemed like we had to give them to just about anyone, fast as we could, no questions asked, as long as they ran up a nice big credit-bill at high interest. People who were careful with their money were no use to us at all. But since the crunch hit, it’s been panic-stations, running around like crazy to get the debt-level down, chasing customers every day to pay up right now on every scrap of back-interest, and of course they haven’t got the money, no-one has. No wonder they hate us, really.
Some of these anecdotes could perhaps be dismissed as nostalgia for a “golden age” that may never have existed. Even so, it’s clear that there’s a definite sense of contrast between past and present, and also too much of a feeling of stress and isolation to be able to think clearly about the future. Architecturally, this is the information that we need most at this point.
Follow-On Assessment
One point that’s important to note here: much of this part of the assessment is likely to be challenging for our executive-level clients, because it’s the first time we explicitly demonstrate that there are real problems here that they need to address. It’s essential, then, to keep our own opinions out of this as much as practicable: we’re here as decision-support, not decision-makers, and the only people who have the responsibility and authority to make the kind of major decisions that will come out of this are the bank’s executive.
We do have the responsibility to show what the problems are, and what their consequences would be for the bank, in a quiet, calm, dispassionate POSIWID sense. Whether we have the authority to do so is another question entirely, as we’ll no doubt discover…
On to the assessment, then, first with context-space mapping.
A rectangular space mapping of reality includes four major factors that illustrate simple, complicated, ambiguous, and not known. The clockwise rotation has been automated and individualized.
Bank example: focus on human to keep things simple
We could go into a lot more depth than this, but that’s probably all the time we have for it right now.
Next, the systems-theory principles.
The most obvious difference is in reciprocation: in the past, the relationships with all stakeholders were perceived as much more about mutual support. (Whether it actually was a relationship of mutual support is actually a moot point: what matters is that it was perceived as such. Where feelings are concerned, perception is reality – and it’s feelings, and not necessarily facts, that are the glue that hold the enterprise together.) To use an ecological metaphor, the previous relationship was viewed by the bank’s customers as symbiotic, whereas it’s now perceived more as parasitic or predatory.
The key impact of this is on the resonance component for systems-theory. In practice, any business-relationship must include a reinforcing feedback-loop somewhere in its system, because that’s what creates growth. The technical term is “positive feedback,” which is a bit unfortunate, because “positive feedback” can actually be very destructive: what it grows is whatever’s in the loop. In the past this loop reinforced that feeling of symbiosis; at the present time, the same loop is reinforcing that mutual negativity described in many of the anecdotes. We can’t kill that loop, because it’s an inherent part of the business-system: and even if we were able to kill it, doing so would kill the business, because there would no longer be anything to grow the business-relationships. What we can do is take more care about what’s reinforced within the loop itself. But as to what that is, and what we should do about it, is something we leave for later phases in the architecture-cycle: for now, we just note that it is so, and move on.
The next item is the five-elements lifecycle.
From the descriptions, this seems to have been more balanced in the past: certainly a stronger emphasis on the People domain, with the client-base previously referred to as “customers” rather than “consumers.” It’s possible that the Purpose-domain of that time was driven more by the traditions of banking rather than explicit choices of policy – but that’s only an opinion, and opinions have no real place in this part of the architecture-cycle.
Finally, review in terms of the segments-model.
At a conceptual level, the structure of the bank was essentially the same in both past and present. Key technology-driven changes in capability, such as the advent of ATMs, were already completed by the time of our “past” time-horizon; various upcoming changes such as Internet-banking and micro-payment via mobile phone still have a low market penetration here. The types of assets and events are much the same as in the “as-is” assessment; the range of functions and locations was partitioned somewhat differently in the pre-takeover state for the two separate banks, but the effective structural impact of those differences is quite minor. Most of the decisions column is much the same, too: the fundamental business-rules and regulations for banking in this region remain essentially unchanged.
The one place – structurally speaking – where there is a significant difference is in the “Universals” section, right up at the top of the framework. At this “past” time-horizon, there were two banks, not one, and each had their own distinct identity. And while profits and perceived “shareholder-value” were important, of course, they were not assigned the almost extreme priority that they have in the “as-is” time-horizon. Once again, though, we take care to avoid any opinion on this, but simply note the fact of the difference.
All of the information from the preceding assessments is noted and summarized in the project-diary.
Step 4: Review Architecture Against Qualitative Criteria
It’s clear here that that the core of this is qualitative; beyond that, just about the only other point that’s certain is that the current emphasis – placing quarterly-figures above everything else – was not there in the past, and is perhaps a key source of the present disjoint from the broader enterprise. The details of that, though, will have to wait until the upcoming gap-analysis.
Step 5: Finalize Building-Blocks for Architectural Scope
As before, the “building-blocks” concept doesn’t really work here – though it’s clear that the most important region of the extended-Zachman frame is the enterprise’s “universals,” and linkage to it from every activity and decision in the organization.
Step 6: Conduct Checkpoint-Review for Stakeholders
As before, the stakeholder-review here consists of a brief follow-up discussion with our change-manager client, summarizing the preceding results of the workshop. From this, we gain the go-ahead for a further meeting with him in two days’ time, after the gap-analysis.
Application
What do you do differently in your assessments for “as-is” and “to-be” contexts? How do you ensure that they stay separate, and are not accidentally blurred together? How do you ensure that you do not fall into doing gap-analysis in this phase, rather than keeping the focus solely on assessment?
What for you is different between the way you do enterprise-architecture now, and the way you’d prefer to do it in future?
How do you do your architectural assessment? What parts of it would you describe as the “art” or “craft” or “science” of architectural investigation? What processes do you go through? How would you describe these processes? How would you explain them to others?
Assuming your work has an enterprise-wide scope, does it emphasize any one specific sub-domain within the overall architecture, such as business, security, applications, process, information, or infrastructure? If it does, who – if anyone – manages the architecture for all the other sub-domains? Who – if anyone – is responsible for linking them all together?
If your work covers only a subset of the enterprise scope but is described as “enterprise-architecture,” why is this? What implications and actual effects does this have for architectural integration across the whole organization and enterprise?
How do you tackle assessment and presentation of highly charged “political” issues? What do you need to do to keep the stakeholders’ focus on the architecture rather than the politics? How do you keep the facts – and feelings as facts – separate from the personal opinions and interpretations that drive the politics?
Summary
In this chapter, we revisited the processes of gathering the information for an assessment, but this time for the comparison time-horizon: from future back to the present, or from present toward the future. We emphasized that the methods need to be the same as before, to make comparison between the two assessments more meaningful. We also took care to not go into gap-analysis or “solutioneering”: those tasks for later stages, not this one.
The example-project introduced us to the sometimes-fraught challenges of the “politics” of architecture, and why we need to take particular care around such issues. The “Application” section at the end of the chapter focused particularly on those themes.
The main deliverables for the day were, again, the respective assessments, for the comparison time-horizon for each of the two projects.
In the next chapter, we’ll compare the two assessments via a gap-analysis, to derive requirements for change.