Travel, parking, hotels, etc. | Schedule and agendas | Working documents and links | Captured flip-charts and notes |
Schedule
| | 8:30-11:45am | 11:45-1:15 | 1:15-5:00pm | 6:00pm |
|---|
| Day 1: Wednesday | No meeting | | Facilitator: Heidi Barta, UW-IT Organizational Development - Set goals for the meeting,
- define outcomes,
- define work processes,
- define / identify repository
- define process for maintaining the content
- identify and prioritize topics,
- assign leads for topics
- Review current work / wiki
| Ad hoc dinner |
|---|
| Day 2: Thursday | Continue with selected topics | Lunch | Continue with selected topics | Ad hoc dinner |
|---|
| Day 3: Friday | Post-workshop action items | | No meeting | |
|---|
Goals and Approach
Workshop goals
- A deep dive into each tool using a selected use case from Higher Education as an illustrative example (eg using Core diagram to describe the Advising ecosystem on campus)
- Document usage of the tool and “how to get started” information for architects
- Find a broad set examples where people have used them
F2F meeting structure
This would be like an (un)Conference where we would be agile in the agenda and deliverables but focused on creating a set of resources for ITANA members
- Use break-out groups each concentrating on a topic
Outcomes
- In person idea sharing and exchange
- A best practices library relating to the use of these tools
- A set of guidelines for each tool. In what context is the tool useful? Who is the intended audience? What kinds of information does it best convey?
- Information that can be applied to one or more problems at the home institution. Ideally that work can be fed back to the library started in the F2F
Strawman for an approach
Using principles from hackathons and unconferences.
- Use most of day 1 for stage setting. I believe the items listed in the agenda above will fill up the time, but by the end of the day we should have topics, leads, and teams to tackle them (topics, not leads). We might want to encourage teams to eat dinner together and begin discussions on their topics.
- Day 2 is hackathon day. Teams work on their topic, creating all of the outcomes listed above. If they complete their topic, the can choose another one. This continues throughout the day.
- Day 3 is presentation day. Each team should present their completed topics to the assembled group.
Questions
What about partially completed topics? Do we want to do something with them?
Do we want to do some presentations on day 2, in order to give the attendees who didn't work on the topic a change to provide feedback and still give the teams time to incorporate the feedback into their tool?
Possible Scenarios
- Core diagram in support of advisors
- Given a portfolio of initiatives, we need to develop a roadmap, manage the portfolio, and otherwise provide stewardship. We need to demonstrate needed capabilities and dependencies and to promote an architecture favoring user experience driven initiatives. We need to communicate the approach to stakeholders. What tools would support this analysis? What tools would communicate needed aspects best