Improved Strategy for Distributed Processing and Network Application Developm...
Arch Review Check List
1. Architecture and Design Review Checklist
Performance
How does it map to the performance curve?
Does it negatively impact other areas, such as landing pages?
What is the expected longevity test needs?
What is the expected capacity test needs?
Is there minimum use of system resources, including memory and execution time?
Does the design facilitate a perceived quick response to user actions?
Is the most critical information relayed back to the user first?
Is asynchronous processing effectively used to improve performance?
Are there any potential sources of bottlenecks in the system?
Is caching being utilized appropriately?
Are there any potential race conditions in the system?
Failover
What are the failover points?
Will the feature as a whole require fault tolerance?
What specific components of the feature need failover capabilities?
What persistent state information is required to support failover?
How will state be handled?
Failure
What are the failure points in the system?
What is the expected user experience for each failure point?
What is the expected system action for each failure point?
Security
From what channels is this feature accessible?
What mechanism is used to secure the feature?
Who has authority to use the feature?
How will this authority be handed out?
2. Robustness, Reliability, Exceptions, and Logging
Is transaction logging going to a common place?
Is clickstream logging going to a common place?
Where is any other application logging going?
What logging needs to be rolled up to the long-term reporting facility?
What will be logged at each point? What will be rolled to the long-term reporting?
How will the support team query the logs?
Are resources appropriately released during errors and timeouts?
Are all resources properly relinquished as soon as possible?
Are resources held onto when they will be re-used?
Does the system do sufficient data validation of input?
Does the system properly handle unavailable resources?
Does the system employ retry logic properly?
Does the system recover from unexpected events?
Does the design ensure that end users cannot carry out any incorrect actions in case of an error?
Are exceptions being caught and reported at the appropriate / correct nested level?
Does the design address generation of detailed debug/trace messages?
Is all critical error information being logged?
Are all necessary elements of a transaction being logged?
Monitoring
Who is expected to monitor the status of the system?
Have transaction test pages/points been identified?
How will the monitoring group be notified of failures?
What is the escalation procedure for faults raised by this app?
Physical Deployment
What hardware will a transaction flow through during its lifetime?
What is the capacity estimates for this feature?
Will additional hardware be required to support this app?
Have URL naming conventions been followed?
Consistency and Reuse
Is the design consistent with other aspects of the system?
Are existing components re-used?
Are design patterns being applied properly?
Are components that have the strong potential of reuse being designed for reuse?
Are components that “probably won’t be reused” being over-designed for reuse?
3. Is there a clear separation of responsibilities between components?
Manageability
How will load balancing be performed?
Does the system provide a “system health status check” capability?
Does the system provide for graceful startup/shutdown capability?
Does the system provide view and modify capability for application characteristics?
Do the error conditions provide understandable messages with enough level of detail to
specify the cause and action that should be taken?
Have all utility program requirements been addressed?
Simplicity
Are Class & Interface names appropriate, easy to understand?
Do any class hierarchies have unnecessary levels of inheritance?
Are classes the “right size” (split apart or merged appropriately)?
Are protocols/handshakes between systems simple and optimized?
Are subsystems loosely coupled and adequately independent?
Is the design flexible (can be modified as requirements change)?
Is the design understandable and coherent?
Are business rules clearly and truly separated from the display components (e.g. no rules in JSPs)?
Miscellaneous
Does the architecture address all roles?
Have existing frameworks been leveraged?
Does the design use and comply with the tools, technologies currently in use?
Does the design meet all business requirements?
Does the design account for backward compatibility?
Does the design minimize impact to existing applications and infrastructure?
Does the design consider packaging/dependency issues?
Are any special security considerations adequately handled?
Are any special deployment issues being considered?
Are there any special fail-over considerations?
Is the design adequately configurable for different environments (dev, prod, etc.)?
Is the system testable?
Have opportunities for testing & monitoring hooks been taken?
Is it possible to isolate run-time problems?
Is transaction scope adequately handled (i.e. something must be a two phase commit)?
Are valid/invalid state transitions being considered (handle browser back button, bookmarks etc)?
4. Does the design have/require a sufficient authentication system?
Does the design have/require a scalable authorization system?
Does the design take into account globalization compatibility?