SlideShare a Scribd company logo
1 of 59
@windley
The University API
Phillip J. Windley, Ph.D.
Brigham Young University
http://www.windley.com
@windley
@windley
@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
“
”
@windley
@windley
@windley
{“answer”: “University API”}
@windley
@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
@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
@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
@windley
@windley
@windley
@windley
@windley 16
Bake your business model
into your API
- John Musser
Founder, Programmable Web
“
”
Principle #1: Design Business-Oriented APIs
@windley
@windley
/students
/instructors
/courses
/classes
/locations
/programs
/colleges
/departments
@windley
@windley
Principle #2: Ensure interfaces are open,
extensible, and published
@windley
GET /students
GET /students?major=CS
GET /students/:id
GET /students/:id?fieldset=transcripts
@windley
POST /students
{id: ...
first_name: ...
last_name: ...
...
}
@windley
@windley
Principle #3:
Support student and faculty choice.
@windley
@windley
@windley
Principle #4: Access Control Happens at the API
@windley
User
Policy
Administrator
PEP
PDP
PAP
Enforce
Policy Enforcement Point
Decide
Policy Decision Point
Manage
Policy Administration Point
@windley
@windley
@windley
Authorization
Server
Owner
Client
5. code
TOKEN
4. code
2. redirect
1. use
3. authorize
6.
data
request
TOKEN
Resource
Server
Client
@windley
@windley
Principle #5:
Keep workflow
below the API
@windley
@windley
@windley
HATEOAS
Hypertext as the Engine of Application State
@windley
An ever expanding range of
computing platforms are needed
to reach students
@windleySource: Morgan Stanley Mobile Internet Report (12/09)
@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
@windley
@windley
@windley
Principle #7: Cloud First
@windley
@windley
Principle #8:
Security is Too Important to Not Outsource
@windley
@windley
@windley
Principle #9: Focus on What’s Core
@windley
@windley
Principle #10: APIs First
@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)
@windley
@windley
Principle #11:
Start Where You Are
@windley
@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
@windley
Resources
• Mashup Corporations’
• The Phoenix Project
• Implementing Domain Driven Design
• Kin Lane on University APIs
• windley.com
@windley
Join us on this journey
• @UniversityAPI
• University API Workshops
• Utah, Feb 28-Mar 1, 2017 (http://bit.ly/UAPI2017)
• Chicago Summer 2017
@windley
The University API
Phillip J. Windley, Ph.D.
Brigham Young University
http://www.windley.com
@windley
Other issues
• Other university APIs: services like lockers, vending machines, health,
payments, HR, calendars, assets, library, collections

More Related Content

Similar to A University API

Hampton's 6 Rules of Mobile Design
Hampton's 6 Rules of Mobile DesignHampton's 6 Rules of Mobile Design
Hampton's 6 Rules of Mobile Design
Hampton Catlin
 
API's - Successes to Replicate. Pitfalls to Avoid.
API's - Successes to Replicate. Pitfalls to Avoid.API's - Successes to Replicate. Pitfalls to Avoid.
API's - Successes to Replicate. Pitfalls to Avoid.
Inman News
 

Similar to A University API (20)

(java2days) The Anatomy of Java Vulnerabilities
(java2days) The Anatomy of Java Vulnerabilities(java2days) The Anatomy of Java Vulnerabilities
(java2days) The Anatomy of Java Vulnerabilities
 
Anatomy of Java Vulnerabilities - NLJug 2018
Anatomy of Java Vulnerabilities - NLJug 2018Anatomy of Java Vulnerabilities - NLJug 2018
Anatomy of Java Vulnerabilities - NLJug 2018
 
Of innovation and impatience - Future Decoded 2015
Of innovation and impatience - Future Decoded 2015Of innovation and impatience - Future Decoded 2015
Of innovation and impatience - Future Decoded 2015
 
OpenAPI at Scale
OpenAPI at ScaleOpenAPI at Scale
OpenAPI at Scale
 
7 things one should learn from iOS
7 things one should learn from iOS7 things one should learn from iOS
7 things one should learn from iOS
 
Cybercrime and the developer 2021 style
Cybercrime and the developer 2021 styleCybercrime and the developer 2021 style
Cybercrime and the developer 2021 style
 
A new hope for 2023? What developers must learn next
A new hope for 2023? What developers must learn nextA new hope for 2023? What developers must learn next
A new hope for 2023? What developers must learn next
 
SoundCloud API Do:s and Don't:s
SoundCloud API Do:s and Don't:sSoundCloud API Do:s and Don't:s
SoundCloud API Do:s and Don't:s
 
GIDS-2023 A New Hope for 2023? What Developers Must Learn Next
GIDS-2023 A New Hope for 2023? What Developers Must Learn NextGIDS-2023 A New Hope for 2023? What Developers Must Learn Next
GIDS-2023 A New Hope for 2023? What Developers Must Learn Next
 
Flask First-Timer
Flask First-TimerFlask First-Timer
Flask First-Timer
 
061203_futurewebapps_tempo
061203_futurewebapps_tempo061203_futurewebapps_tempo
061203_futurewebapps_tempo
 
Mobile Web vs. Native Apps | Design4Mobile
Mobile Web vs. Native Apps | Design4MobileMobile Web vs. Native Apps | Design4Mobile
Mobile Web vs. Native Apps | Design4Mobile
 
Hampton's 6 Rules of Mobile Design
Hampton's 6 Rules of Mobile DesignHampton's 6 Rules of Mobile Design
Hampton's 6 Rules of Mobile Design
 
Awesome application in 2014
Awesome application in 2014Awesome application in 2014
Awesome application in 2014
 
Eight Reasons Why the Internet of Things Is Doomed
Eight Reasons Why the Internet of Things Is DoomedEight Reasons Why the Internet of Things Is Doomed
Eight Reasons Why the Internet of Things Is Doomed
 
Kimberley-Go: Apps, social media & augmented reality
Kimberley-Go: Apps, social media & augmented realityKimberley-Go: Apps, social media & augmented reality
Kimberley-Go: Apps, social media & augmented reality
 
Javascript State of the Union 2015 - English
Javascript State of the Union 2015 - EnglishJavascript State of the Union 2015 - English
Javascript State of the Union 2015 - English
 
The Future of eLearning
The Future of eLearningThe Future of eLearning
The Future of eLearning
 
API's - Successes to Replicate. Pitfalls to Avoid.
API's - Successes to Replicate. Pitfalls to Avoid.API's - Successes to Replicate. Pitfalls to Avoid.
API's - Successes to Replicate. Pitfalls to Avoid.
 
Goto Berlin - Migrating to Microservices (Fast Delivery)
Goto Berlin - Migrating to Microservices (Fast Delivery)Goto Berlin - Migrating to Microservices (Fast Delivery)
Goto Berlin - Migrating to Microservices (Fast Delivery)
 

More from Phil Windley

Introducing Personal Event Networks
Introducing Personal Event NetworksIntroducing Personal Event Networks
Introducing Personal Event Networks
Phil Windley
 
Using Apache as an Application Server
Using Apache as an Application ServerUsing Apache as an Application Server
Using Apache as an Application Server
Phil Windley
 

More from Phil Windley (20)

Trust, Blockchains, and Self-Soveriegn Identity
Trust, Blockchains, and Self-Soveriegn IdentityTrust, Blockchains, and Self-Soveriegn Identity
Trust, Blockchains, and Self-Soveriegn Identity
 
Events, Picos, and Microservices
Events, Picos, and MicroservicesEvents, Picos, and Microservices
Events, Picos, and Microservices
 
Picos, CloudOS, and Connecting Things
Picos, CloudOS, and Connecting ThingsPicos, CloudOS, and Connecting Things
Picos, CloudOS, and Connecting Things
 
Events, Picos, and Microservices
Events, Picos, and MicroservicesEvents, Picos, and Microservices
Events, Picos, and Microservices
 
Relationships: Modeling the Vehicle Ecosystem with Fuse
Relationships: Modeling the Vehicle Ecosystem with FuseRelationships: Modeling the Vehicle Ecosystem with Fuse
Relationships: Modeling the Vehicle Ecosystem with Fuse
 
Fuse 2
Fuse 2Fuse 2
Fuse 2
 
Connecting Things
Connecting ThingsConnecting Things
Connecting Things
 
Persistent Compute Objects and the Fabric of Cyberspace
Persistent Compute Objects and the Fabric of CyberspacePersistent Compute Objects and the Fabric of Cyberspace
Persistent Compute Objects and the Fabric of Cyberspace
 
Persistent Compute Objects - Picos
Persistent Compute Objects - PicosPersistent Compute Objects - Picos
Persistent Compute Objects - Picos
 
Fuse Technical Presentation
Fuse Technical PresentationFuse Technical Presentation
Fuse Technical Presentation
 
Personal Cloud Application Architectures
Personal Cloud Application ArchitecturesPersonal Cloud Application Architectures
Personal Cloud Application Architectures
 
Why Personal Clouds
Why Personal CloudsWhy Personal Clouds
Why Personal Clouds
 
Personal Cloud Operating Systems
Personal Cloud Operating SystemsPersonal Cloud Operating Systems
Personal Cloud Operating Systems
 
Introducing Personal Event Networks
Introducing Personal Event NetworksIntroducing Personal Event Networks
Introducing Personal Event Networks
 
The Live Web #SCITDA11 Keynote
The Live Web #SCITDA11 KeynoteThe Live Web #SCITDA11 Keynote
The Live Web #SCITDA11 Keynote
 
Shaping strategies and Startups
Shaping strategies and StartupsShaping strategies and Startups
Shaping strategies and Startups
 
Shaping Strategies and the Live Web - Kynetx Impact 2011
Shaping Strategies and the Live Web - Kynetx Impact 2011Shaping Strategies and the Live Web - Kynetx Impact 2011
Shaping Strategies and the Live Web - Kynetx Impact 2011
 
The Evented Web Makes Users Happy
The Evented Web Makes Users HappyThe Evented Web Makes Users Happy
The Evented Web Makes Users Happy
 
Using Puppet and Cobbler to Automate Your Infrastructure
Using Puppet and Cobbler to Automate Your InfrastructureUsing Puppet and Cobbler to Automate Your Infrastructure
Using Puppet and Cobbler to Automate Your Infrastructure
 
Using Apache as an Application Server
Using Apache as an Application ServerUsing Apache as an Application Server
Using Apache as an Application Server
 

Recently uploaded

Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...
Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...
Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...
EADTU
 
Contoh Aksi Nyata Refleksi Diri ( NUR ).pdf
Contoh Aksi Nyata Refleksi Diri ( NUR ).pdfContoh Aksi Nyata Refleksi Diri ( NUR ).pdf
Contoh Aksi Nyata Refleksi Diri ( NUR ).pdf
cupulin
 

Recently uploaded (20)

OS-operating systems- ch05 (CPU Scheduling) ...
OS-operating systems- ch05 (CPU Scheduling) ...OS-operating systems- ch05 (CPU Scheduling) ...
OS-operating systems- ch05 (CPU Scheduling) ...
 
DEMONSTRATION LESSON IN ENGLISH 4 MATATAG CURRICULUM
DEMONSTRATION LESSON IN ENGLISH 4 MATATAG CURRICULUMDEMONSTRATION LESSON IN ENGLISH 4 MATATAG CURRICULUM
DEMONSTRATION LESSON IN ENGLISH 4 MATATAG CURRICULUM
 
Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...
Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...
Transparency, Recognition and the role of eSealing - Ildiko Mazar and Koen No...
 
Rich Dad Poor Dad ( PDFDrive.com )--.pdf
Rich Dad Poor Dad ( PDFDrive.com )--.pdfRich Dad Poor Dad ( PDFDrive.com )--.pdf
Rich Dad Poor Dad ( PDFDrive.com )--.pdf
 
Stl Algorithms in C++ jjjjjjjjjjjjjjjjjj
Stl Algorithms in C++ jjjjjjjjjjjjjjjjjjStl Algorithms in C++ jjjjjjjjjjjjjjjjjj
Stl Algorithms in C++ jjjjjjjjjjjjjjjjjj
 
UChicago CMSC 23320 - The Best Commit Messages of 2024
UChicago CMSC 23320 - The Best Commit Messages of 2024UChicago CMSC 23320 - The Best Commit Messages of 2024
UChicago CMSC 23320 - The Best Commit Messages of 2024
 
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
 
Michaelis Menten Equation and Estimation Of Vmax and Tmax.pptx
Michaelis Menten Equation and Estimation Of Vmax and Tmax.pptxMichaelis Menten Equation and Estimation Of Vmax and Tmax.pptx
Michaelis Menten Equation and Estimation Of Vmax and Tmax.pptx
 
Contoh Aksi Nyata Refleksi Diri ( NUR ).pdf
Contoh Aksi Nyata Refleksi Diri ( NUR ).pdfContoh Aksi Nyata Refleksi Diri ( NUR ).pdf
Contoh Aksi Nyata Refleksi Diri ( NUR ).pdf
 
VAMOS CUIDAR DO NOSSO PLANETA! .
VAMOS CUIDAR DO NOSSO PLANETA!                    .VAMOS CUIDAR DO NOSSO PLANETA!                    .
VAMOS CUIDAR DO NOSSO PLANETA! .
 
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptxAnalyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
 
ESSENTIAL of (CS/IT/IS) class 07 (Networks)
ESSENTIAL of (CS/IT/IS) class 07 (Networks)ESSENTIAL of (CS/IT/IS) class 07 (Networks)
ESSENTIAL of (CS/IT/IS) class 07 (Networks)
 
24 ĐỀ THAM KHẢO KÌ THI TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH SỞ GIÁO DỤC HẢI DƯ...
24 ĐỀ THAM KHẢO KÌ THI TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH SỞ GIÁO DỤC HẢI DƯ...24 ĐỀ THAM KHẢO KÌ THI TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH SỞ GIÁO DỤC HẢI DƯ...
24 ĐỀ THAM KHẢO KÌ THI TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH SỞ GIÁO DỤC HẢI DƯ...
 
Andreas Schleicher presents at the launch of What does child empowerment mean...
Andreas Schleicher presents at the launch of What does child empowerment mean...Andreas Schleicher presents at the launch of What does child empowerment mean...
Andreas Schleicher presents at the launch of What does child empowerment mean...
 
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading RoomSternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
 
Including Mental Health Support in Project Delivery, 14 May.pdf
Including Mental Health Support in Project Delivery, 14 May.pdfIncluding Mental Health Support in Project Delivery, 14 May.pdf
Including Mental Health Support in Project Delivery, 14 May.pdf
 
An overview of the various scriptures in Hinduism
An overview of the various scriptures in HinduismAn overview of the various scriptures in Hinduism
An overview of the various scriptures in Hinduism
 
OSCM Unit 2_Operations Processes & Systems
OSCM Unit 2_Operations Processes & SystemsOSCM Unit 2_Operations Processes & Systems
OSCM Unit 2_Operations Processes & Systems
 
Model Attribute _rec_name in the Odoo 17
Model Attribute _rec_name in the Odoo 17Model Attribute _rec_name in the Odoo 17
Model Attribute _rec_name in the Odoo 17
 
80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...
80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...
80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...
 

A University API

Editor's Notes

  1. 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
  2. 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…
  3. 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
  4. 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)
  5. 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.
  6. 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.
  7. 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
  8. 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
  9. 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.
  10. 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.
  11. Familiar players: Netflix, Facebook, Google Maps, Salesforce [click] Also: EdTech players like Instructure and Kuali.
  12. 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.
  13. 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
  14. 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.
  15. 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
  16. 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
  17. 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)
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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
  23. 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.
  24. 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
  25. FERPA!! But!!!! Controlling who has access to what is hard. We’re failing
  26. 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
  27. 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
  28. 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
  29. 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.
  30. 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.
  31. 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?
  32. 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
  33. 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).
  34. 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.
  35. HATEOAS is the way APIs accomplish what Web pages have been doing for several decades now: manage workflow.
  36. 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.
  37. 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
  38. 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
  39. 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
  40. 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
  41. 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
  42. But!!!! The cloud is scary
  43. 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
  44. 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
  45. 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.
  46. 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/
  47. 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
  48. 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
  49. 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/
  50. 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/
  51. 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
  52. 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/
  53. 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.
  54. Kin has a good collection of strategies for getting started And of course, my blog 
  55. Thanks for listening. Questions?