How to Create Solution Approaches
The third and final (3 of 3) Part of the Solution Strategy & Architecture section describes Solution Approaches. In general, Approaches build upon the prior Solution Strategies and Architectural Diagrams & Solution Components to create a series of mid-level artifacts. In turn, the Approach lays the groundwork for iterative planning and implementation.
Specifically, this Part describes how to create each of the various implementation approaches which, together, define an overall Solution Approach. In fact, most Approaches are template-based and table-driven. That is, they apply a 'fill in the blanks' method. Alternatively, a few are compiled by selecting and/or modifying appropriate portions of other standardized materials.
In general, this collection of documents align Solution Definition with Solution Delivery. Specifically, several of these artifacts help populate an initial Solution Backlog. Others define several key processes which relate to Testing and ongoing Operations. Overall, they provide much of the information required for resource planning, budgeting, and to begin iterative planning and implementation.
After reviewing the content on this page, look to the following for additional information.
Bridging Architecture & Delivery: Solution Approaches
A Solution Approach provides broad context about a topic. Additionally, it also identifies individual items related to that topic. For instance, items may identify specific Integrations or Data Migrations. In general, the context for each Approach defines aspects which impact all items related to the topic. In effect, it allows subsequent definition of individual items to avoid restating key information over and over.
An Approach captures information that would be common across all (or most) items in the subject area. As a result, this leaves the individual Solution Design & Delivery items - such as Features and Stories - free to focus upon what is unique to them. In other words, Features & Stories need only address information specific to their objective. They need not restate materials that appear within the Approach, and which would otherwise be redundant if re-stated across multiple items.
"Big Picture" Perspectives
Equally important, a Solution Approach also provides a summary of scope and timing. While the Solution Backlog is the gospel for identifying all items associated with the Solution, each Approach will summarize items targeted at the beginning of each Solution Phase. Moreover, though the Backlog may change, an Approach should remain the same throughout the Phase. In other words, an Approach provides a point-in-time baseline reference.
Solution Approaches are much easier to reference for a big-picture perspective than the Backlog. For example, they are helpful during initial Inception planning activities. At this point, there is a need to prioritize everything against everything else. Of course, it is much easier to work with summary lists than with backlog items. Similarly, each Approach also provides an excellent source for budgeting and resource planning.
By and large, most of the Approaches build upon corresponding Strategies. In effect, the Strategy established the guardrails that items within the Approach must follow. For instance, if a Strategy does not approve a certain tool, or Design Pattern, then no item within the Approach should use them. Conversely, each identified item should only apply tools and patterns which the Strategy approves.
Fill in the Blanks
Fortunately, most Solution Approaches are template-based and table-driven. That is, they are 'fill in the blank' artifacts. Although, many Approaches depend upon the production of other artifacts. In this respect, the Approach merely summarizes what appears in other Solution artifacts. In fact, they provide easier reference, and alternate perspectives, for different audiences. As a result, if completing an Approach is difficult, that likely means the creation of some other required artifact is not complete (but should be).
Checks and Balances
Finally, several Approaches are interdependent with information the Solution's Context Diagram, Logical Diagram & Physical Diagrams depict. For example, both the Context Diagram and Application Approach reference the Business Processes within scope. Similarly, both the Context Diagram and the Integration Approach reference related Products, Systems and Services and the data exchanged between them. In fact, these are checks and balances. That is, nothing should appear in the diagrams which does not also appear in an Approach. And vice versa.
To emphasize, the information within these Solution Approach artifacts defines how the organization will implement this Solution. In other words, they define this unique Solution, as opposed to how a different organization, or different customer, may choose to implement the same packaged software. Afterwards, beyond the Approach materials, identify individual items as Features in the Solution's Backlog.
Compiling the Solution Approach (SA)
SA1 - Application Approach
First, building upon the Application Strategy, this Solution Approach lists the major functions available within each Solution Module. Additionally, it identifies which functions are in, or out, of scope. Similarly, it does the same for major Data Objects (data stores).
Further, for each Legacy System the Application Approach also describes the mapping of legacy functionality to future state functionality. Also, it introduces plans for retiring the legacy process(es) and system(s).
Finally, for each legacy system, this Approach segments the described changes into the Solution Phase during which delivery of the change will occur. As a result, it anticipates which changes are to occur at which times.
SA2 - Integration Approach
Next, building upon the Integration Strategy, this Solution Approach begins with Business Impacts. In effect, it maps the Business Process Definition(s) and their related Data Objects, within scope of a planned phase.
An assessment of each Data Object determines whether an integration is appropriate. For those which are appropriate, a further assessment determines whether the integration will be In-bound or Out-bound. The title given to individual integrations describes the:
- Direction to / from the related (or peer) System.
- Data content (not field-level structures); and
- Design Pattern to use.
The Integration Approach also describes common functions that are applicable to multiple Integrations.
Finally, the Approach segments the identified integrations into the Solution Phase during which delivery of each integration will occur. At this point, the Approach does not describe Data Objects to field-level. For those, refer to the specific Integration Feature which will align to the Solution's Integration Epic.
SA3 - Data Migration Approach
Like the Integration Approach, the Data Migration approach builds upon the Data Migration Strategy. Again, this Approach begins with Business Impacts, mapping the Business Process Definition(s) and their related Data Objects within scope of a planned phase.
An assessment of each Data Object determines whether legacy data should migrate from one or more legacy systems. For those which will receive data, the title given to each Data Migration will describe the:
- Source (or peer) System.
- Data content (not field-level structures); and
- Design Pattern to use.
As with others, this Solution Approach also describes common functions that are applicable to multiple Data Migrations.
Finally, the Approach segments identified Data Migrations into the Solution Phase during which their delivery is to occur. As before, the Approach does not describe Data Objects to field-level. For those, refer to the specific Data Migration Feature which will align to the Solution's Data Migration Epic.
4 - Reporting Approach
Building upon the Reporting Strategy, this Approach also begins with Business Impacts. Again, it maps the Business Process Definition(s), and their related Report Objects, within scope of some planned phase.
An assessment of each Report Object will determine whether it is best to treat the Report as an Integration (see above) or not. A subsequent assessment then identifies whether the report belongs within the Solution's delivery scope, or whether a different Solution, such as a BI or DW Solution, is better suited to deliver it.
Desired Reports have their corresponding data sources and anticipated Design Patterns identified. The Approach also describes common functions that are applicable to Reports of varying types.
Finally, the Approach segments identified Reports into the Solution Phase during which their delivery will occur. Of course, each Report will appear as a Feature in the Solution Backlog. Additionally, each Feature should align with an appropriate Epic.  Unlike Integrations and Data Migrations, there is no general Epic for Reports.  As with other Approaches, specifics such as field-level content will appear in the corresponding Report Feature and/or related Stories as they progress through Analysis & Design.
5 - Security Approach
Building upon the Security Strategy, this Approach also begins with Business Impacts, mapping the Business Process Definition(s) and their related Module functionality and related Data Stories.
Analogous to the Integration, Data Migration and Reporting Approaches, this Solution Approach identified individual Security Objectives (i.e., Features). However, unlike those of the other approaches, the segmentation of work required will not always be as clear cut. An assessment of each Module function and Data Object determines whether there is a requirement for application Security or not. Where there is a requirement, the Approach will describe a Security Objective.
Note that one, or a few, Security Objectives may affect multiple Functions and/or Data Objects. The Approach also describes common functions that are applicable to varying Security Objectives.
Finally, the Approach segments identified Security Objectives into the Solution Phase during which delivery of each will occur. Details of Security Objectives will appear within the Security Objective Features which will align to the Solution's Operations Epic.
6 - Testing Approach
Building upon the Testing Strategy, this Approach describes how to validate changes to the Solution. This Approach is built to support the Application Approach. Additionally, it must align with the Operations Approach, which defines available Environments.
The Approach describes the Test Stages appropriate for the Solution. Additionally, it defines the Test Components and how each is produced. Further, it also identifies the Test Types which will be used to validate the Solution.
Moreover, this Approach defines how to develop and execute tests. Even more, it should describe when tests are built and in which environment(s) they are to run. In the same way, this Solution Approach describes the Test Levels to use, as well as how their progression will establish trust, and confidence, in the Solution. It facilitates all of the above through sound Test Plans which it also describes.
Finally, the Approach will also describe the setup and use of any Test Management System (TMS) and/or other selected testing Tool(s).
Note that unlike other Approaches there is no list of specific tests. Similarly, there is nothing to segment by Solution Phase. Identification and production of test components will occur in conjunction with their corresponding Features and Stories.
7 - Upgrade Approach
Pending Migration
8 - Operations Approach
Building upon the Logical diagram, which describes any single Environment, and in coordination with the Application Approach and Testing Approach which describe what is to happen where and when to deliver the Solution, the Operations Approach describes:
- the various Environments to be available.
- the purpose & use of each.
- the progression of work and test sequencing; and
- the progression of code / configuration from initial development through maturity and onto deployment in Production.
The Solution's Physical Diagrams summarize the content of this aspect of the Operations Approach.
This Approach also defines configuration and use of the Work Management, Collaboration, Test Management, and other supporting tools. Such configurations either enable, or constrain, options for managing Solution Delivery and ongoing Solution Operations.
The pages within this Part conclude the ITM Section on Solution Strategy & Architecture.
After completing this Section, move on to the next ITM Section - Iterative Solution Planning.