Contact the Enterprise Architecture (EA) Team for support.

The IT Architecture Review is part of the ITS Portfolio Governance process. Please see the IT Solution Architecture Governance page to learn how the IT Architecture Review fits into the larger governance process. This page provides guidelines only for the IT Architecture Review component.

Purpose

Advance ITS Organizational Priorities

• One IT at Yale: Design, share, and reuse proven architectural patterns across the organization. 
• Service Quality: Improve solution design and documentation through input from IT architects and design experts.
• Workplace of Choice: Empower architects and solution designers by sharing techniques and building a professional network.

Advance Service Maturity.

1. Design solution architectures that eliminate technical debt and run efficiently.
2. Adhere to proven, repeatable, secure, and reliable IT architectures and IT Architecture Standards.
3. Advance business continuity through well-documented IT architectures.
4. Leverage architecture and design technical expertise from across the organization.

Projects Requiring Review

The following projects are required to contact the EA Team to determine review requirements.

• All ITS portfolio projects and ITS Ready-To-Serve (RTS) projects are required to follow the ITS Portfolio Governance process.
• All projects with new architectures or substantive architectural changes in any component.

Type of Review

The EA Team will determine the type of IT Architecture Review required. 

1. No review is required.
2. EA Team review required.
3. Technology Architecture Committee (TAC) review required. 

Presenters

The Lead Architect (a qualified solution architect or equivalent) is expected to present the solution architecture. Other team members are welcome to attend.

Scheduling

Reviews are scheduled through the EA Team. The review should be scheduled early enough to allow time to incorporate feedback from the review. Approval of the solution architecture is required to pass the Design Gate of the IT Portfolio Governance process. 

Support

The EA Team or IT architect on the TAC will support the project's Lead Architect in preparing a design and presenting the architecture. The EA Team understands that a "Not Approved" ruling will be detrimental to the project's timeline and budget. Therefore, significant effort is made to encourage projects to have the necessary architectural resources available, start work on architectural design early, and request feedback from the support architect with ample time to incorporate needed adjustments

The Review

The review is scheduled for thirty, forty-five, sixty, or ninety minutes depending on the complexity of the review. EA Team reviews include one to three reviewers. TAC reviews have ten to fifteen reviewers. The EA Team leads the review, keeping it on topic, on time, and collaborative. 

Presentation Guidelines

The IT Architecture Review focuses on the solution design, conformance to ITS Standards, use of proven architectural patterns and their fit into the broader enterprise architecture. Project brief information provides context for reviewers but is not evaluated in the IT Architecture Review.

IT Architecture Review documentation should contain the following:

1. Title
2. Reason for Review
3. Project Goals Brief
4. Stakeholders Brief
5. Success Criteria Brief
6. Unique Requirements Brief
7. Risk Classification Brief
   1. Risk Classification
   2. Data Classification
   3. Availability Requirement Classification
   4. External Obligations Classification
8. Security Planning Assessment (SPA) Brief
9. Logical Block Diagram (see below)
10. Physical Block Diagram (see below)
11. Information Flow Diagram (see below)
12. Integration Schedule and Methods
13. High Availability Design Overview
14. Disaster Recovery Design Overview
15. ITS Standards and Minimum Security Standards Compliance and Exceptions Overview
16. Lifecycle management and exit strategy overview
17. Decommissioning Plan
18. ITS technical staff readiness assessment to support solution operations
19. Risks and open issues overview

The Review Ruling

The reviewers will rule as to whether the solution design sufficiently, conforms to ITS Standards, uses proven architectural patterns, fits into the broader enterprise architecture, and whether the organization has the essential technical skills to operate it. The ruling will be one of the following:

1. Approved as presented
2. Approved with recommendation (not required to be implemented)
3. Approved with contingency (required to be implemented)
4. Not Approved

The EA Team will document any exceptions to ITS standards that are granted to the project. These will need to be revisited at future lifecycle events such as major software upgrades or infrastructure refactoring.

Diagram Examples

Logical Block Diagram

A logical block diagram depicts all of the system components in an organized representation of the solution architecture using blocks, icons, layers, segmentation, and relationships. The diagram distinguishes and organizes components using shape, color, location, and other graphical devices.

Example: Logical Block Diagram.

Physical Block Diagram

A physical block diagram depicts all of the system's components, physical infrastructure, and virtual infrastructure in an organized representation of the solution architecture using blocks, icons, layers, segmentation, and relationships. The diagram distinguishes and organizes components using shape, color, location, and other graphical devices. These diagrams include but are not limited to, the following.

• Layer 3 devices (routers, firewalls) if they are relevant to the architecture
• Hosts for middle-tier and database-tier services
• Load balancers
• Connecting protocols
• Software technology stacks
• Other components that are part of the configuration and relevant to its function

Example: Physical Block Diagram

Information Flow Diagram

An information flow diagram indicates what data a technology consumes, produces, and transports among the various logical components and the user. Unlike the block diagram, the information flow diagram isn't all-inclusive. It demonstrates, in broad strokes, how data is managed. This includes any data-passing protocol classes being used (e.g. via SOAP web service) as well as any data lifecycle decisions being made (e.g. It’s cached for a week and then refreshed). If the technology consume data from a canonical source, identify the source and the mechanism for incorporating the data. Identify moderate or high-risk data.

Example: Information flow example. Note that this vendor diagram could be improved by providing details on the protocols used in the data flows.