ApiDays Zurich Keynote 2017 Gareth Jones
•Transferir como PPTX, PDF•
3 gostaram•498 visualizações
Keynote on API vs Agile with Microsoft Graph from APIDays.io conference in Zurich September 27th 2017 by Gareth Jones
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a ApiDays Zurich Keynote 2017 Gareth Jones
Semelhante a ApiDays Zurich Keynote 2017 Gareth Jones (20)
Mais de Gareth Jones
Último
Último (20)
ApiDays Zurich Keynote 2017 Gareth Jones
- 1. Agile vs APIs How Microsoft Graph maintains agility in a contract-centric world API Days Zurich September 2017 #APIDaysCH Gareth Jones Principal API Architect @garethj_msft This Photo by Unknown Author is licensed under CC BY-SA
- 2. Macro velocity This Photo by Unknown Author is licensed under CC BY-NC-ND
- 3. Agile API This Photo by Unknown Author is licensed under CC BY
- 4. Self-service => Cost effective
- 5. Sustainable? Only with stable contracts This Photo by Unknown Author is licensed under CC BY-NC-SA
- 6. The dreaded VERSIONING slide This Photo by Unknown Author is licensed under CC BY
- 7. Big design up front enables agility with APIs - @garethj_msft This Photo by Unknown Author is licensed under CC BY-NC
- 8. Really, the Microsoft guy used THIS example? This Photo by Unknown Author is licensed under CC BY-SA
- 9. You need to make change ITSELF self-service.
- 10. Mobile Apps demand data THEIR way
- 13. 3 things to understand about Graph 1. API gateway to constellations of information
- 16. 3 things to understand about Graph 1. Personal constellations of data 2. The business opportunity is substantial
- 17. 90% of Fortune 500 companies Are using Office 365 100M monthly active users Office 365 commercial subscriptions 8T resources in Microsoft Graph (emails, events, calendar, users, files…)
- 18. The core data that drives business is on the Microsoft Graph Is this person out of the office? Who is their manager? Where do they need to be next? What documents have they been working on recently? Rich Context Deep Insights Real-time Updates
- 19. 3 things to understand about Graph 1. Personal constellations of data 2. The business opportunity is substantial 3. Linked data enables agility
- 20. Traversing links answers questions What photos were taken recently by my favorite photographers? Which colleagues have recently created documents? All without adding new API surface. Linked data enables agility This Photo by Unknown Author is licensed under CC BY-NC-SA
- 21. Agility: A demo is worth a thousand slides This Photo by Unknown Author is licensed under CC BY-SA
Notas do Editor
- So my name is Gareth Jones, and I’ve been with Microsoft for twenty years now, working on APIs for about the last 5 or six. I spent a couple of years as an architect for the Microsoft Graph in the core team, and more recently in our Education team focusing on building a platform on the Graph for app-builders targeting the classroom. So I’d like to start us off this morning by talking about one of the tensions in our world – perhaps a thing we don’t always mention as we celebrate the successes of APIs. Their tendency to give Agile practitioners on implementation teams headaches. I’ll dig into that and pitch two things that have really helped me maintain agility as I’ve transitioned projects to being API-centric and somehow I’ll magically manage to pitch Microsoft Graph along the way. How does that sound?
- Now I think we’re all used to Agile methods in our enterprise development, but sometimes the transition to API-centric development has seemed to conflict with that agility at some level. On the macro level the API economy has sped up business deals and enabled us to decouple monolithic projects. We have a clear win there. But at the implementation team level, as those teams learn about APIs there is fear. Fear that API best practices around change management are culturally a 180 degree switch from an agility culture. Agile of course is fundamentally centered on accepting business change as a natural part of the flow of building systems.
- API economy is based on contract-centric integrations Contracts don't change or customers get angry is our orthodoxy. There does seems to be a tension here. But why? Surely if there's new value, customers should accept change? It's an obvious value exchange? Some dev cost for some new super-duper must-have functionality? To understand this we've got to examine what most of the API economy is made of.
- It's mostly integrations between systems that were suddenly cost-effective because they didn't require a large systems integration project. Instead they were largely self-service due to published APIs - internal or external. This generated wonderful moments of business value to cost ratio. This is the moment where I get to give some side-eye to all the business guys yesterday saying “Don’t focus on the technology.” Of course they all forget that it was the technology simplification that enabled the API economy in the first place. SHHHH - don’t tell the MBAs - they think they invented it ;-)
- But is this sustainable? It's only sustainable if the initial low project cost is matched by low ongoing maintenance. And that only happens with stable contracts. If you have to revisit your project regularly , even if there's cool new stuff, the scale of the project suddenly went back to the previous cost and we're not in API economy land anymore. So how do we bring our Agilistas who are worried about calcification along on our API journey with us?
- Now there are a whole bunch of technical issues that the community has gotten to a point of mature discussion on - doing versioning right - where right is a religious belief - being the main one - that help tremendously in enabling change. And you must put a rational versioning policy in place or go down the road of full HATEOS. Patrice is going to save us this afternoon with his talk. But I want to focus on two other techniques.
- One is totally counterintuitive Big Design Up Front enables agility with APIs. Don't ship an MVP of an API that enables just one customer scenario. Pick a second one, ideally as far away in the domain as you can and design and ship that too. In stretching your design for those two scenarios, some part of your design brain will start to interpolate, and leave enough whitespace for most everything in-between.
- Whitespace is key in early stage API designs if you don’t want to end up with something that looks crazy once you start adding new scenarios. You need breathing room for everything that will come afterwards.
- The other comes back to change and the core self-service nature of the API economy. You need to make change ITSELF self-service. Where does most change come from today? It's either adding new pieces - a new value here or a new resource there. Any decent versioning policy can handle that.
- Or it's reshaping requests and remixing the resources required. This is most true in the explosion of mobile apps. Most people building mobile apps are super-sensitive to the number of round trips to create the experience. Whether because of performance, or network reliability, getting things down to the holy grail of a single round trip to your service is always the goal.
- But they all need different stuff! So finally, we get to Microsoft Graph, and why I feel like it's worth evangelizing the value of Graph-shaped APIs. (as well as using ours of course) So what is the Microsoft Graph? Who feels like they know what it is pretty well? Show of hands? Well, its not anything to do with Visual graphing? Or much to do with charts and graphs in Excel?
- Rich context, deep insights and core platform capabilities allow you to build smart applications
- Here’s three things to understand it.
- Privacy and especially user and organizational consent are at the center of managing API access to the quantity of user-data that we are stewards of.
- Why should you care? Make data work for you… make your applications and solutions context aware Microsoft Graph is the API to millions of organizations, and the foundation for building intelligent business process.
- Find the demo – and it is a demo, not production at http://graphql-demo.azurewebsites.net/
- GA Updated: .Net/Xamarin SDK & Android SDK GA: JS SDK & PHP SDK New VS integration