|
|
 |
 |
 |
 |
Activity:
Partition the System
 |
|
Participating Roles
Responsible:
Architect
Consult:
Developer |
Applications are partitions of a distributed system that contain logically related code elements and 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. To create an agile architecture, MSF utilizes shadowing. A shadow is an architecture for the functionality to be completed in the iteration. The shadow leads the working code at the beginning of an iteration as the architects get out in front of the development for the iteration. During this time, the architecture and the working code are not in sync. This shadow communicates any re-architecting or redesign that needs to occur to keep the code base from becoming a stove pipe, spaghetti code, or one of the many other architectural anti-patterns. As the pieces of the leading shadow are implemented, the architecture begins to reflect the working code base. The original parts of the system that were architected but not implemented, now become implemented. When the architecture represents the working code, we call the shadow a trailing shadow. As the sun sets on the iteration, all of the leading shadow should be gone and replaced strictly by trailing shadow. The trailing shadow is an accumulation of the architectures over all of the iterations. To keep architecture from becoming too detailed, we recommend that it be focused at the component and deployment levels. Add the applications necessary to maintain the functionality called for by scheduled scenarios, quality of service requirements, and bugs. At the beginning of the iteration, add the 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 a logical datacenter diagram to understand the logical deployment topology. If no datacenter diagram exists, create one.
- Consider the system topology patterns that would make implementing the system as efficient and as effective as possible for the existing deployment environment. If the physical system deployment environment does not exist, delay defining such an environment until enough of the architecture is in place to make an educated decision. Use a logical datacenter diagram to describe a logical deployment topology which can later be used to design or map to an existing deployment topology.
|
|
2 |
Create Applications |
- Within the application diagram, create a leading shadow or the equivalent of the system topology chosen. Create a system diagram from the shadow applications and add proxy endpoints for all of the unimplemented endpoints.
- 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. Create shadow applications in a system diagram and add any unimplemented proxy endpoints.
- 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 to implement the leading shadow and for any refactoring that needs to occur to move existing functionality to a new application.
- Check in the application and system diagrams for the tasks and attach the relevant diagrams to the tasks.
|
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. | |
 |
 |
 |
 |
© 2006 Microsoft Corporation. All rights reserved.
Version 4.1.0 |
 |
Overview 