Create Conceptual Solutions

(Activity) for Tier Product

PURPOSE

A Conceptual Solution specifies how a system’s structure and design patterns will address an architectural concern or a set of related concerns. These solutions can range from very narrow and specific such as using a particular code style in certain circumstances or very broad and all-encompassing such as adopting a general type of technology. The overarching objective is to optimize the system as a whole’s delivery of value over time.

Note

The time and effort required for this activity can vary dramatically. With well-established team norms and for a relatively narrow concern with low risk this activity may only take a few minutes to complete end-to-end. Conversely, for broad concerns that pose high risks conducting this activity may be a major undertaking requiring considerable time and resources.

WHEN

Based on concern priority, appropriate personnel become available.

ENTRY CRITERIA

Todo

ASG needs to determine the entry criteria for this activity.

SUB-ACTIVITIES

  1. Identify Potential Solutions

    • Define one or more conceptual solutions to the concern in sufficient detail to understand and evaluate the effectiveness of the solution. Research established industry and company patterns and practices that might be applicable. Include consideration of available options for code reuse through the purchase of applicable commercial products, the adoption of open-source software, or the reuse of components developed previously or developed by other projects. Optionally conduct brainstorming sessions that include stakeholders with diverse backgrounds and skills.
    • When needed, create proof-of-concept software to gain a better understanding the utility of potential solutions.
    • Capture concepts proposed for evaluation using artifacts appropriate for the complexity and scope of the architectural concern being addressed.
    • As needed, create or update team norms and standards for when and how to create proof-of-concept software and for the types of diagrams or other artifacts used to capture conceptual solution in order to improve team communication and efficiency. Consider use of industry standard UML structural and interaction diagrams. Strongly consider use of user experience research to identify user workflows, problems and/or existing usability issues.

  2. Determine Evaluation Method

    • Decide if the solution to the concern will be determined informally through consensus or if a formal evaluation process will be used to select between explicit alternatives.
    • An informal evaluation process is an unstructured discussion among relevant team members on the effectiveness and feasibility of either one or several potential solutions. Informal evaluations are intended to find solutions quickly when the risks inherent in potential solutions do not merit the time required for a formal evaluation.
    • A formal evaluation process is a structured method for deciding between alternatives using a consistent analytical method and rigorously defined criteria. Examples of formal evaluation processes include the Lightweight Architecture Alternative Assessment Method (LAAAM) and the Analytic Hierarchy Process (AHP).
    • As needed, create or update team norms and standards for criteria used to determine when a formal evaluation is required in order to ensure consistency. If a formal evaluation method is used, document the methodology to facilitate future reuse by the team.

  3. Establish Selection Criteria

    • Determine what quality attributes of the system will be used to evaluate potential solutions and the relative importance of these attributes. This includes factors that affect run-time behavior, system design, and user experience and commonly includes concerns such as maintainability, availability, interoperability, performance, reliability, scalability, security, supportability, testability, and usability.
    • As needed, create or update team norms and standards for selection criteria to ensure consistency.

  4. Evaluate Potential Solutions

    • Using the selected evaluation method determine the relative suitability of each solution identified. Suitability includes the benefits, explicit costs, and opportunity costs of a solution during both initial development and long-term operation in the run time environment. Ensure participation of all relevant stakeholders in the evaluation process.
    • Capture the outcome of the evaluation using artifacts appropriate for the complexity and scope of the architectural concern being addressed. When a formal analytical method is used include the relative ranking of the criteria used and the relative ranking of the potential solutions.
    • As needed, create or update team norms and standards for stakeholder participation in solution evaluation and for how Architectural Evaluation Results are documented.

  5. Select Conceptual Solution

    • Deliberate on the proposed solutions and their evaluations and attain a team commitment to a final selection.
    • If needed to mitigate risk create a prototype implementation of a proposed solution. Prototypes should only be created when the architectural concern is critical to project success, there is significant risk in the solutions efficacy, and it will be difficult and expensive to change the solution after it has been fully implemented.
    • Document the team commitment to the solution as needed using artifacts appropriate for the complexity and scope of the solution.
    • As needed, create or update team norms and standards for attaining and documenting a team commitment to a solution and for when and how to create prototype software.

  6. Submit Technology Notification Insertions

    • Per the Architecture Review Policy mandate, always gain company approval for implementing a solution. This is generally only required in cases where implementing a solution entails significant business risk for the company, such as new technology, software, library, font, image, or other intellectual property not owned by InnovaSystems.
    • Use the provided online form or send an email to the Chief Technology Officer (CTO) and Development Manager if the online form is unavailable.

    Note

    Changes to architectural patterns in support of business needs does not require an approval from CTO. Use your best judgement when deciding to submit, if unsure it is best to submit.

OUTPUTS

EXIT CRITERIA

A technology insertion notification is sent when a new technology is introduced.

SEE ALSO

Process Guidance Version: 10.4