1. Architecture Decision Group Group Organization & Processes April 7, 2015 | Tuesday

2. Agenda Architecture Decision Group Principles Organizing the Enterprise Architecture Model Current Architecture Domains, Issues, and Decisions EA Decision Group Processes Guidelines & Tools 2

3. EA Decision Group Principles 3 Decisions provide a precedent, not laws for all time Group decisions will be made based on information available at the time. Technology changes rapidly; the right design decision today may not be right in a year or two when the context of the problem or the available technologies have changed. That said, reversing a decision should not be done lightly. Decisions — and the rationales behind them — must be written down A decision known only to a few does not help Harvard. Decisions and their rationales need to be recorded in a known place. Decisions are made by a small group, but anyone can provide input To keep the process manageable, decisions will be made by a small group of technical stakeholders selected by permanent members of the EA Decision Group. However, topics for discussion should be made generally known, and written input from anyone is welcomed and encouraged. We must strive for simplicity in Harvard IT systems at every level Harvard is an intrinsically complex place, but we should strive for the simplest technical solutions possible at all levels — from the infrastructure we use, to the programs we write, to the way those programs interact. This does not ensure that complexity will not creep into the system, but it safeguards against a system too complex to work reliably or allow for change. We will strive for a small number of standard platforms Reducing complexity includes reducing platforms — operating systems, database systems, web servers, etc. This requires balance, since too few platforms means that real differences cannot be accommodated but too many makes operating all systems overly complex. Deviations from set standards that do not establish addition to the standard (that is, deviations that are not applicable to an entire class of applications or uses) will be strongly discouraged.

4. EA Decision Group Publishing: Organize to the EA Model 4

5. User Experience Applications, Services, and SaaS Cloud Development Environment (scheduled open issue) Define cloud development environment methods, tools, and techniques Cloud Operational Environment (scheduled open issue) Define operational levels and services Dependent Job Scheduling (unscheduled issue) Define mechanism to handle dependent jobs scheduling that works in the cloud and on-premise Test Data (unscheduled issue, recently added) Development and testing environments should not contain data at level 2 or above Interoperation Data Middleware & PaaS 5 Current Architecture Domains, Issues, and Decisions

6. Infrastructure and IaaS Virtual Private Clouds (decided Jan. 9, 2015) Define topology of AWS accounts, regions, VPCs, and instances Supported cloud stacks/images (scheduled open issue) Define basic software stacks that we will support/allow in the cloud Using Standard Patterns (unscheduled issue, recently added) Leverage standard patterns; introduce processes around managing cloud resources HUIT support of non-HUIT groups in the cloud (unscheduled issue) Determine approaches for how HUIT supports non-HUIT groups in the cloud Networking Network & Security Architecture (scheduled open issue) Design environment to be restricted and safe, or work on detecting and eliminating security problems as they happen DNS (unscheduled issue) DNS re-architecture proposal IPv6 Adoption (unscheduled issue) Decide how to drive IPv6 adoption beyond the network group Direct Connect Routing and Encryption (unscheduled issue) Determine configuration for communications channel between cloud and on-premise Security 6 Current Architecture Domains, Issues, and Decisions

7. Architecture Decision Group Processes Intake: Accept architecture issue submissions and requests for architectural guidance Discussion & Research: Convene meetings with appropriate membership to assess issues, weigh alternatives, and prepare recommendations for decisions Reviews: Work with application and project teams to review architectural directions, submitting requests for guidance when needed Decision & Waivers: Accept recommendations and, after deliberation, require additional study, announce decisions, or issue waivers Notification: Use notifications to solicit issues, enlist group participation in the discussions, and issue advisories when appropriate 7

8. Architecture Decision Group Guidelines & Tools 8 Content The group will consolidate issues, document discussions, and give decisions Each issue will be given its own set of pages, with the expectation that each issue’s working group will document issues, discussions, and recommendations The group will communicate broadly to enlist participation and announce decisions Content Management The group will use the wiki as a collaboration and content management tool Notification Tools and Methods Harvard wiki pages (e.g. https://wiki.harvard.edu/confluence/display/HUITArch/HUIT+Architectural+D ecision+Group) Email, including distribution lists ABCD meetings and ABCD communications mechanisms Blogs

9. Next Steps 9 Enhance the wiki: –Summary pages of issues and resolutions –Detailed pages for issues and working documents Communicate broadly with the HUIT community –Purpose and location of the wiki pages –Description of the processes Continue to resolve any in-process issues Schedule discussion and research for issues still pending

10. Questions or comments?

11. Thank you!