Overview |  | Roles |  | Work Items |  | Views |  | CMMI |  | Index |  | Glossary |

Project Portal
| ### Next Steps Design System Architecture and Deployment |
| Create Alternative Application Partitioning Designs ( 3 : TS : 1 : 1.1 ) ( 3 : TS : 2 : 2.1 ) ( 3 : DAR : 1 : 1.3 ) Solution Architect
Activity: Create Alternative Application Partitioning Designs
Solution Architect
Developer
|  |  |  | Planning |  |
|  | Participating Roles Responsible: Solution Architect Developer Accountable: Solution Architect
### Overview The problem is analyzed, and different approaches are considered. A group of requirements are selected that represent key business and technological challenges. Examine the characteristics of these challenges, such as integration of legacy systems, predicting future needs based on current needs, reusability of code, and maintenance costs. # Entry Criteria Existing Enterprise Architecture Application diagrams must fit into existing enterprise architecture. Product Requirements Must be approved for current iteration. Domain Model Includes object or data models. Quality of Service Requirements Used to identify architectural challenges. Scenarios Used to identify architectural challenges. When: Project begins or iteration begins. # Sub-Activities
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.
# Exit Criteria
| An application diagram with all key elements necessary to evaluate each architectural approach is created.
| A set of alternative suggestions for architectures to be evaluated.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |