Description

Roles

Attributes

Steps

1. Create Application Diagram:
   
   Using the domain model and requirements as input, create an application diagram that represents the core logical elements of the system. This will later be partitioned into system diagrams. Alternative partitioning schemes will be considered and evaluated.
   
   Note: Application diagrams in Visual Studio Team Edition for Architects only model ASP.NET applications, Windows applications, and Microsoft Office projects. For more information on generic applications, see Application Types and Prototypes for Defining Applications in the Visual Studio help.
2. Establish Evaluation Criteria:
   
   Determine which criteria to use to identify requirements and scenarios that represent significant architectural challenges.
   
   Consult the existing enterprise architecture documents for criteria. Review any business requirements, technical requirements, and enterprise standards that must be applied to new applications.
   
   Capture additional criteria that are known to be architecturally significant, such as integration with legacy systems, reusability of code, reusing existing vendor libraries and platforms, and controlling maintenance costs.
   
   Capture additional criteria that represent risks and cost when implementing a technical solution.
3. Select Candidate Group of Requirements:
   
   Evaluate each quality of service requirement and product requirement against the evaluation criteria. If a requirement represents an architectural challenge, consider it a candidate for modeling.
   
   For example, a requirement that the new product must support older customer databases meets the criteria of integrating with legacy systems. Such a requirement is a candidate for modeling how the integration would work.
4. Select Candidate Group of Scenarios:
   
   Evaluate each scenario against the evaluation criteria. If a scenario represents an architectural challenge, consider it a candidate for modeling.
   
   For example, a scenario in which the user downloads a client update meets the criteria concerning maintenance costs. Such a scenario is a candidate for modeling how best to handle client updates.
5. Reduce Candidate Group:
   
   Review the candidate scenarios and requirements. Remove scenarios and requirements that duplicate the evaluation criteria or are better represented by other scenarios and requirements. Trim the candidate group to a core group representing the key architectural challenges, risks, and costs of the new application.
   
   Keep the scenarios and requirements that best represent the evaluation criteria, and that present the most risk, and present the most potential cost when architecting for a technical solution.
   
   Keep the scenarios and requirements that are the most comprehensive or key parts of the application.
6. Create Partitioning Criteria:
   
   Using the requirements as motivation, analyze established architectural patterns (such as façade, or model-view-controller), and identify potential candidates for implementation.
   
   Identify candidate patterns through their motivation and consider their design tradeoffs in terms of coupling, cohesion, extensibility, adaptability and flexibility.
   
   Select a set of candidate for implementation as alternatives for assessment.

Inputs and Outputs

WorkProduct	Input	Output	Allowable States
Application Diagram			(none)
Requirement			Active

Successors

Type	Name	Dependency Type
	Design System Architecture and Deployment	Finish-Start