Task: Perform Technical Feasibility Exploration
Develop and assess an architectural proof-of-concept for an SOA solution, based on existing architectural requirements and risk profile.
Purpose

To synthesize an exemplar solution that meets the critical architectural requirements.

Relationships
RolesPrimary: Additional: Assisting:
InputsMandatory: Optional:
  • None
External:
  • None
Outputs
Main Description

The task is performed generally to address risks regarding the ability of an existing asset to meet the requirements for a candidate service. 

  • The transactions that need to be componentized and exposed need to be identified as part of the Asset Fit Gap Analysis.
  • Elements of these Architectural Proof-of-Concept decisions and considerations relate back to both functional and operational aspects of the architecture.

When dealing with existing applications, examine and consider the items described in Guideline: Non-Functional Requirements for Existing Systems .

The above list is not meant to be exhaustive; it is provided here for guidance.

Example: Perform Technical Feasibility Exploration presents a realistic scenario driving a technical feasibility exploration effort.

Steps
Determine evaluation criteria

Draw the criteria against which the Architectural Proof of Concept is to be evaluated from the architecturally significant requirements for the concept under evaluation and from the functional requirements for the candidate service(s) that are under consideration.  Leverage the Software Architecture Document and the Service Model. 

Decide on construction approach

Work with the Developer to select the techniques to be used to construct the Architectural Proof of Concept, for example:

  • Conceptual modeling
  • Rapid Prototyping
  • Simulation
  • Automatic translation of specifications to code
  • Executable specifications
  • Construction of spikes as prototypes - vertical slices through layers
Select assets and technologies for Architectural Proof of Concept

The Developer selects the assets and technologies to be used to construct the Architectural Proof of Concept.

Construct Architectural Proof of Concept

Using the techniques selected for construction, the Developer builds the Architectural Proof of Concept, using the selected assets and technologies, to satisfy -- to the extent required by the risk profile of the project -- the functional and non-functional requirements for the candidate service.

Evaluate Architectural Proof of Concept

Test the Architectural Proof of Concept against the evaluation criteria.  The way that this is performed depends on the form of the proof-of-concept. For example:

  • In the case of an executable prototype, this might be through demonstration
    • For a conceptual model, through inspection and reasoning; or,
    • For a simulation, requiring the set-up and running of the simulation model with input data derived from the evaluation criteria, the testing is performed by collecting and analyzing output data from the model.
Assess results

Assess the results to determine whether the evaluated concept (generally an existing asset) meets the requirements for the candidate service.  Also, use these results to check on the validity of the requirements. At this time in the project, requirements are still mutable and not necessarily well-understood by the stakeholders.  For example, perhaps the opportunity exists to relax requirements that were shown to be high-risk by the evaluation of the Architectural Proof of Concept. All these avenues need to be thoroughly explored in assessing the results.  This contrasts with the situation later in a project, when there will be much greater reluctance to change or reinterpret requirements.

Update the Asset Fit Gap Analysis based upon the results of the Proof of Concept.

Properties
Multiple Occurrences
Event Driven
OngoingYes
OptionalYes
Planned
Repeatable
Key Considerations

The exemplar might be limited in some way, such as:

  • The resulting solution might simply be conceptual
  • The resulting solution might only illustrate some critical aspect of the overall requirements.
More Information