Draft Mintues: ITANA call of 21-Nov-2013

Attending

Jim Phelps, University of Wisconsin - Madison (chair)
Mojgan Amini, UC San Diego
Glenn Donaldson, The Ohio State University
Chris Eagle, U. Michigan
Leo Fernig, University of British Columbia
Andrew Gianni, University of Buffalo
Michael Janke, Minnesota State Colleges and Universities
Ashish Pandit, UC San Diego
Brenda Reeb, University of Rochester
Tamer Sakr, UC Berkeley
Brian Savage, Boston College
Rich Stevenson, University of Maryland

*********
Links:
ITANA Website: http://itana.org/
ITANA Wiki: https://spaces.at.internet2.edu/display/itana/Home
*********

DISCUSSION

Starting an Enterprise Architecture Practice Working Group

Attendees at the ITANA F2F and Unconference were interested in the "new to enterprise architecture" intiative. If you are interested in helping with this working group, please contact Colleen Nagy; see the working group site for more information.

Reference Architecture for Teaching and Learning

The working group has updated its Teaching and Learning Capability Map. Leo and Rich presented the following changes, which were based on feedback from Jack Seuss at UMBC and Colin Smythe at IMS.

• In the Instructional Design area, the term Learning Component has replaced Learning Object, to express that they may not be passive/static objects but can be live components that people interact with.
• In the Teaching area, the term Scaffolding has replaced terms like "syllabus" or "course outline", to more generally express things instructors do to plan a learning experience such as a course.
• In the Supporting Capabilities, Collaboration and Communication was added and Compliance was moved from the Core Capabilities.
• Jack and Colin suggested that it would be useful to pivot the capability map on certain Supporting Capabilities such as Identity Management and Data Analytics, to see how these play out across the other capabilities on the map.

The working group is considering developing a maturity model for evaluating teaching and learning. This would be a little different from past ITANA activities in that it would represent a resources to be maintained by ITANA long term.

• We will refer to existing maturity models like CMMI, particularly for Supporting Capabilities.
• If you've done maturity modeling at your institution for the Core Capabilities, we'd welcome your input.
• The group welcomes references to existing maturity models outside IT for thinks like teaching and instructional design.
• Chris: Without going too far into the various business domains, the maturity model could certainly start with a way to assess supporting technologies for each capability.

The working group is looking for feedback on how much detail to include in Supporting Capabilities, which could extend to more areas of operations than shown on the map currently. For example, Data Analytics is included because it cuts across many Core Capabilities and is a current area of interest for evaluating the effectiveness of higher education initiatives.

• Brian: The RATL could include common API definitions as a reference. For example, common semantics in an area such as Portfolio Management.
• Leo: For example, in the Assessment capability, the RATL could connect up with the IMS Calibre project for an API standard. Similarly, in the Instructional Design area for standards around reusable Learning Components.
• Rich: The standards referred to in the RATL don't have to be higher-education specific, for example SAML.

Leo: The capability mapping work could be extended to the whole higher education enterprise, covering research and outreach as well as the current teaching and learning capabilities.

Rich: IMS is interested in having ITANA present the capability map at an event in May. This would be a great opportunity to get input from a wider audience.

Transitioning from database connections to APIs

Tamer at UCSD provided this overview of the topic prior to the call:

We are planning the transition of many downstream systems from direct DB connection to APIs. Current analysis and systems inventory uncovered a wide variety/spectrum of capabilities. A smaller subset of those systems are capable of invoking an API, others will need a transition plan in the form of an SDK, API client or other solutions. The transition will also include honoring exiting data release policy, so the authorization layer will also need to be implemented and well thought out as part of the transition plan. What are others doing in similar situations? Any recommendations would be greatly approciated.

Specifically, for HR data UCSD plans to transition many downstream data from direct database connections to the ODS to an API approach. Regarding legacy systems, should software be developed, such as an SDK or API clients for legacy systems, or some other approach?

• Leo: UBC is going through a similar process related to student systems. UBC has seen several API projects fail in the long term. Underlying business and governance issues need to be addressed, regardless of the value of the technical solution. Also, master data management is a necessary foundation for knowing what is the canonical source for different kinds of data. (This could include the data warehouse as a canonical source of slowly changing dimensions.)
• Tamer: UC's HR system replacement project unified the schema for HR, which can serve as a canonical data model for the API. Further challenges will include honoring existing data access policies in authorization in the API, creating a metadata repository to support the SOA strategy, and the actual implementation of the API in legacy systems, working with developers in many different systems.
• Leo: When centralized authentication was first rolled out at UBC, initially it required a client download, which turned out to be infeasible to support because of the variety of platforms in use. In the long run, what was feasible was a simplified solution that essentially only required HTTP to work.
• Jim: UW-Madison rolled out web services for curricular data, and documented how to consume them in .NET, PHP, and Java, with toolkits (which could include SDKs, plugins, or modules, and could be developed outside central IT and shared as a community source project).
  • Critical areas were targeted for early implementation, with 27 different consumers at this point. Those that remain with direct database connections may be charged maintenance costs until they are forced to move.
  • Owners of client systems were at the table from the beginning to create the data standards and integration solutions and prioritize issues. The initiative also educated the community about the complexity of an enterprise services effort by involving them.
  • In terms of governance, the data steward (Registrar) led the initiative and owns the process of managing access to the API and guiding expansion of the operational data store, steering new users toward the API.
  • Authorization is required to access the API, and a second level within the API to select authorized data elements and records. This is implemented in custom code.

Tamer will share progress on this project in a future call.

Next ITANA call: Thursday, November 21, at 1pm-2pm Eastern Standard Time