Do you conduct an architecture review every few Sprints?

There are 2 main parts to any application. The UI which is what the customer can see and provide feedback on, and the underlying code which they really can't know if it is healthy or not.

Therefore it is important to conduct a 'test please' on the internal code and architecture of the application.

Ideally conduct a small 'Code + Architecture Review' for every Sprint. Assuming a 2 week Sprint, schedule a 4 hour (2 architects x 2 hours) review.

The following are items that are addressed in an architecture/code review:

Background information/overview of the project

• Current system
• Objectives of the system
• Number of users (internal, external, edit, read only)
• Current technologies
• Current environment (SOA, SOE)

Points for discussion

• Rich client
• Web client
• Smart client (any disconnected users?)

• Technology choices

  • Persistence layer (e.g. Database)
  • Business layer
  • UI
  • Communications
  • Workflow
  • Integration - external systems

• Requirements for 'package' software

  • PerformancePoint
  • Reporting Services
  • Accounting packages
  • SharePoint
• Usage Telemetry
• Performance Monitoring
• Data migrations
• Data reporting
• User experience
• Network
• Responsibilities/players

• Infrastructure

  • Network
  • Hardware

• Deployment

  • Staged implementation
  • In parallel
  • Development/Test/Staging/Production
• Disaster recovery
• Change control/source control
• Build Server
• Performance
• Scalability
• Extensibility
• Design patterns
• Maintainability
• Reliability (failover servers?)
• 'Sellability' i.e. is the solution appropriate for the client?