The HUIT Architecture Decision Board will drive simplicity and consistency across HUIT's technology stack. It will provide timely support for decisions that impact multiple groups. The board will be composed of 5 permanent members and will invite subject matter experts to discussions. It will operate transparently by writing and publishing decisions and justifications on a public wiki for the HUIT community.

1. HUIT Architecture Decision Board
Overview

2. The problem
• Similar decisions need to be made in different groups
– What cloud structure do we adopt?
– What is our basic software stack?
– What does our development environment look like?
• Separate decisions create complexity
– Local optimization leading to global confusion
– Differences that don’t make a functional difference
• No group or process to adjudicate architectural discussions HUIT-
wide
– Informal groups aid in communication
– Some groups that drive consensus
We need a pan-HUIT architectural group
2

3. Example Issues
• Virtual private cloud structure
– One VPC, emulating the physical data center
– Multiple VPCs
• How many
• What are their characteristics
• Cloud stack
– Operating systems
– Databases
– Web servers
• Operational tools
– Monitoring
– Logging
3

4. 4
Determine broad architectural principles for HUIT operations and development
Charter
• Drive simplicity throughout
the technology stack
• Insure consistency of
architecture from group to
group
• Provide timely support for
technical decisions
• Ensure that decisions are
justified and understood by
those impacted by the
decisions
• Interpret the enterprise
architecture in particular
cases
Strategic Objectives
• Whenever possible, push
decisions down to local
groups
• Timely address particular
problems that span multiple
groups
• Transparent process with
written decisions
• Practical
• Invite participation
throughout the technical
community
• A decision making body, not
a consensus forming body
Guiding Principles
• Fast turn-around of design
issues that span groups
• Written decisions
referenced by multiple
groups
• Inclusion of decisions into
University enterprise
architecture
• Adoption of the decisions
over multiple groups
Key Performance Indicators
Architecture Decision Group

5. Strategic Objective
• Drive simplicity through the technology stack
• Avoid unintended differences
• Provide common patterns
• Insure architectural consistency
• Provide timely support for technical decisions
• One-stop shopping for broad sets of guard rails
• Ensure the decisions are justified and understood
• All decisions, with justifications, will be written and available
• Interpret the Enterprise Architecture in particular cases
• The enterprise architecture will need flexibility; this group decides (when
needed) on the application
5

6. Guiding Principles
• Whenever possible, push decisions down to local groups
• Only get involved when the issue crosses group boundaries
• Ask impacted groups for input and advice
• Timely address particular problems that span multiple groups
• Move quickly
• Re-examine when evidence dictates
• Transparent process with written decisions
• Practical
• Invite participation throughout the technical community
• Expertise exists everywhere
• A decision making body, not a consensus forming body
6

7. KPIs
• Fast turn-around of design issues that span groups
• We don’t slow development or deployment
• Written decisions referenced by multiple groups
• People are reading and following the decision
• People are contributing to the process
• Inclusion of decisions into University enterprise architecture
• Adoption of the decisions by multiple groups
• Consistency of design
• Differences should make a difference
7

8. Process
• Issues identified
– Added to the backlog
– Scheduled for discussion or pushed down to local group for
recommendation
– Area for opinion and comment write-ups created
• Experts are identified and invited
– This may be on-going
• Issue is discussed, decided
– Member of the group writes up decision and justification
– Comments invited from the community
• All of this occurs on the publicly open wiki
8

9. Group Composition
• Five permanent members (for continuity)
– CTO (Jim Waldo)
– Deputy CIO (Ben Gaucherin)
– CISO (Christian Hamer)
– MD of Architecture and Engineering (Jason Snyder)
– Director of Networking (Jefferson Burson)
• Meetings are invitation only
– Invited experts
– Invited observers
– Encourage honest discussion
• All are invited to submit written opinions
– Some of these may result in invitations to attend
9

10. Communication Wiki
• Scheduled backlog of issues
– What is currently scheduled for discussion and decision
– What has been decided (with links to decisions)
– Open area for unscheduled issues
• Anyone can add to this area
• Pages for decisions
– Includes both the decision and the justification
– Links to opinion pieces
• Areas for opinion pieces to be submitted
– Opinions can come from members, guests, or the community
– Will become part of the record for an issue
10