A University API
•Download as PPTX, PDF•
1 like•635 views
Provides 11 principles for designing, deploying, and promoting a University API at your university.
Recommended
More Related Content
Similar to A University API
Similar to A University API (20)
More from Phil Windley
More from Phil Windley (20)
Recently uploaded
Recently uploaded (20)
A University API
- 1. @windley The University API Phillip J. Windley, Ph.D. Brigham Young University http://www.windley.com
- 2. @windley
- 3. @windley
- 4. @windley 4 Software is Eating the World! More and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense. Many of the winners are Silicon Valley-style entrepreneurial technology companies that are invading and overturning established industry structures. Over the next 10 years, I expect many more industries to be disrupted by software, with new world-beating Silicon Valley companies doing the disruption in more cases than not. - Marc Andreessen “ ”
- 5. @windley
- 6. @windley
- 8. @windley
- 9. @windley Googlehttp:/ / facebook.com Web Page Title 1.Lorem ipsum dolor sit amet consectateur nonummy lorenzino. 2.Interdum volgus videt, est ubi peccat. 3.Si veteres ita miratur laudatque poetas 4.Ut nihil anteferat, nihil illis comparet, errat. 5.Si quaedam nimis antique • Alpha • Bravo • Charlie • Delta • Echo • Foxtrot • Golf • Hotel • India • Juliet • Kilo • Lima • Mike • November • Oscar • Papa • Quebec • Romeo • Sierra • Tango • Uniform • Victor • Whiskey • X-Ray • Yankee • Zulu
- 10. @windley Googlehttp:/ / facebook.com Web Page Title 1.Lorem ipsum dolor sit amet consectateur nonummy lorenzino. 2.Interdum volgus videt, est ubi peccat. 3.Si veteres ita miratur laudatque poetas 4.Ut nihil anteferat, nihil illis comparet, errat. 5.Si quaedam nimis antique • Alpha • Bravo • Charlie • Delta • Echo • Foxtrot • Golf • Hotel • India • Juliet • Kilo • Lima • Mike • November • Oscar • Papa • Quebec • Romeo • Sierra • Tango • Uniform • Victor • Whiskey • X-Ray • Yankee • Zulu Carrier 12:00 PM 1. Lorem ipsum dolor sit amet consectateur nonummy lorenzino. 2. Interdum volgus videt, est ubi peccat. 3. Si veteres ita miratur laudatque poetas 4. Ut nihil anteferat, nihil illis comparet, errat. 5. Si quaedam nimis antique API
- 11. @windley API Googlehttp:/ / facebook.com Web Page Title 1.Lorem ipsum dolor sit amet consectateur nonummy lorenzino. 2.Interdum volgus videt, est ubi peccat. 3.Si veteres ita miratur laudatque poetas 4.Ut nihil anteferat, nihil illis comparet, errat. 5.Si quaedam nimis antique • Alpha • Bravo • Charlie • Delta • Echo • Foxtrot • Golf • Hotel • India • Juliet • Kilo • Lima • Mike • November • Oscar • Papa • Quebec • Romeo • Sierra • Tango • Uniform • Victor • Whiskey • X-Ray • Yankee • Zulu Carrier 12:00 PM 1. Lorem ipsum dolor sit amet consectateur nonummy lorenzino. 2. Interdum volgus videt, est ubi peccat. 3. Si veteres ita miratur laudatque poetas 4. Ut nihil anteferat, nihil illis comparet, errat. 5. Si quaedam nimis antique API Carrier 12:00 PM 1. Lorem ipsum dolor sit amet consectateur nonummy lorenzino. 2. Interdum volgus videt, est ubi peccat. 3. Si veteres ita miratur laudatque poetas 4. Ut nihil anteferat, nihil illis comparet, errat. 5. Si quaedam nimis antique
- 12. @windley
- 13. @windley
- 14. @windley
- 15. @windley
- 16. @windley 16 Bake your business model into your API - John Musser Founder, Programmable Web “ ” Principle #1: Design Business-Oriented APIs
- 17. @windley
- 19. @windley
- 20. @windley Principle #2: Ensure interfaces are open, extensible, and published
- 21. @windley GET /students GET /students?major=CS GET /students/:id GET /students/:id?fieldset=transcripts
- 22. @windley POST /students {id: ... first_name: ... last_name: ... ... }
- 23. @windley
- 24. @windley Principle #3: Support student and faculty choice.
- 25. @windley
- 26. @windley
- 27. @windley Principle #4: Access Control Happens at the API
- 28. @windley User Policy Administrator PEP PDP PAP Enforce Policy Enforcement Point Decide Policy Decision Point Manage Policy Administration Point
- 29. @windley
- 30. @windley
- 31. @windley Authorization Server Owner Client 5. code TOKEN 4. code 2. redirect 1. use 3. authorize 6. data request TOKEN Resource Server Client
- 32. @windley
- 33. @windley Principle #5: Keep workflow below the API
- 34. @windley
- 35. @windley
- 36. @windley HATEOAS Hypertext as the Engine of Application State
- 37. @windley An ever expanding range of computing platforms are needed to reach students
- 38. @windleySource: Morgan Stanley Mobile Internet Report (12/09)
- 39. @windley Hundreds, even thousands of developers who don’t work for you must be convinced to adapt your product to the dynamic environment of various apps
- 40. @windley
- 41. @windley
- 42. @windley Principle #7: Cloud First
- 43. @windley
- 44. @windley Principle #8: Security is Too Important to Not Outsource
- 45. @windley
- 46. @windley
- 47. @windley Principle #9: Focus on What’s Core
- 48. @windley
- 49. @windley Principle #10: APIs First
- 50. @windley API Client API Manager / ESB / etc. Service Composition Throttling Attribute Based Access Control Authentication Authorization Address Abstraction Monitoring Policy Enforcement Data Transformation Protocol Transformation CFramework PeopleSoft Alfresco BusinessObjects ServiceNow CustomServices Java,PHP,etc. OtherCampusContributors (Library,Bookstore,etc) Domain APIs SOAP XML RPC SOAPSOAPXML RPC REST REST Domains University API (REST)
- 51. @windley
- 52. @windley Principle #11: Start Where You Are
- 53. @windley
- 54. @windley Principles for Starting an API Initiative 1. Design business-oriented APIs 2. Ensure interfaces are open, extensible, and published 3. Support student and faculty choice. 4. Control access at the API 5. Keep workflow below the API 6. Make developers the customer 7. Be cloud first 8. Security is too important to not outsource 9. Focus on what’s core 10. Buy and build API first 11. Start where you are
- 55. @windley Resources • Mashup Corporations’ • The Phoenix Project • Implementing Domain Driven Design • Kin Lane on University APIs • windley.com
- 56. @windley Join us on this journey • @UniversityAPI • University API Workshops • Utah, Feb 28-Mar 1, 2017 (http://bit.ly/UAPI2017) • Chicago Summer 2017
- 57. @windley The University API Phillip J. Windley, Ph.D. Brigham Young University http://www.windley.com
- 59. @windley Other issues • Other university APIs: services like lockers, vending machines, health, payments, HR, calendars, assets, library, collections
Editor's Notes
- Story of Lego: Lego started in 1906. In 1958, Godtfred Christiansen, son of the founder, invented the now iconic "stud-and-tube" system that holds Lego blocks together. A patent was issued and Lego as we know it was born. In the 60’s and 70’s the product line was expanded to include block-like people called minifigs and assorted accoutrements The result was a 15-year stretch during which the company doubled in size every five years. Revenues grew from $142 million in 1978 to more than $1.2 billion in 1993 Lego diversified with multiple products, many of which didn’t work with each other or the classic parts In 2003, the company was near bankruptcy. Lego retrenched, getting a new CEO and focused on its core parts, expanding the usefulness of it’s tube and stud design. The result is a rejuvenated Lego with soaring profits and popularity We’ll come back to this story several times today. Source: http://www.thelegocasestudy.com/uploads/1/9/9/5/19956653/lego_case_study_2014.pdf Image source: http://www.wired.co.uk/magazine/archive/2013/10/features/building-success
- The good old days: University IT systems used to be simple, and confined to a few special activities But that’s not true anymore. Here’s why…
- Marc Andreessen, invented Web browser, now runs one of the biggest VC firms in the US Software is eating the world. Why? All necessary software and services can be delivered at global scale 2 Billion people on Internet Cloud makes it easy to launch global software-powered startups Most dramatic example is Amazon killing Borders, but Netflix, iTunes, Uber, AirBnB, photography, skype, LinkedIn, WalMart, FedEx
- This is certainly true of University systems. Software is eating the University. More and more of the student experience is mediated by software Applications Financial aid Student information systems Learning management systems But we give our students this when they’re used to this (transition)
- And it’s more than mobile. Future IT systems will also need to use voice-mediated interfaces like Siri and Alexa. The IoT will put even more demands as the number of devices students and faculty bring to campus, and expect to interoperate with University systems explodes. Most universities: build crappy software using outdated techniques buy crappy software integrate it poorly The result is a software-mediated student experience that is far from ideal. On top of this, we spend a LOT of money.
- The answer to this challenge is an API. The API isn’t the only thing, but it’s the central thing. Building a University API will force other necessary changes.
- Lego analogy: Standard parts Standard interfaces Consistent No user manual; they have their own language Virtually infinite combinations that enable creativity and innovation A decided contrast to most software systems. In or out of the University
- You many be asking “What is an API?” APIs are like Legos for IT systems. APIs are specifications or protocols for how to exchange information or request online services from an organization. In the old days, a company like Facebook would create their backend infrastructure That infrastructure would generate the Web pages
- Then along came mobile. Mobile apps didn’t work the same way. They needed direct access to the business logic of the system. APIs, or “application programming interfaces” give the Web app and the mobile app access to the information and processes they need. The applications (whether Web, mobile, Alexa, IFTTT, etc.) are responsible for creating the user interface.
- What’s even better, other applications, not owned by Facebook, can get permission to access parts of Facebook’s infrastructure and create their own services on top of the API.
- Familiar players: Netflix, Facebook, Google Maps, Salesforce [click] Also: EdTech players like Instructure and Kuali.
- One of the big advantages of APIs is that they enables other applications to complement your offerings. Walgreens Story: “Walgreens recently opened its photo printing and pharmacies to the outside world through APIs. Large numbers of developers responded, and some offered immensely popular applications such as Printicular from MEA Labs, which allows users to print photos at Walgreens from either their phones or their accounts with Facebook, Instagram, or Dropbox. Riding on the inputs of such third-party developers and their popular applications, Walgreens enhanced overall customer engagement with its retail stores. In fact, its revenues per customer for people who interacted with it in its stores and via the web and mobile devices were six times those generated by people who just shopped at its stores.” The Strategic Value of APIs by Bala Iyer & Mohan Subramaniam (https://hbr.org/2015/01/the-strategic-value-of-apis) This isn’t just about business.
- Universities want more engagement with potential students, students, faculty, staff, and alumni. That means more digital systems. Situation at BYU: 30,000 students 950 services in the registry 5 different identifiers (at least) home grown SIS Our goal is to never do a fork-lift upgrade to the SIS. We’re replacing our SIS in pieces. Incremental, small-scale, (even daily) updates to the system. API decouples the user experience from underlying systems We can change underlying systems without upsetting the student experience We change the student experience without modifying underlying systems. This is how we put class add/drop in our mobile app. The API reduced friction and allowed the mobile team to work independent of the underlying systems
- Because software is eating the world, University IT systems, like Legos in the 80’s and 90’s sometimes seem to have lost their roots. Our IT systems are disconnected from the reality of the university’s business In BYU’s case our 950 services were mostly just stovepipes off whatever system enabled them. They were inconsistent, didn’t necessarily relate to the University’s way of doing business.
- So we come to the first principle. APIs should reflect the business of the university. To see how that works, let’s dive into a University API Image source: https://farm8.staticflickr.com/7231/7277168160_83ff0509f8_b.jpg
- The fundamental concept in an API is a resource. Resources have Types Data Relationships with other resources Resources are grouped in collections Resources exist independently or can be contained within another resource
- Top level resources are the primary subjects of the API They are understandable in the context of the University’s business. Tell story of Lori Gardener, Asst Directory of Admissions at BYU (not experienced with APIs, but could understand the API for admissions)
- But!!!! Programming and Extending Our Current Systems is Hard An API overcomes one of the big problems with creating great student experiences in a software-mediated world. We have 950 services in the service registry and multiple IDs Touching a student in a mobile app might require several dozen different services, multiple ID formats, multiple error formats, multiple result encodings. This limits the ability to add new features, even when the API and service exists. Mobile app dealing with students might have a dozen or more different services, several Ids, multiple error codes and return formats. This makes developer’s job really hard. This ensures campus developers won’t do much integration except where they have to.
- Take time to deliver an API that describes the University’s business. APIs are long-lived. They are notations, not technologies. BYU has had /instructors teaching /classes to /students in /classrooms for over 140 years. In 25 years, we’ll likely still have /instructors teaching /classes to /students in /classrooms The API should be complete, consistent, and obvious.
- For example, every top-level resource is plural. We don’t have /students and /class And they behave consistently. GETting the /students resource returns a collections of students…all of them...properly paginated, of course. This is true for any top-level resource. Query parameters limit the scope GETting the /students resource with an :id returns the information about the identified student. What information? All of it in theory. In practice it has to be grouped for both convenience and to support authorized access. Again, this is true for any top-level resource.
- For completeness, other HTTP methods work on the same top-level resources. For example this creates a new student record. Top level resources are the primary subjects of the API Note that the existence of an API doesn’t imply everyone has access to everything. We’ll get to that in a minute.
- But!!!! We can't keep up with demand for interfaces, mobile apps, etc. And if we allow others to create special purpose apps using our underlying systems, these apps will undoubtedly have a different look and feel from University-developed apps Student and faculty experience suffers They might not be well integrated with other university applications and functionality. Tell story of planning being disconnected from registration Embrace disconnected experiences. Image source: http://www.city-data.com/forum/seattle-area/2352951-do-seattle-natives-really-hate-california-4.html
- Talk about our LMS strategy Faculty already using multiple LMSs Integrate any LMS a faculty member wants to use Don’t be afraid of deconstructed experiences. Your students aren’t. Use Facebook as an example: FB, Messenger, Moments, etc. Expect Shopping soon. Students are used to this. Expect it, even. The key is to give them ways to reconstruct the parts that matter to them. In the case of LMS this means providing them with a common calendar and notification system. Support multiple options so that students can reconstruct the experience in a way that works for them. Look at the tools students use and find ways to integrate them into the overall tool flow. That allows students to create a personal learning environment that is suited to how they learn.
- To understand why choice is so important, you have to understand that standards, like a University API, also accelerate the rate of innovation. Standardized architectural building blocks like bricks, dimensional lumber, pipes, and so on have led to a faster rate of house building and a wider diversity of housing types and shapes. This is the same with electronics and other modular systems. APIs don’t stop change, but they reduce friction by providing a boundary below and above which change can take place. A University API will lead to greater diversity and specialization in the applications students and faculty use. It will also enable innovation below the API since changes can be made to underlying architectures without the drag that having to change all the apps along with it entails. Think about electrical power standards. We don’t have to all buy new electronic gadgets because the power company decides to switch from coal power generation to wind turbines. The changes above and below the API are isolated from each other by the abstraction. Image Source: https://images.lowesforpros.com/img/i/articles/le38I_A2LEqLFQgivM-zYg.png
- FERPA!! But!!!! Controlling who has access to what is hard. We’re failing
- This may not always be possible, but it is in most cases. The goal is flexible and consistent application of access policies Image source: https://en.wikipedia.org/wiki/Toll_road#/media/File:New_Jersey_Turnpike_toll_gate.jpg
- The tool we use to accomplish that is known as Attribute-Bases Access Control. ABAC combined with an API enables policy objects to directly control access Data stewards have more confidence policies are correctly applied Programmers are saved from having to interpret policy in a set of loosely-connected implementation details. API’s with the use of ABAC can actually provide more controls by allowing data stewards to not only define “who” can access information or services, but also the “what, where, when and how.” This couples with our information governance process. Diagram adapted from Axiomatic
- Tell the story of students building an alternative class registration system Building good student experiences is hard There’s always too much work to do. How can we let other people build apps that use our systems and are also secure? Image source: http://www.fastcompany.com/3029885/why-you-should-probably-host-a-hackathon
- You’ve probably all used or at least seen Facebook login (or something similar from Google or Twitter) All these are based on Oauth, an identity protocol that allows people to authorize an application access to their data on another site. Sometimes we call this “Alice to Alice sharing” since the student is sharing her data that exists in one place with herself in another application she wants to use.
- An API Enables Others to help APIs provide authorization schemes that allow students to authorize apps built by outsiders to work with the API. Oauth works by letting an authorization server, under the user’s control, to control access. Clients use the token they’ve been given to access resources on the user’s behalf. You might be thinking “that’s OK for Facebook but we care about student privacy”. That’s a naïve view. Facebook is not nearly as cavalier about personal data as you might think and Oauth is widely used by apps. It’s the foundation of much of the Mobile app economy. You can comply with FERPA and allow people to develop apps against your API at the same time.
- Users authorizing access to their data sounds good, but that’s not enough. For example, consider Adding and Dropping classes. I might trust BYU’s app, but can I trust third party applications to add and drop classes? Will they enforce the right pre-requisite checking, for example? In other words, what if the app does something that’s not allowed?
- Workflow is the business rules and logic that determine what can be done. Workflow is process. Putting workflow below the API ensures that other applicstions will then only be able to use base data within the proper, approved process APIs expose services, not data This means some requests will fail. What do we do about that? Image source: https://en.wikipedia.org/wiki/Production_line
- Think about this problem in terms of what we already do on a Web page. Let’s look at a class registration system. Imagine that the student clicks on the Proceed button, but doesn’t have the pre-requisite for Math 106. The system would provide a page that indicated the problem (failure).
- A well-designed system would give the student a way to recover from the problem by, perhaps offering to add the prerequisite and remove the course that couldn’t be added. A well-designed API can do the same thing for clients using the API. There’s an ugly word for this.
- HATEOAS is the way APIs accomplish what Web pages have been doing for several decades now: manage workflow.
- There are several natural consequences of software eating the university: Students and faculty attention is fragmented. Students and faculty are becoming more specialized This is a natural, and good, consequence of choice And one we can’t avoid.
- Each New Computing Cycle = 10x > Installed Base than Previous Cycle The integration requirements are staggering You can’t win this game in the traditional way. We have to change the game
- Here’s how to change the game… If software is eating the world, why are you telling developers you hate them? You are in a competition for ideas. Developer attention is in short supply and yet we offer Bad or no interfaces Off-putting security regimes Poor support If we offer anything at all. Our universities must adapt to niches. Adapted from Darwin's Finches, 20th Century Business, and APIs
- Developers are the lifeblood of innovation. Developers can give you new services and new solutions on an almost daily basis. Developers might work for you, somewhere else at the University, for a vendor, or for themselves. Make developers happy with good tooling, consistent interfaces, understandable/reasonable access policies, self-service When developers succeed with your API, you succeed. Image source: https://www.flickr.com/photos/polarity/7000068730
- Do you ever feel like your drowning in demands for new products and services? Even if developers help build out clients, just building the infrastructure necessary to fully support university business and keep up with new demands from administrators, students, faculty, and regulators will tax IT resources that are already stretched thin. Trying to build all the software that is needed to meet student and faculty demands can tax the ability of even well-funded technology shops. Image source: https://www.youtube.com/watch?v=Cx01ZZVBqsI
- Using cloud-based resources allows developers to use the right tool for the job without expensive and long set-up times, fractured infrastructure, and costly maintenance. For example, it’s not uncommon for an application to need several different databases to succeed, say a NoSQL database for scalable, high-availability operations and a relational database for analytics and administration. In the past, we’d have stuffed everything in one or the other cause expense. Now, with cloud, I can rent both, someone else runs them, and developers are off to the races. Plus as more of your teaching goes online, the Cloud gives you the ability to scale and meet your customers (students) where ever they are. Image source: https://commons.wikimedia.org/wiki/File:Lenticular_cloud_over_Mount_Hood.jpg
- But!!!! The cloud is scary
- Amazon has more people working on security than you have people. Maybe many more. You can’t keep up with all the threats. Amazon and others stand a better chance. If Netflix can trust its entire business to Amazon you likely can too. Amazon and other cloud vendors are FERPA certified. You might have people question the safety, legality, or wisdom of storing University (student) data in the cloud. They’re wrong. There are ways around all those problems. Image source: http://www.triadprotectiongroup.com/assets/Fotolia-61379106-X-c-r.jpg
- A University API is a boon to security because it provides a single point of control for sensitive information (without being a single point of failure). The API, combined with proper attribute-based access control can provide consistent control for how that data is exposed and used. Without an API and access control at the API, security is at the mercy of ad hoc processes, connections, and policies. You might forget who has access and why. ABAC on yourAPI provides one place to check what policy allows. ensures policy is applied consistently provides a single point of control without a single point of failure Image source: http://video.nationalgeographic.com/video/ng-live/mcbride-colorado-lecture-nglive
- But!!!! All this sounds good, but we can’t stop talking about the financial and HR system, identity and directories, networks, the datacenter, etc. We can’t focus on APIs. Remember Lego? They had a similar problem. They were defocused and not getting creative synergy from their products. Like Lego of the 2000’s, there are many distractions and we can spend our energy on things that aren’t core.
- How do you focus on the core? Outsource everything else. We are big believers in the tenets of Domain-Driven Design. Determine what is core. Focus on that. Core means it’s central to what you do as a business—what differentiates you. For a university, that’s the things in the University API. Things like your payroll system are important, but you’re not going to succeed or fail based on how you pay people. You can’t succeed with a University API so long as your focus is on non-core IT systems. Outsource as much of this as you can. Limit changes to non-core systems Talk about PeopleSoft at BYU – required VP-level intervention by both CIO and CFO. Focusing on what’s core includes bringing domain experts into design process. Admissions process Non-technical people can understand the representations of the API (if designed right) and how they map to the business concepts Image source: http://blog.sigmaphoto.com/2014/understanding-aperture-and-f-stop/
- Our systems don't have APIs Ours at BYU didn’t either—at first. Now almost everything does. Image source: http://skagitvalleybeekeepers.org/101/8.html
- Related, ensure that every product you buy and every vendor you use understands that you are an API-first shop. Don’t buy anything that doesn’t provide an API. Don’t build anything that doesn’t have an API. Build abstraction layer (shim) to connect product APIs to the University API. Our analytics show BYU’s APIs are being used more than Web pages driven by mobile and system-to-system access We have a special pot of money we can allocate to approved projects to enable API access/build-out Image source: Phillip J. Windley
- API Management Tooling Is Important Provide an API to external organizations, internal teams, or both. Avoid the hassle and constant maintenance of building a solution from scratch. API managers support Access control Documentation (active) Consistency Rate limiting Analytics Versioning Billing/payments Developer portal We looked for could run on prem Could also in the cloud was extensible and pluggable. suite integration - Identity Server for OAuth support and federation with our CAS environment. Open source Image source: http://www.3scale.net/api-management/
- This Seems Daunting or overwhelming There are so many pieces to get in place. So many things to change. People Ideas Budget Processes Image source: http://www.greekmythology.com/pictures/myths/Sisyphus/189291/sisyphus/
- Define the API and build towards it from both sides, piece by piece (e.g. Add/Drop) Start by designing the API itself. Lots of resources. Even if nothing is connected. Then connect things to it a bit at a time. This will bring big wins. You can clean up the connections later. But, you need commitment from the top or overwhelming grassroots support to not go off the rails. Image source: https://www.flickr.com/photos/galego/3491764744
- Imagine your University with a bright shiny API, lots of developers clamoring to use it, data secure, processes followed, mobile apps humming. Make a commitment to the API. Because it’s a long-lived artifact, take time to design it right. Take time to grow it. You have time. Image source: http://suabroad.syr.edu/exchange-programs/
- Here are the principles all in one place. This list isn’t exhaustive, but it’s a good start. This isn’t easy, but it’s doable. Follow the principles. Take an incremental approach. (tell story of UAPI committee…it became their idea) Create the right incentives (measure what’s important to you) Analytics showed access to API more than Web after short time. Use existing projects to drive the development of the API. Include parts of it in every project.
- Kin has a good collection of strategies for getting started And of course, my blog
- Thanks for listening. Questions?