Overall Aim, Scope, and Purpose

Action: Identify the stakeholders and scope. Every item of architecture work will apply to and affect one or more groups of stakeholders, so we need to identify who those are, as early as possible in the project. We describe these people as “stakeholders” rather than “clients,” because although the work is usually for a specific group of people – such as you, in this case – there are often many others who will be affected by it, and whose feelings and opinions will definitely impact the overall effectiveness of the end-result. It’s essential to set the right scope, so it’s important to note that for architecture work, the scope of influence – the stakeholders whose views we need to take into account – is usually several steps broader than the scope of action – the part of the business for which we have the authority and budget to enact change.

Action: Identify the methods and overall approach to be used. The aim here is to use architecture to describe how architecture works, so we’ll need to base the work on existing disciplines, frameworks, and methods. One key to this is the way in which the same overall practices recur not just as sequential cycles, but within other cycles – a pattern known as recursion. We also want to explore and explain the process of sensemaking and decision-making that is the real core of architecture-practice.

Agile-architecture cycle: 1. Setup – context, scope, values, business-purpose, and success-criteria 2. Architecture-side: what do we have, what do we want, what’s the difference from here to there 3. Implementation-side: what needs to change, what's the plan, do it 4. Wrap-up: what value was gained, what have we learnt, what's next Include glossary/thesaurus, models, opportunity/risk, issues, etc. Perhaps use an adapted version of TOGAF ADM to illustrate this?

A cyclic chart of responsibilities for architecture from A to H with four different external arrows named set-up, architecture, implementation, and wrap-up.

As shown in Figure 1-2, there will be just one main cycle for this project, with separate smaller cycles either side to provide lead-in (Start) and follow-up (End). Each of these cycles may well include other cycles within it, to support the needs for recursion.

In effect, this first day (labelled Start in Figure 1-2) is one very rapid skim through that cycle, looking at purpose, then the needs that arise from that purpose, and what we need to do to action those requirements, followed by a quick wrap-up and review. After that we’ll do a full cycle, allocating one day to each set of activities (phases A to H). We’ll then complete the project with a final overall review, which again will be another rapid one-day cycle (End).

Initial Aim, Scope, and Stakeholders

For this initial one-day cycle, the stakeholders are ourselves, the scope is the same “how would we describe architecture?” and the aim is to develop a plan of action for the remaining work that will deliver useful results in the small amount of time that we have.

Initial Assessment

Right at the start of an assessment-phase, by definition, we don’t know what we’re doing, and we don’t know what to do. We know where we want to go, but not much more than that. This can often bring on a strong feeling of inadequacy, incompetence, even of failure, so it’s important to realize that this bewilderment is normal and to be expected at this stage of the process.

For almost everyone, this kind of inherent uncertainty can be very uncomfortable. And although it takes a lot of practice to become “comfortable with being uncomfortable,” that’s a very useful skill for architects to develop, because our clients will be going through exactly the same experience, and we’ll need to help them through it too. What helps most here is to acknowledge what we feel, yet remember to follow the process: keep the focus on the overall aim or “vision,” and then do something – almost anything, in fact – to give appropriate ideas somewhere to begin to coalesce.

As shown in Figure 1-3, the free-form nature of mind-mapping can be useful here – if only to express how we feel about the uncertainty at this point…

A mind map has some different questions and uncertainties about real business problems. How to use, cross-maps, models, vision, and ent-arch maps, and how do I make this practical are some of them.

Importantly, all we are doing at this stage is assessment and information-gathering: we document the ideas and images that come up, but we don’t take action to follow up on any of them as yet. This does, however, point to a key operating principle that we will use throughout the entire process:

Action: If anything comes up during a project-phase that more properly fits the function of a later phase, the only action should be to document and tag it for retrieval during that later phase. For example, that list in the preceding graphic includes “how would I use this?” and “use simple checklists” – both of which are more about action than assessment, so we do nothing more about them for now, other than ensure that we will remember them when we get to the “implementation” stage of this small cycle. But the question “what is an enterprise?” is useful for assessment, so we do need to explore that point briefly before moving on.

Perhaps unsurprisingly, the question “what is an enterprise?” is fundamental to enterprise-architecture. This is important because many discussions about enterprise-architecture will assume that it’s solely about IT. The point here is that even if we’re only concerned with IT, we still need to set its respective “enterprise” in a broader scope – much broader, in fact.

This essential difference between rule-based versus values-based means that whilst we can sort-of control what happens within an organization, we can’t do the same with an enterprise. The best we can do is negotiate agreements – which is a very different process than issuing organizational edicts…

An organization is also an enterprise in its own right, of course (though an enterprise is not necessarily an organization) – hence the common habit of describing a business-organization as “the enterprise.” But for the context we’d typically need for an architecture, a useful guideline, as shown in Figure 1-4, is that the enterprise in scope is at least three steps larger than the organization in scope.

A three-layered chart of organization and enterprise. Information is provided for transactions with providers, partners, clients, Interactions, and stakeholders in layers 1, 2, and 3 respectively.

For a government department or not-for-profit organization, we might use alternate labels for “clients,” “prospects,” or “competitors,” but the overall structure would be much the same.

It’s extremely useful to keep that layered pattern in mind at all times when doing any kind of enterprise-architecture.

Remember that there’s no particular plan at this stage: it’s just about creating a space in which ideas can arise, and then collating the results in re-usable form. It may be that in the end, we don’t use some of these ideas at all: but at this stage, we not only don’t know but can’t know which ideas will or won’t be of use. Yet placing these notes in the project-diary means that they’ll be available to us if and when we need them: that’s all we’re doing here.

One idea from that list that’s useful right now is the architectural notion of the “parti.” As Frederick puts it, “a parti is the central idea or concept of a building … parti derives from understandings that are nonarchitectural and must be cultivated before architectural form can be born.” It’s unlikely to arrive just yet, but we need to keep our awareness open for any pointers to our own enterprise-architecture equivalents of the parti – a single unifying theme that will link all aspects of this architecture together.

It’s not much work to do this, of course, but that’s probably all the assessment that we need to do at this very early stage.

Initial Implementation

“Implementation” in this context will likewise be very simple: most of it is just an exploration and confirmation of the key tools that we would use in the main body of the work. For the main project here, these were listed in the earlier notes:

• Context-space mapping

• Five key principles from systems-theory

• Five-elements model of concurrent-lifecycle business processes

• Four-dimensions segments-model

A two-sided row has a plan and action with two columns named certain and uncertain including complicated, ambiguous, simple, and not known with unsorted at the center.

Context-space mapping (CSM) is a method for using descriptive frameworks in architecture. The example we will use here adapts a framework called SCAN, that describes a context in terms of four distinct “domains” of interpretation and action (Figure 1-5).

The circular block in the middle is a kind of placeholder that, among other things, would be used for items that we haven’t yet been able to sort into any of those four preceding categories.

Reflexion is perhaps the strangest aspect of systems-theory, yet one of the most valuable in enterprise-architecture. Through it we see that everything is connected to everything else, but is also part of everything else. A useful analogy here is a hologram: unlike an ordinary photograph, even the tiniest fragment of a true hologram will always contain a complete picture of the whole.

As shown in Figure 1-6, the five-elements model applies those principles of recursion and reflexion to any type of lifecycle in the enterprise:

A pentagonal model illustration of 5 elements of the life cycle. The elements are people, preparation, process, performance, and purpose.

And the multi-dimensional segments-model provides a means to categorize anything we come across in our modeling of the enterprise. For compatibility, it draws in part from the classic row/column Zachman taxonomy that’s well-known to most enterprise-architects, but has a number of significant differences. For example, this reframe adds a new dimension (“universals”) as a separate row at the top, and also inserts an extra dimension of “asset-type” segments which categorize types of entities (Figure 1-7).

Note, though that, just as the action-cycle described earlier intentionally looks like much the TOGAF ADM, but is actually different, here the segments-model intentionally looks a bit like Zachman, but is likewise actually different. In both cases, the similarities are there to support some degree of backwards compatibility; but the differences are absolutely crucial, because they are what make it possible for our architectures to break out of the classic IT-centric box.

A 3-dimensional triangle block of a segment model. The base has physical, virtual, and abstract. Length is marked as layer segments. Vision, values, and standards are placed on the top and marked as universal.

Somewhat as in the columns of the original Zachman framework, the “Component segments” represent the abstract elements (“primitives”) that we use to assemble a design.

(There are also a few additional uncategorized segments such as for financial assets and functions, energy as an asset, and time as an event-trigger.)

Most real-world entities we deal with in enterprise-architecture are composites that straddle across multiples of those segments. For example, a book is an asset that is both physical and virtual – object and information; a service is a merging of function and capability in which assets may be changed in accordance with decisions and events; and a business-model straddles every row, column, and segment of the entire frame.

Once we’ve identified the tools and techniques that we will use for the main cycle, we then need somewhere to store all of the information that’s required:

Action: Define and implement information-stores or “repositories” for architectural information, including glossary/thesaurus, stores for models and project-management information, and registers for risks, opportunities, and other issues – see Appendix A.

So we’ll use this as a parallel worked-example throughout the main project-cycle.

Wrap-Up on Initial Cycle

Every architecture-cycle should end with a brief review. At first, we may seem not to have done much in this day’s work, and it’s quite likely there’ll still be a lot of uncertainty about what we’re aiming to do and what we’ll achieve by the end of the overall project. But, in fact, we’ve now done most of the essential groundwork that will underpin all of the subsequent tasks – and as with all foundations, there’s not much that will show on the surface! The value of that groundwork will become more evident as we move through the main architecture-cycle over the next few days.

Application

Summary

We ended the chapter with an “Applications” section, providing a set of questions to help you to bring what you’ve learned here into your own work-context.

In the next chapter, we’ll start the main architecture-cycle, with an emphasis identifying purpose, scope, and content for the architecture-project.