2016-08-08 - Incubating Call #1 - Meeting Notes [MEMBERS ONLY]

Date

08 Aug 2016

Attendees

My sincerest apologies for mangling so many names - I’d greatly appreciate it if folks could correct as appropriate.  This will ensure we can correct the roster for the next call. 

Discussion items

Notes

• Introductions
• Michael Gardner - managing director, BNY Mellon Innovation Centre
• Anthony Fabbricino - product management at BNY Mellon Innovation Centre, API focus
• Adeel Khan - JP Morgan, responsible for the development team for the real time communications group (phone systems, messaging products including Symphony), extensive experience in APIs, hoping to contribute to the WG by evaluating APIs, coming back with suggestions, POCs on the JP Morgan end, sentiments on those APIs, etc.  Involved in Desktop Wrapper WG, but will be more focused on this WG as it better fits expertise and interest
• Ian McDermott - same team as Adeel, focus on infrastructure engineering for messaging (including Symphony and MS Lync), 250K users at JP Morgan so automation is key
• Amon? ?? - JP Morgan responsible for engineering for sales & research groups, interested in doing some POCs around Symphony to see how it can be used was a channel for our content
• Paul T - running product team at Symphony LLC, focused on “platform efforts” (APIs). Expectations are two-fold:
• Gather structured & scaled input from customers & partners
• Help orchestrate POCs
• William Kwon - PM at JP Morgan markets, interested in terms of API roadmap
• Karen Doe - JP Morgan delivery lead for Symphony rollout.  Interested to hear how we can work together with respect to the apps, as well as doing concepts
• James Turck - Credit Suisse, run architecture innovation for global markets, ESCo member, runs Desktop Wrapper WG, key way for Credit Suisse to integrate with Symphony.  Want to see a coherent way the APIs are presented to us, want to influence API story
• Jason Wanny? - JP Morgan - APIs for browsers, as developing a web site
• Ravi Shankar (JP Morgan) - client technology, interested in entitlements APIs
• Jhonalyn Esmena (JP Morgan) -  APIs & bots workstream at JP Morgan
• Anjana Dasu (LLC) - PM at LLC for platform, APIs
• Bruce Skingle (LLC) - principal engineer, developed current Symphony REST APIs
• Peter Monks (SSF) - formerly a platform PM (APIs, security, performance, data import / export, etc.), most recently at a SaaS publishing platform (Inkling) and an open source content management company (Alfresco)
• Objectives:
• Karen: there seem to be two different objectives:
  1. Development of API capabilities
  2. Prioritisation
  • These seem to need two different groups of people - developers and product people and it doesn’t feel like these should be mixed
• Michael: this seems to indicate ambiguous language in the charter e.g. “developers” could refer to Symphony LLC engineers and/or developers in member organisations
• Michael: 2 main objectives are being proposed:
  1. First and most important: ensure that we have good governance on APIs across all working groups, and all the different APIs represented at the Foundation, consistency of style, consistency of resource referencing, exhibit good / best practices wrt REST
  2. Second, which might be debatable: APIs could be used to shape the Symphony roadmap, via interface-first development.  To me this makes sense, but it’s a secondary goal.
• Karen: I understand what you just said, but didn’t get that from the draft charter
• Adeel: where do the APIs sit?  In the Foundation or in the LLC?
• Paul T: two work streams currently in progress:
  1. Full open sourcing plan - multiple pieces of the Symphony code base in the open source.  This is not what we’re talking about right now though.
  2. Symphony LLC is currently the sole contributor of APIs consumed by partners & customers, and as such we have a roadmap with short / medium / long term horizons.  We want this group to help make sure that we have a deep relationship with the community of partners & customers, facilitated by the Foundation.  Once the source code is in the open source, things become slightly different, but that hasn’t happened yet so I don’t think this group should worry about that yet.
• Michael: ultimately the Foundation can’t tell the LLC what to do.  The LLC is an independent entity with its own mission and objectives.  It’s conceivable that there are areas in which the Foundation may want to move beyond what the LLC provides.  It’s possible that some LLC API contributions don’t meet this group’s standards, and we might (for example) provide a proxy API that’s conformant with the WG’s governance standards.
• There are examples of LLC APIs today that could do a better job of following REST standards.
• Paul: I think what we’re trying to do here has the same objective: create a massively useful messaging platform.  Our goals across the LLC, and Foundation WGs are aligned - if we have to rebuild things on the LLC side then that would be a huge problem, and the WG can help ensure that we avoid that situation.  The WG can help the LLC product team scale beyond the 1:1 research interactions that have happened in the past
• Bruce: 3 things the WG could do:
  1. Look at the APIs in functional terms and build consensus about what’s needed next. e.g. entitlements.  Use this forum as a means to coordinate what’s needed.
  2. Look at language bindings for REST APIs - generally speaking developers don’t want to interact with naked REST APIs.
  3. Try to become a governance body for the way the existing REST-like API is engineered.  It’s unclear to me what the value of that would be.  There is an existing approach document, and the existing APIs follow it.  If there’s feedback on those APIs then LLC engineering would be interested in hearing it.  In terms of being more REST-like that doesn’t seem like a particularly useful conversation to me.  If there are things you can’t do, then that’s a lot more important.  Arguments about “true REST behaviour” are fairly academic and unhelpful approach in my experience.
• Michael: a baseline API standard is important, so that future APIs can be consistent.
• Peter: why don’t we avoid the word “REST”, and focus on an “HTTP API” standard instead?
• Bruce: we already have one of those.
• Peter: the feedback I’ve received is that the current APIs are not especially high quality or best practice with respect to REST / HTTP.
• Adeel: it’s about capabilities.  What do we have now, what’s coming next.  Are there gaps in the APIs that prevent consortium members from developing what they want?
• Michael: we’re running out of time in this meeting - why don’t we ascertain a time for the next meeting?  There’s clearly lots to discuss.
• Proposed date/time: 22nd August 8:00am US-PDT
• Paul T: suggest having the member organisations identify their “top 3” 6-9 month objectives for Symphony’s APIs, before the next meeting.

Action items

• Circulate LLC API Guidelines - Former user (Deleted) - available here
• Circulate existing API list - Peter Monks - available here (please contact Peter Monks if you don't have a login to the developer docs site)
• Review LLC API guidelines and existing API list - ALL
• Coordinate an exercise to identify 1 to 3 top API-related objectives that each participant thinks needs to be worked on in the next 3-9 months - Former user (Deleted), Peter Monks (with consultation from Former user (Deleted) & Former user (Deleted))
  
• Send out invitation for next meeting - 2016-08-22 - Former user (Deleted)