Checklist Description: This checklist captures common elements that should be present in system
architecture and application design. It is presented during the Conceptual Architecture/Design
Compliance Review process to stimulate thought, guide brainstorming, and to ensure the architecture
and design process being outlined contains all appropriate considerations. To ensure that the system
envisioned fully addresses University Services Enterprise Architecture context, standards and principles, assess the Architecture/Design considerations that apply to your subject matter expertise
and organizational needs.
Project Name: Review Date:
Assessment and Recommendations: Notes:
Approved without revision
Approved with revisions (see Notes)
Artifacts Reviewed: Technical/Functional Specification(s)
Charter/Project Management Plan Application Architecture Diagram
Business Requirements Document
Does the architecture allow for implementation of all of the known major requirements?
Does the architecture communicate an adequate vision of the system that will direct further design activities?
Is the architecture well organized and provide a concise system
overview, background information, constraints, and a clear
organizational structure for all downstream designs?
Is the architecture designed to accommodate likely change?
To the extent possible, is the architecture independent of the technology that will be used to implement it?
Are all external interfaces, including user interfaces, identified and justified?
Is the level of robustness specified and justified (robustness generally
means that the architecture is capable of functioning correctly - or at the
very minimum not failing catastrophically - under many conditions)?
Is the architecture appropriately layered (client/presentation tier, business logic tier, and data tier)?
Is the architecture feasible for implementation?
Can the components be integrated and tested in an incremental fashion?
Is there any missing or incomplete logic?
Can the parts of the architecture be traced back to requirements?
Are standard, not proprietary, components being used wherever possible?
Does the architecture avoid unnecessary redundancy?
Will the proposed architecture satisfy all specified quality attributes and performance goals?
Is an error-handling strategy described and justified?
Have maintainability issues been adequately addressed? ? 2009 Regents of the University of Minnesota. All rights reserved. Page 1
Have all reliability and performance needs been addressed?
Have all security considerations been addressed?
Does the design support both product and project goals?
Is the design feasible from a technology, cost, and schedule standpoint?
Have known design risks been identified, analyzed, and planned for or mitigated?
Does the level of formality match the project size, project goals, and development expertise?
If possible, were proven past designs reused?
Does the design support proceeding to the next development step?
Can the design be implemented within technology and environmental constraints?
Does the design emphasize simplicity over cleverness?
Does the design create reusable components if appropriate?
Have all reasonable alternative designs been considered, including not automating some processes?
Does the design allow for ease of maintenance?
Have the follow areas been considered and included for detailed planning:
Legal and Regulatory Considerations
Information Security and Access Considerations
User Interface Considerations
Performance and Availability Considerations
? Service Level Definition
? Capacity Planning
? System Monitoring
? Business Continuity and Recovery
Component Reuse Considerations
Data Storage and Retention Considerations
Error Management Considerations
Quality Assurance Considerations
Reporting and Management Information Considerations
? 2009 Regents of the University of Minnesota. All rights reserved. Page 2