Page tree
Skip to end of metadata
Go to start of metadata

Draft Minutes, ITANA call of 29-Aug-2013

Jim Phelps, University of Wisconsin - Madison (chair)
Andrew Gianni, University of Buffalo
Glenn Donaldson, The Ohio State University
Chris Eagle, U. Michigan
Dave Perhne, U. Michigan
Chris Riedel, U. Chicago
Mike Fary, U. Chicago
Joel Banez, Westmont College
Jon Terrones, UW-Madison
Jim Helwig, UW-Madison
Lonnie Smetana, U. of Manitoba
Luca Filipozzi, U. of British Columbia
Mark McCahill, Duke University
Michael Janke, Minnesota State Colleges and Universities
Mojgan Amini, UCSD
Ashish Pandit UCSD
Phil Robinson, Cornell University
Sharif Nijim, Notre Dame
Frank Boshoff, U of Toronto

ITANA Website:



In early August, Jim Phelps shared this on the list:

"I've talked a few times about the Univ. Wisc-Madison Advanced Integration Architecture initiative. wiki site here:
The goal of this service is to run an enterprise level integration service. This includes running the infrastructure (ESB, Web Services / API Registry, Message Oriented Middleware, BPEL orchestration layer, Security / SLA enforcement, etc....), to provide Center of Excellence type services (helping data stewards defined and develop their data and service APIs and services, helping developers consume those services, overall managing the environment and schemas).
It does include SOAP/XML Web Services, REST services, Message Queues and Topics, etc.
Do others have case studies you can share? I'll roll this up and post it to the wiki and share with the list."

Many campuses replied to the list on this topic, leading to today's call to share ideas.

Campus Status on SOA API Work

U. Chicago:
-Coming at this topic from a few directions.
-U. Chicago has adopted Workday as new HR system. Uses ESB technology.
-Trying to create the right environment (including API) to expose university data

U. Michigan:
-Have been working on API management for about 2 years
-First release will focus on exposing public data targeted towards students and mobile development
-Future releases may include a directory of APIs for all the enterprise systems
-Utilize that with Central IT and Department IT
-Goal is to share some of the resources
-Plan for second phase includes using OAUTH2 with WS02

-Looking to replace existing middleware infrastructure
-Have built up a large inventory of web services, being used internally in applications
-Small subset available for external departments' use
-First step is to get a good solution for the public APIs
-Secondly, will also look at secure services, and associated governance
-Looking at new ESB technology
-Have been in discussions with UC Berkeley and UCSF around what they have done with public-facing portal:

U. Wisconsin-Madison:
-Moving from Workday to WS02
-Building the test infrastructure
-Hope to get to business-use-case-driven access requests when granting API keys

-Set up Oracle SOA Suite in production in Jan. 2013
-Went live with Workday HR and Payroll in March 2013
-Would like to do more on data service APIs, and more on the true SOA path
-But have been focusing on integration, especially integrating Workday with other existing systems

U. Toronto:
-Implementing IBM Integration Bus.
-want to move from batch to real-time messaging
-want a balance between tactical approach and strategic approach for services
-bought IBM's webSphere Service registry and repository (a web application to manage the cataloging of available services)
-also establishing a standing committee for management of services, with the faculties and divisions

Ohio State:
-There are services coming out of PeopleSoft (ERP) and other systems (such as residence and dining)
-Much is available via mobile apps
-For ESB, planning to use WS02 (consulted with U. Michigan on this)
-Have been working on education of key stakeholders around process and life cycle

Westmont College:
-Up until about a year ago, there were no APIs
-Now there is capability, but Westmont is a small school, so constrained by lack of staff
-Looking at WS02 and other tools

Duke University:
-Focus on infrastructure for using OAUTH to allow individuals to opt into release of private info to apps.
-There is a token broker for OATH2, hooked up to Shibbloth.

Notre Dame:
-Working towards a campus gateway for APIs
-Like Toronto, evolving from file-based culture to real-teim culture

-Has Peoplesoft ERP for HR and Finance
-Goal is to move from culture of batch processing towards real-time messaging

University of Buffalo:
-Working to get buy-in to formalize efforts around SOA
-Would like to move away from flat files
-Building web services and front-ends to use the web services
-Some challenge getting buy-in for middleware approaches
-Getting traction and buy-in around building API management to support citizen development using public data sources
-In Proof of concept stage now, reviewing open-source solutions
-May be able to use the infrastructure around this to apply to other areas

Potential questions

Broad Questions (you can answer either as current state and/or future state):
Do you have a wiki or web site with a lot of this info? If so, link please.

What API Management Infrastructrure (Middleware) do you have in place or have in place? What are the other core systems? API Management, ESB, ERP , DataIntegration, and Security(Authz/Authn/Access)

Picture of current state and aspirational state?

What are the "poster child" use cases you're using to build momentum for SOA?

Do you have low-hanging fruit, or "easy wins" that you can show reasonably quick value with?

How do you evolve the culture from file based to real-time based?

Do you have design documents that you could share?

How did you build data objects? What kind of governance did you put around the objects? How do you maintain them? How do you put security and authorization around them?

How are you gathering resources - people and funding to support the effort? Where do these resources live? What skills sets do you think you need to support this?

What is the technical stack you are running? Why did you pick that stack? Pros and Cons of the stack. What else did you look at and didn't pick?

What is behind your API? How do you handle security?

Why are doing this? What is your vision? What do you see as the future state?

What benefits you have achieved in your implementation?

Potential Next Steps

-Spin up a working group on the SOA API topic?
-Have an UnConference on the topic?
-Conduct Google Hangouts of campuses presenting their work in the SOA API area?
-Create a video library?

SOA API Start-up Survey

Each campus create a wiki page with their answers to these survey questions.

Later, ITANA may conduct another call to discuss themes that emerge and decide on next steps.

  • No labels