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

Project Portal
| See Also Designing Distributed Systems Create Infrastructure Architecture |
| ### Next Steps Determine Interfaces Develop Threat Model Write Code for a Development Task Code Fix for a Bug |
| ### Patterns & Practices Security Review Performance Review |
| Activity: Partition the System
Architect
|  |  |  | Create Solution Architecture |  |
|  | Participating Roles Responsible: Architect Consult: Developer
### Overview Applications are partitions of a distributed system that contain logically related code elements that deliver a subset of the system’s overall behavior. Partitioning the system has many benefits. It reduces complexity, creates encapsulation, increases the potential for subsystem reuse, and creates logical units for deployment. Complete implementations are not needed all at once. Add the applications necessary to maintain the functionality called for by scheduled scenarios, quality of service requirements, and bugs. Create development tasks to refactor the code to match the new architecture as required. If necessary, validate the new structure with an architectural prototype. # Entry Criteria Dependencies: A set of scenarios and quality of service requirements is scheduled for the upcoming iteration that impacts the application diagram. # Sub-Activities
1 | Choose Architectural Patterns | If the system is to be deployed to an existing environment, examine the logical datacenter diagram to understand the deployment topology. Consider the patterns that would make implementing the system as efficient and as effective as possible for the existing deployment environment. If the system deployment environment does not exist, delay defining such an environment until enough of the architecture is in place to make an educated decision.
2 | Create Applications | Within the application diagram, add or update the applications, endpoints, or connections. Create or update only the applications, connections, and endpoints necessary to implement the scenarios or quality of service requirements for the upcoming or in-progress iteration. However, keep the architecture flexible enough to meet remaining high priority scenarios or quality of service requirements from the scenario and quality of service requirement lists. Add dependencies on services provided by other systems. Look for external interfaces (Web services) or databases that the solution relies upon.
3 | Validate Deployment | Once the application diagram reflects the architecture for this iteration and the deployment environment has been defined, validate the deployment. From the application diagram, choose the define deployment option. Map any new applications to their respective logical servers. Validate the diagram and correct any validation errors that come up.
4 | Create Development Tasks for Architectural Changes | Create new development tasks for any refactoring that needs to occur to move existing functionality to a new application.
# Exit Criteria
| Updates to the applications and their connections are documented in the application diagram.
| If the logical datacenter diagram has been created, the deployment has been trialed and any validation errors are corrected.
(C) 2005 Microsoft Corporation. All rights reserved. Build 97 |