Solutions Architecture Dimensions

Overview

A comprehensive Solution Set may need to account for a wide range of things, organized here into representative groupings rather than a rigid checklist:

• Relevant Laws, Regulations, Contracts, Licenses, Leases, and Subscriptions

• Value Streams and Capabilities

• Products and Services

• Processes and Procedures

• Data & Information (e.g., Data & Information Models, Inventories, Integrations, Data Formats, Data Protocols, appropriate KPIs and Metrics — developed further in SAF Phase 1, covered later in this document)

• Tools and Technologies (e.g., Programming Languages, Applications, APIs, Data Transformation and Transmission Technologies)

• Non-Functional Requirements (NFRs) (e.g., Performance, Scalability, Availability, Reliability, Maintainability, Usability, Interoperability, Recoverability)

• Security (e.g., Identity & Access Management, Data Protection, Access Controls, Security Policies)

• Risk (e.g., Risk Identification, Risk Register, Risk Mitigation Planning, Risk Tolerance)

• Regions, Real Estate, and Facilities (e.g., Data Centers, Colocation Facilities, Local Office Racks, Office Space, Manufacturing Facilities)

• Stakeholders, Roles & Responsibilities, and Skills

• Assessments (e.g., Capability Assessments, Technology Assessments, Skills Assessments)

• Relationship Mappings (e.g., Applications to Capabilities, Capabilities to Value Streams, Data & Information to Applications & Integrations)

• Transition Plans and Roadmaps

One distinction is worth making explicit: “products and services” appears twice in this document, in two different senses. Earlier, in the discussion of the EA Platform, “Products and Services” referred to the tools and platforms the Enterprise Architecture practice itself uses. Here, in the context of the SA Dimensions, “Products and Services” refers to something different: the actual business products or services — for example, improving Employee and Consultant Onboarding, or improving Customer Support — that a given Solutions Architecture engagement is trying to improve or create, and which have nothing to do with the EA Platform.

This list is representative, not exhaustive, and is expected to grow as Solutions Architects encounter problems not yet anticipated here. Nor does every engagement require every item on it: not all problems touch Regions, Real Estate, and Facilities, or require a Relationship Mapping exercise, for example. Determining which of these apply, and at what depth, for a given engagement is a judgment call the Solutions Architect makes — not a checklist to complete mechanically.

Most of these groupings tie back to the specialized architecture practices established in “How Solutions Architecture Relates to Other Architecture Practices” earlier in this document. Value Streams and Capabilities, Processes and Procedures, Stakeholders/Roles & Responsibilities/Skills, Products and Services, and most Regions, Real Estate, and Facilities fall under Business Architecture. Data & Information falls under Data & Information Architecture. Tools and Technologies falls under Technical/Technology Architecture — which also, as established earlier in this document, claims the exception within Regions, Real Estate, and Facilities: Data Centers, Colocation Facilities, and Local Office Racks exist to house technology infrastructure rather than support business operations directly, and so fall under Technical/Technology Architecture rather than Business Architecture, unlike Office Space or Manufacturing Facilities. Security falls under Security Architecture. Non-Functional Requirements, Risk, Assessments, Relationship Mappings, and Transition Plans and Roadmaps are cross-cutting or tied to specific SAF phases — Non-Functional Requirements and Risk in particular touch every specialized practice’s own considerations rather than belonging to just one, since performance, scalability, and availability concerns cut across business, technical, data, and security work alike, and Transition Plans and Roadmaps in particular are produced in SAF Phase 3 and detailed further in SAF Phase 5, covered later in this document — rather than belonging to a single specialized practice.

These Dimensions apply twice over, not once: they are the same lens used to document what currently exists — the Current State Solution Set, in SAF Phase 2 — and to determine what should exist — a Future State Solution Set, in SAF Phase 3. Applying one consistent set of Dimensions to both is what makes the change required in each Dimension, moving from Current State to a given Future State option, clear and comparable.

The Current State and Future State data captured across whichever Dimensions apply to a given engagement does not stay local to that engagement. As established in “How Solutions Architecture and the EA Platform Reinforce Each Other” earlier in this document, this data feeds into and improves the EA Platform once vetted — the Dimensions selected here become the categories along which the engagement’s contribution to the EA Platform is organized.

The purpose of a Solutions Architecture engagement is to help the Customer — the owner of the problem — get to as good a solution as possible. The purpose of this chapter is to help the reader understand what it actually means to provide a comprehensive solution: applying the Solutions Architecture Framework across every relevant Dimension, and documenting the result using the Solutions Architecture Reference Book (SARB), covered next.

Best Practice: Deliberately Check Every Relevant Dimension, Not Just the Obvious One

During Vision Development and Current State Collection, deliberately consider each Dimension that may be relevant to the problem at hand, not only the most visible one — this means evaluating whether a Dimension applies, not necessarily producing an artifact for every one of them regardless of relevance. A problem that presents as a technology issue may still require changes to roles & responsibilities, facilities, or regional decisions that are easy to overlook if the review stops at the technology dimension.

Benefit(s)

Deliberately checking every relevant Dimension avoids the specific failure of a technically sound solution that overlooks a non-obvious requirement — an unaddressed process gap, an unassigned responsibility, an overlooked regional or facilities decision — and supports the Customer in actually getting a complete solution, not just a technically elegant one.