Name:
Paul Schurr and Rupert Berk
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)
We have a set of home-grown, rest-based apis and software libraries that provide some middleware capabilities. We are in the process of implementing WSO2, including ESB and API Manager. We are supplementing WSO2 with message queuing, and Spring microservices.
Picture of current state and aspirational state?
Current State:
Over the past 7 years we have developed a set of rest-based web services that sit in front of systems in each data domain of the university. The effort was mostly focused on providing read-only apis with high-value data, particularly exposing previously inaccessible mainframe data. This has been a big improvement but the task has been so laborious that we haven't been able to fill out most of the data domains very thoroughly.
Future State:
We are looking for a better developer/consumer experience that will allow us to increase our development velocity. We want it to be easier to explore, consume, and develop useful APIs. We want to provide consistent security, provisioning, documentation, audit logging, and metadata. We want a system that is more easily administered, more supportable, and has better monitoring/auditability.
What are the "poster child" use cases you're using to build momentum for SOA?
We started by providing student data to enable online web grading in 2008. It had a high impact and was well-received by campus. We built out from there.
Do you have low-hanging fruit, or "easy wins" that you can show reasonably quick value with?
Once we developed the SOA framework to support web grading, we were able to build out the student data services and begin to provide HR, Financial, and Person data. These services were used in a variety of integrations and enabled us to move quickly to provide data for a mobile course catalog, photo class lists, and other high-visibility applications.
How do you evolve the culture from file based to real-time based?
We did a big educational outreach to sell the vision to campus, including bringing in a speaker (Pete Lacey) to lead seminars, creating an on-going cross-campus web services discussion group, making presentations to leadership and the community. We also did a lot of hand-holding with campus developers, creating sample code and documentation, helping with application development.
But it's an on-going battle. Even though we've been pushing for 7 years, we are still fairly file-based as an institution.
Do you have design documents that you could share?
Yes. Currently, they are restricted to the UW community but we will look into sharing as much of it as possible.
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?
We worked with stake-holders across campus from each domain that we modeled and engaged in joint resource design sessions. We used a 9-step restful resource design process as described by Ruby and Richardson in RESTful Web Services. The important part of the process is that it was a collaboration with a broad set of stake-holders. The UW is a very consensus-driven organization and we could only make progress by involving lots of people.
We already had a Data Management Committee that had identified data stewards for each domain. We created a Web Services Governance Group to manage objects. We integrated the web services with our existing home-grown authorization system so that data custodians could manage access without developer involvement and the web services would dynamically consume the authorizations.
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?
To take our SOA initiative to the next level, we are taking advantage of a big implementation project at the UW. The UW is replacing our 30 year old mainframe payroll system with Workday and the new system must integrate with many legacy systems. We are using this tactical challenge to further our strategic aims around SOA.
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?
Currently we are running both .Net and Java based web services using home-grown frameworks. We are moving to Java based microservice API approach using the WSO2 middleware stack.
What is behind your API? How do you handle security?
Currently, our APIs front many different systems: legacy unisys mainframe systems, SQL Server/Oracle DBs, 3rd party systems. We have pursued a strategy of providing a layer of abstraction in front of vendor and legacy interfaces and trying to make that layer consistent despite the very different systems underneath.
For our current web apis, Data Custodians use our access management tool to grant appropriate access to consuming applications. Responsibility for ensuring that users access appropriate data is delegated to the consuming applications.
In the future, we hope to be able to rationalize the access management across Web apis and other data delivery channels such as reporting through the Enterprise Data Warehouse. We also are considering opportunities to employ multi-tier authentication such as OAuth2.
Why are doing this? What is your vision? What do you see as the future state?
We want to move to a state where we can apply consistent security and metadata, increase the velocity of web api development, and help insure that users get consistent information regardless of which system they get it from (data warehouse reports, departmental apps, central apps).
What benefits you have achieved in your implementation?
We drastically reduced the number of shadow copies of Student data, financial data, and HR data by providing a way to access the data dynamically when it is needed. This lowered the risk of data breaches, improved the ability of central applications to evolve by reducing tight coupling, and improved the quality of data for users by centralizing some of the interpretation and derivation. We hope to build on this progress in our new project.