Things work better when they work together, with clarity, with elegance, on purpose.
Enterprise-architects are responsible to the organization to make that happen: the underlying aim of every item of architecture-work in the enterprise is to make things work better for everyone, in a more effective way.
What do enterprise-architects do?
And how exactly do they add value to the business?
One obvious driver for value to the business will be speed of response: the work is not going to be of much value if we allow ourselves to get stuck in “analysis-paralysis.” But the business will also need us to deliver something that is of practical use: we do need to get the balance right here. So, following an Agile-style development principle, we’ll pick an arbitrary but appropriate timescale – ten working-days, or two business-weeks – for a first-level architecture iteration. At the end of that time, we’ll review and decide what to do next.
Commitment - use architecture methods, etc., to describe how to do architecture-development in real-time - topic for the architecture-project is architecture itself - document in book-form - timescale: 10 working days - success-criteria: better understanding of architecture purpose and practice |
This means we’re already in Day 1 for the project: no time to waste.
Overall Aim, Scope, and Purpose
Starting-point: - project-stakeholders are architects and architects’ clients - use the existing Agile-architecture development-process - demonstrate the recursion, etc., within that process - particularly want to describe the sensemaking and decision-making components of architecture, such as via context-space mapping |
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.
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 setup phase
A group of three phases on architecture-assessment
Another group of three phases on implementing the results of that assessment
And a shared completion-phase that wraps up the overall project
By the way, do note that what we’re describing here is not the TOGAF ADM. It intentionally uses the same kind of layout, to support compatibility, but some of the differences are fundamental. In particular, phases B, C, and D work in a very different way: in TOGAF, these are arguably usable only for larger-scale IT projects, whereas in this frame they’re designed for use with any type of content or context, any type of scope, scale, or timescale. To see the difference, compare the labels for each phase to those in the TOGAF ADM.
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.
Assorted notes: - start with a mind-map of key themes/concerns: what is “enterprise architecture”? for this purpose? - how would I use this? – give a real example - “what is an enterprise?” – what is “the enterprise” for this? - use simple checklists: context-space; five-principles; five-elements; four-dimensions segments-model (extended-Zachman) |
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.
The organization is bounded by rules, roles, and responsibilities
The enterprise is bounded by vision, values, and shared commitment
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…
Layer #0 (root): The organization itself
Layer #1 (transactions): Clients, suppliers, suppliers, service-providers, and partners
Layer #2 (interactions): Prospects, regulators, recruiters, the market, and more
Layer #3 (further stakeholders): Competitors, non-clients, anti-clients, government, community, environment, and more
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.
Layer #1 (transactions): Responsible/accountable with suppliers, customers, etc.
Layer #2 (interactions): Consulting and/or consulted by the market
Layer #3 (further stakeholders): Informing and/or informed by those further stakeholders
Layer #0: Physical IT – TOGAF “IT-Infrastructure Architecture”
Layer #1: The “users” of the physical IT-infrastructure, namely, applications and data and their service or partner interfaces – TOGAF “Information-Systems Architectures”
Layer #2: The clients of those applications, human or otherwise – a rather muddled part of TOGAF “Business Architecture”
Layer #3: The “business ecosystem” for the overall architecture – the remainder of TOGAF “Business Architecture”
It’s extremely useful to keep that layered pattern in mind at all times when doing any kind of enterprise-architecture.
From the “101 Things” architecture-book: - the parti is the central idea for the structure – what is the parti here? - sense of place (and what goes on in that place) - architecture vs. space-planning, engineering, design - “good designers are fast on their feet” – an Agile view of the parti - emphasis on process, not product - importance of “thinking about thinking,” as meta-methodology - levels of knowing: simplicity, complexity, informed-simplicity - design in section, not solely in plan! – views into “context-space” - design with models – modeling as a sensemaking/design process - gaining control of design process at first feels like losing control - architecture an exercise in truth and in narrative – what is the story? - everything is in context to a larger context – layering of “enterprise” - design is constrained by rules, regulations, other people's priorities: use those constraints to encourage creativity - do something to get started – and give it a name |
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
Context-space mapping
Five key principles from systems-theory
Five-elements model of concurrent-lifecycle business processes
Four-dimensions segments-model
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).
Simple: “Certain,” decisions in real-time, based on simple true/false logic applied to simple cause-effect relationships with very high repeatability
Complicated: “Certain,” decisions either before or after the event, based on analysis of complicated but linear cause-effect relationships with high repeatability
Ambiguous: “Uncertain,” decisions either before or after the event, based on iterative experiments with non-linear cause-effect relationships that have only partial repeatability
Not-known: “Uncertain,” decisions in real-time, based on principles and values, in contexts with no discernible cause-effect relationships and low to no repeatability
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.
Rotation: A systematic process to assess a context from multiple yet related perspectives – such as a checklist or overview-diagram
Reciprocation: Processes that create balance between systems or between components in a system
Resonance: Positive-feedback or feedforward, which increase the “snowball effect” toward self-propagation, or negative-feedback or damping, which diminish the effect
Recursion: Relationships or interactions which repeat or are “self-similar” at different scales – such as the classic hierarchical org-chart
Reflexion: Holographic inverse of recursion – the whole is reflected in, and can be identified within, any part at any scale
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.
Purpose: Focuses on appropriateness in the enterprise
People: Addresses elegance, values, simplicity, ergonomics, and other human-factors in the enterprise
Planning: Emphasizes efficiency – making the best use of the enterprise’s available resources
Process: Ensures reliability and availability of the functions and services required by the enterprise
Performance: Assures overall integration between all the different elements of the enterprise
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).
“Universals”: Core constants for the overall shared-enterprise “story” such as vision, values, and standards to which everything should align – the key points of connection with enterprise partners and other stakeholders
Row-0: “Enterprise” – identifies the key elements of the enterprise as a whole, within which the organization will operate
Row-1: “Scope” – adds possibility of change: key “items of interest” in each category, without relationships
Row-2: “Business” – adds relationships and dependencies between entities: core entities described in business-terms
Row-3: “System” – adds attributes to abstract “logical” entities, expanded out into implementation-independent designs
Row-4: “Develop” – adds details for real-world “physical” implementation-dependent designs
Row-5: “Deploy” – adds details of intended future deployment as actual software, actual business-processes, work-instructions, hardware, networks, etc.
Row-6: “Operations” – adds details of actual usage: specific instances of entities, processes, etc., as created, modified, and acted on in real-time operations
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.
Assets (“What”): Physical objects, data, links to people, brands, finances, etc.
Functions (“How”): Activities or services to create change, distinct from the agent (machine, software, person, etc.) that carries out that activity
Locations (“Where”): Physical (geography, etc.), virtual (IP nodes, http addresses, etc.), relational (social networks, etc.), time
Capabilities, often as roles or “actors” (“Who”): Human, machine, software application, etc., and either individual or collective
Events (“When”): Physical, virtual, human, business-rule, time-based, or other event
Decisions (“Why”): Reasons, constraints, and other tests which trigger or validate the respective condition, as in strategy, policy, business-requirements, business-rules, regulations, etc.
Physical: Tangible assets, mechanical processes and functions, physical or temporal locations, physical events; also Simple-domain rule-based capabilities and decisions
Virtual: Intangible assets such as data, software processes and functions, logical locations, data-driven events; also Complicated-domain analytic capabilities and decisions
Relational: Links to people (as indirect “asset”), manual processes and functions, social/relational locations, human events; also Ambiguous-domain heuristic capabilities and decisions
Aspirational: Abstract assets such as principles, values, brands and belonging, morale and self-belief, locations within value-webs, some business-rule events; also Not-known domain principle-based capabilities and decisions
(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.)
Physical assets are “alienable” – if I give it to you, I no longer have it
Virtual assets are “non-alienable” – if I give it to you, I also still have it
Relational assets exist between two entities – if either party drops the relationship, it ceases to exist
Aspirational assets represent relationships that are more a one-sided “to” rather than a balanced “between”
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.
More random notes and jottings: - architecture is often about the “non-functional,” the qualitative - is about development of judgement and awareness (otherwise all we have is “follow-the-rules,” which destroys differentiation) - use method and repositories to illustrate themselves - OODA (observe, orient, decide, act) inside-loop in sensemaking - serendipity, obliquity - CSM: order = direct approach, unorder = oblique approach - also CSM: in real-time we don't have time for analysis or experiment – everything that we do is the analysis or experiment - decisions made in real-time may have impacts that last for decades - dynamics of sensemaking – “go for a walk” through context-space - content, context, connections, purpose |
Real client business-problem as demonstrator - loss of respect: “we’ve gone from the most-respected bank in our region to least-respected – what can we do about this?” |
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
How are architecture-projects set up in your own business context? What information do you receive with the work-request? What guidelines and metrics – if any – are defined so as to enable benefits-realization assessment on project completion?
Do you work on your own, as part of a team of architects, or a more diverse team that includes people from a variety of organizational functions? If you work on your own, what options and actions do you have for peer-review? If you work as part of a team, how do you manage the group-dynamics and the respective roles and responsibilities?
How do you identify the stakeholders for the project? The immediate clients for the project will usually be obvious, but which other stakeholders’ interests need to be addressed, and how?
What, for you, is the typical timescale and scope for an architecture project?
What methods do you use to provide guidance and governance for each architecture project? In what ways do these methods change for different timescales and scopes?
How do you start a project? What assessment takes place before you begin, and immediately after starting? How do you manage the inherent uncertainties at the start of each project?
Which frameworks, tools, and techniques do you use in your work? How do you select these, and why? And do they differ from project to project?
What information do you collect during architecture work? How do you store, manage, and maintain this information?
Summary
Context-space mapping, used to guide sensemaking and decision-making
Five key guiding-principles from systems-theory, providing a checklist of structural patterns
A five-step lifecycle-model, describing a linked sequence of types of work within a project
The segment-model, describing types and categories of content that apply in the development
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.