Task: Define Solution
This task focuses on defining a solution.
Disciplines: Architecture
Purpose

Note: Though the steps in this task are presented in a logical order, one might need to alternate between them or perform some of them in parallel

Relationships
Steps
Perform Gap Analysis

Note: Though this step is presented in a logical order, one might need to alternate between it and the other 3 steps contained in this task or perform some of them in parallel.

This step is performed by doing a pair-wise comparison of the COTS packages identified in the context of the marketplace sphere to the information gathered from the architecture and design sphere, stakeholder needs and business processes sphere, and programmatics and risks sphere. The focus is on trying to understand where they match, where they don't match, and a characterization of the mismatches.

The pair-wise comparison does not have to focus on all the spheres at the same time. For instance, the step could start by comparing the identified COTS packages to the information gathered from the architecture and design sphere only, in order to access how each COTS package fits into the enterprise architecture. Based on this information, some tradeoffs could be negotiated and a solution formed. Then, the information gathered from the stakeholder needs and business processes sphere could be added in order to assess how each COTS package supports the required user business processes. Based on this information, some tradeoffs could be negotiated and the solution refined. This process continues until the solution is formed based on all the available information gathered from the spheres.

Negotiate Tradeoffs

Note: Though this step is presented in a logical order, one might need to alternate between it and the other 3 steps contained in this task or perform some of them in parallel.

This is a key step to make sure that any identified mismatch is understood and resolved. It is imperative to understand how important each mismatch is to the solution and understand the possible ways the mismatch can be resolved. Mismatches can be resolved through negotiating with stakeholders to modify user business processes and stated stakeholder needs; gathering more information about the capabilities of the COTS packages and their ability to be tailored to accommodate the mismatch; changing the way the architecture uses the COTS packages; or creating a custom component to provide the necessary capability. If a mismatch cannot be sufficiently resolved, the candidate solution can be removed from further consideration.

Form Solution

Note: Though this step is presented in a logical order, one might need to alternate between it and the other 3 steps contained in this task or perform some of them in parallel.

With an understanding of the matches and mismatches, a solution is formed (or updated) by assembling one or more COTS packages or COTS package components, legacy systems (piece of the systems being replaced), reuse libraries, other reuse sources (for example, freeware, shareware), any required custom code (including wrappers and "glue") and appropriate linkage to the broader organization's architecture with which the solution must interface. The solution architecture and design is capture in the solution dossier.

Score Solution

Note: Though this step is presented in a logical order, one might need to alternate between it and the other 3 steps contained in this task or perform some of them in parallel.

The objective of this step is to score the solution against the project's constraints, including the critical use cases and the critical non-functional requirements, architectural and design constraints, project management constraints, and any constraint related to business processes. The rating is done by using Requirements Attributes. Again, involving all stakeholders (or empowered representatives) is highly recommended while performing this step in order to gather as much feedback as possible on the candidate solution.