(insert screen shot of the Adobe Connect list of attendees or type)
Ashish: The API working group report out represents 3 years of work. Ashish comes from a SOA background.
Much of the report out also represents the efforts of migrating to Cloud.
The API work is also about engaging with the business and we have to be careful because some new tools come with headless applications.
Promises with the business are not always easy to keep.
The group is learning what it takes to build a quality API which means alignment with the business which is quite a bit of work.
Why did the group start?
To share best practices, governance and technologies.
Understand governance and organizational aspects
Different than top down and more community driven
Chronological review of Data Modeling
Rupert Berk is hosting a panel on how the APIs fit into the ecosystem in January.
API managers such as PeopleSoft used University of California
University of Michigan:
Enterprise Service Bus
Creating of structure of data stewards and Product managers, service level expectations
Branding of the effort is important due to the many different groups they were working with
Creating a new way of working with the data. Free the Data campaign. Discussed concerns about this term regarding loss of control
Create an outreach effort. The API is an enabler for accessing the data. Changing the culture but still protective of the data
Key to a successful campaign is clarity
Controlling access to the data and creating gating but also creating better access
Under what conditions you are going to access the data
Rupert from the University of Washington talked about an effort going back to 2008 working with the registrar who felt they were getting the access they wanted.
Jim from the University of Wisconsin
Answering business decisions
Concern of data stewards
APIs present a uniform way to get to the data
Get at the data in a more consistent way
Consistency was part of the messaging
Good sharing of the group regarding the person API Definition
University of Waterloo:
Supporting multiple languages
Messaging of opening data
Start with the open data
Academic data starts with a lot of security
Oregon State, Jose Cedeno:
Breaking down the monolith
Overlap between monolith and micro services
complexity due to diversity
Problems solved faster
Example of API was website of database outages
Self Sovereign Identity
Empower the students to manage their learning data
Giving them transcript data.
Cross campus enrollment, blockchain transcript-lack of security, distribute with a key, portable student history, personal transcript, transfer records to different universities or employers
Developer Portal Architecture
Identify the owners and stewards
Define the Business terms, API aligned with technology terms and business terms.
How were the Business Terms defined?
Reaching out to the business to define the business terms. Brad Stone: We used an Iterative approach.
TIER Provisioning/Deprovisioning-UW Madison
LMS-Course interfaces WSYWG but supports infrastructure.
Upcoming for the Working Group:
Survey-about what topics in the future
What is involved in standing up an API program
How should teams be organized
API Documentation Debate
Demos from Itana members
Is there a need for sub-team within Itana regarding cataloging
Collaborative approach to the catalog
Survey Results will be coming
Jim Phelps suggested the working group pull the efforts of the past 3 years into a white paper regarding the state of APIs in higher education which could be an Educause publication.