Rules

Secret ingredients to quality software

Edit
Info

Do you conduct an architecture review every few Sprints?

Created on 01 Sep 2009 | Last updated by Tiago Araujo on 29 Jul 2019 10:22 PM (over 1 year ago)

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?

Note: If you are using Enterprise Architect, be aware of technical debt:

  • Add a datetime of the last time the diagram was modified so we have an indication of when it is out of date
  • On your diagrams, be aware that some parts are done and some are not.
Adam CoganAdam Cogan
Ulysses MaclarenUlysses Maclaren
Cameron ShawCameron Shaw
Justin KingJustin King

We open source. This page is on GitHub