DEVELOPMENT SERVER
Rules to Better Work Items ( AKA Project Management )

An internal architecture review is the application of the Test Please principle against the design phase. An architecture review conducted during every release minimizes errors in design which saves future rectification costs.

Schedule a 4 hour (2 architects x 2 hours) review during all releases. While it may not be so important to conduct a review in every development release, they are compulsory for a specification release.

The following are items that are address in a 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 (SQL Server, Access, SQL Express, LINQ, netTiers)
  • Business layer
  • UI
  • Communications
  • Workflow
  • Integration - external systems
• Requirements for 'package' software
  • PerformancePoint
  • Reporting Services
  • Accounting packages
  • SharePoint
• 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?

Enterprise Architect

• should have a datetime of the last time the diagram was modified so we have an indication of when it is out of date
• should have the ability to mark items as ‘todo’. E.g. it would be nice to have an indication of which items on the diagrams have been completed, and which are still pending