Structured Integrated Solution Architecture Framework (SISAF)

In search of a comprehensive yet workable Framework and Methodology for Solution Architecture, a Structured Integrated Solution Architecture Framework and Methodology is presented – dubbed SISAF; the High-Level & Detailed Reference Models thereof are shown above.

The Model is based on the excellent work of Alan McSweeney - a solution architect extraordinaire, the TOGAF ADM and the Zachman framework.

The Framework is structured as it addresses all of the six dimensions (views) of a Solution: Functions & Results, Business Processes & Actors, Data, Technology, Implementation, and Management & Operation.

It is integrated as it aligns closely with the traditional Project Management Life-cycle stages which in turn dovetail into the Zachman Levels (or Layers) of Architecture:

• Contextual Identification (Early Engagement contextual ideation stage)
• Conceptual Definition (Initiate/Evaluate Project stage)
• Logical Representation (Plan Project stage)
• Physical Specification [& Tooling Configuration] (Deliver & Adopt [Design, Build, Test, and Deploy] Project stages)

Each Layer’s steps conclude with producing a Solution Architecture Artefact which informs a Project Artefact along with its associated activities:

• (Context) Solution Options & Implementation Approach: informs Project charter/Concept
• (Concept) Conceptual Solution Architecture & Rough Order of Magnitude: informs Business Case/SOW
• (Logic) High Level Solution Architecture Design: informs Build & Test Plans
• (Physics) Detailed Solution Architecture Design: informs Deployment & Migration Plans

The Solution Architecture and all its elements are bound by the four Major “constraint categories”:

• The foundational "floor" of Consistency through utilisation of Reference Models, Architectures, patterns & Catalogs
• The limiting "ceiling" of Compliance with Principles, Strategy, Policy, Regulations & International standards
• The bounding "wall" of Business Motivation translated into Business & functional Requirements
• The opposite bounding "wall" of Solution Robustness level translated into Non-Functional requirements & Quality Attributes trade-off

Both of the latter two “constraint categories” (Business, Functional and Non-functional Requirements or Quality Attributes) are continually refined as the solution architecture progresses through the architecture layers from top to bottom.

As mentioned earlier, the Reference Model is based largely on the work of Alan McSweeney with a framework wrapper from Zachman Framework and encapsulated Methodology from both Alan McSweeney & the TOGAF ADM.

Specifically, it is based on the following excellent presentations of Alan McSweeney (albeit with considerable modification and consolidation) which emphasize a Structured Approach to Solution Architecture, the Importance of Early Engagement with the business in Solution Architecture and the Integration of Solution Architecture with the Project Management Stages:

https://lnkd.in/fqPGQat

https://lnkd.in/fjtPwaW

https://lnkd.in/f2VQcwR

It is worth noting that the model’s comprehensive list of Solution Architecture Elements (as shown in the detailed Reference Model) assumes the solution addresses a complex problem. For simpler or less complex problems, many of the Solution Architecture elements in any step in the detailed model’s methodology may not be required and should be bypassed on a case-by-case basis. This is represented by the “(0 or more of):” qualifier present in the Reference Model in most of the steps of the methodology.

However, the approach of progressing from the contextual to the conceptual to the logical to the physical layer while developing the solution architecture, where each layer is concluded with a documented artefact, (regardless of how concise or brief it maybe) should be followed in order to avoid dogmatic resolution/solution or technology selections, and to provide greater traceability to business requirements.