Identify Architectural Concerns

(Activity) for Tier: Product

View Training

PURPOSE

Solution Architecture must continually evolve in response to changes in functional needs, enterprise architecture, operational experience, and the overall technical environment. This activity identifies functional, interoperability, operational, or technical concerns that may be best solved by extending or modifying the existing top level design of the product or by adding or changing design patterns specified in the solution architecture.

WHEN

At a minimum at an established regularly recurring interval. Optionally a team may also establish norms for when to immediately respond to the receipt of an expression of a potentially architectural significant concern by a stakeholder. Typically the periodicity, stakeholders included, and communication procedures used will vary between functional, interoperability, operational, and technical concerns.

ENTRY CRITERIA

None

SUB-ACTIVITIES

  1. Discover Potential Functional Concerns

    • Gather information on changes in expectations for the business value the product delivers. Customers may participate directly or the team’s business analysts may act as proxies for the customer. This effort may include a review of new or recently revised Epics, features, user stories or other forms of requirements documentation. Additionally, it provides an opportunity for stakeholders such as project testers and customer support personnel to report shortfalls they have observed in how the product is providing business functionality and ideas they have for how the delivery of business value can be improved.

  2. Discover Potential Interoperability Concerns

    • Review all new or recent changes in enterprise information technology policy documents, enterprise reference architectures, and information from the customer or subject matter experts that pertains to how the product interoperates with other enterprise systems, processes, or environments. Ensure anticipated changes in external interface definitions are explicitly identified. Also consider changes to technical standards prescribed or recommend by the enterprise.

  3. Discover Potential Operational Concerns

    • Gather relevant stakeholder observations on needs, problems, risks, and opportunities for improvement in the ongoing operation of the product in the run time environment. Consider changes or potential improvements in operational concepts and scenarios; anticipated changes to or shortcoming of the current operational environment; how software is deployed to, configured, monitored, and administered in production, staging, test, and development environments; and how well the product is meeting quality of service goals.
    • Optionally, perform root cause analysis of recent product faults, failures, or other types of defects.

  4. Discover Potential Technical Concerns

    • Gather relevant stakeholder observations on needs, problems, risks, and opportunities for improvement in the technology being used to create and evolve the product. Include consideration of development tools; development patterns and practices; technical frameworks and foundations; the state of code in the existing codebase; and overall industry trends that may impact the future viability of technologies.

  5. Evaluate Potential Concerns

    • Evaluate each potential concern discovered and determine if it is a valid concern. If it is, determine if the concern is architecturally significant. This would include concerns that impact the major components of the product and their relationships with each other and the environment; concerns dealing with interoperability with external systems; concerns that impact existing design patterns used in the product or that may merit the introduction of new design patterns; and concerns that impact important quality attributes of the system.
    • As needed, create or update team norms and standards for making a decision on validating architectural concerns.

  6. Document Architectural Concerns

    • Capture a brief description of each Architectural Concern .
    • As needed, create or update team norms and standards for how architectural concerns are documented to in order to improve consistency and quality and to ensure all team members have fast and efficient access to documented concerns.

  7. Prioritize Documented Concerns

    • Provide guidance on the order in which concerns should be addressed. Consider all architectural significant concerns that have been identified but for which no Conceptual Solution has yet been created.
    • As needed, create or update team norms and standards for prioritizing work on architectural concerns.

EXIT CRITERIA

Architecturally significant concerns are described sufficiently to guide creation of a conceptual solution.

SEE ALSO

Process Guidance Version: 10.4