ITANA Conference Call Minutes - April 28, 2011

---------------
Attending
Jim Phelps, University of Wisconsin-Madison (chair)
Jim Behm, University of Michigan
Chris Eagle, University of Michigan
Leo Fernig, University of British Columbia
Scott Fullerton, University of Wisconsin-Madison
Karen Hanson, University of Wisconsin-Madison
Paul Hobson, University of British Columbia
Piet Niederhausen, Georgetown University
Steve Olshansky, Internet2
Renee Shuey, Pennsylvania State University
Eric Taggert, University of California-Irvine
Ann Kitalong-Will, Internet2 (scribe)

---------------
Action Items

(AI) - Jim - will organize a call for the group organizing the F2F at Educause.

(AI) - Matt Kolb, Jim - presenting to CIC forum on survey on status of Enterprise Architecture report.

---------------
Student Lifecycle as a Tool for Managing the Architecture

See: https://spaces.at.internet2.edu/display/itana/Lifecycle+Management+and+Analysis

Work at UBC
(Paul & Leo)

Background: There is a rich and varied landscape supporting student lifecycle at UBC, and they needed information to describe how the systems work together, etc.

Diagram: Useful communication tool; represents the student's education lifecycle and correlates with the different processes that the students interact with over their lifecycle, the process owners, and each system that supports the processes.

Questions for the group:

  • Prospect, applicant, student, alumnus: administratively focus terms; are these terms useful to a college-aged student would use? Does it make more sense to frame capabilities from the perspective of the customer rather than from the perspective of the university? (e.g. "exploration," "enrollment," "learning")

Open Discussion

  • How do you frame a capability that occurs at multiple points or that span across the life cycle - e.g. in year one and in year four?
  • What are the issues students are dealing with? what are their questions? what systems do they need to have access to? (e.g. enrollment costs, housing costs, parking costs)
  • From a customer's perspective, are we making it too hard for them to find answers to their questions?
  • Capabilities vs. roles: it is important to constituents that we are representing an individual going through these stages, and that we are trying to facilitate their needs during a particular stage of the lifecycle.
  • How do we represent the multiple roles an individual can hold? (e.g. as a learner, as an employee); systems become very complicated for the individual as they deal with different systems as an employee vs. as a student, etc.; or individuals who may be at multiple points of the lifecycle at once?
  • Is it important to identify an individual's different roles at once? Does it help to tag one of those affiliations as primary?
  • From a systems perspective, tagging an individual affiliation as primary is not useful; overlaying all the roles a person may hold complicates the graphical representation of the lifecycles, and doesn't necessarily add value to the purpose of the representation as a communication tool.
  • This captures service transition boundaries, as an IdM and access management tool.
  • This is a good way to approach systems design, thinking about capabilities and services that support those capabilities, then designing services as opposed to systems. It can help to address problems with duplication.
  • Maintaining the tools needs to be easy - it isn't sustainable if they require several full-time employees to maintain.
  • Consider connections to portals, IdM, etc.

Penn State Work
(Renee)

Began looking at student lifecycle by putting together a cross-functional committee, resulting in 5 recommendations in the report; primary recommendation was to extend the definition of a student (e.g. suspect, prospect, etc.). To support this, the report recommends:

1. Develop a better understanding of student affiliation, with attributes to support, and to change business processes to support these.
2. Identity assurance profiles.
3. Implement a single point of authentication.
4. Streamlining registration processes.

Goal/challenge: gain buy-in from stakeholders.

---------------
Project Moonshot

Next call will cover Project Moonshot.

---------------
Next Call: Thursday, May 12, 2011
2:00 PM (ET) / 1:00 PM (CT) / noon (MT) / 11:00 AM (PT)

  • No labels