Date

18 Aug 2016

Attendees

Agenda

(no agenda prepared prior to call)

Meeting notes

• Bruce: Apologies for last meeting - I was out of office but got confused about the date and forgot to cancel it
• Bruce: Working towards demonstration between a FactSet bot and a rendering app developed by Markit
  • Frank isn't on the call, so not sure where the renderer app is at
  • If anyone else is interested in developing a rendering app, that would be really helpful
• Bruce: Implementation of interface for financial objects:
  • No official release date yet, but... we were almost able to get the web UI implementation of rendering into sprint 40, but due to an ill engineer it didn't quite make it.  I do expect it to appear in build 41.
  • Now we have something that looks like the production implementation - anything that's implemented using what's there will be valid with the final production version of the code
  • We implemented this in the API agent, to allow MessageML messages to be injected natively - currently the system uses a mix of Markdown and JSON internally, but we're switching to MessageML throughout
  • Build 39 has the necessary code to allow MessageML messages to be injected into the system, and what we'll have in build 41 (and can be provided in a development environment today, upon request), is the ability for the web UI to be able to process a message injected in MessageML and invoke the appropriate rendering app.  This code is in place and available, and the app I previously demonstrated (Yahoo finance) has been updated to use the new mechanism.
  • On the mobile client you'll see raw XML for any MessageML messages.  We have not been able to update the content export or mobile clients to support MessageML yet.
  • We hope to be able to deliver the final versions of MessageML in export and mobile client soon thereafter.  If any organisations on this call have a need for this in production - please let us know as it helps inform prioritisation.
• Johan: we're working on a more production-ready bot and are interested in continuing to work on it, beyond the POC.
• Bruce: to be clear we are 100% committed to MessageML throughout - it's just a question of prioritisation vs all the other features customers have requested to get the work finished. If anyone is interested, but not able to talk on this call, let me know - I'm happy to talk bilaterally.
• Bruce: I believe this is Matt Gardner's first call - is Blackrock interested in working on this in the near term?
  • Matt G: I need to get ahead of where we are with the Blackrock team and get back to you.
• Bruce:
  • Demo app overview:
    • User types a cashtag into a message
    • Bot (member of that chatroom) would recognise the cashtag, use the FactSet backend market data, add some FactSet heuristics to figure out what the user is referring to, and add some other information (CUSIPs, etc.)
    • It would then post back a complex financial object message back to the chatroom with all of those identifiers in it
    • Markit would then provide a custom renderer which would display some interesting market data (graphs etc.) for that security
  • Matt G: is this like Selerity - it's embedded within Symphony?
    • Bruce: yes that's right - we're extending the Javascript API so that an app can now register itself as a renderer for a particular type of financial object (e.g. "financial security" object).
    • Symphony then figures out which installed renderer(s) are available for that object.  The app would be given the object and an iframe, and can render whatever it likes in there
    • We have an ugly sample app that re-renders every minute with random data but we want to get a step closer to reality - to something a user would actually want to look at in terms of real data and professional presentation.
    • This could also be tied into firm's asset management systems etc.  The beauty of this is that the app can render anything it likes.
    • The whole point is that I could send the same financial object in a message to a Blackrock user and a JP Morgan user and they would see different things - perhaps from proprietary backend systems in each firm.
    • Matt G: makes sense!
• AOB
  • Johan: yes - we spoke about renderers, but we've also talked in the past about composers.  Any thoughts on that?  FactSet might be interested in doing a POC there too.  Are there hooks in the extension API in early stages we could look at?
    • Lawrence: I chatted with Paul T yesterday, who is specifically looking for an example of a firm who wants to build a composer, so congratulations!
    • Bruce: we have the design intent for this, but we have not yet been able to implement anything to support composition.  It's obviously something we need to do.
    • Lawrence: if someone's asking for it, it helps greatly with prioritisation
    • Bruce: if I can find 2 customers who actually want to use this for real, that would be useful for us.  We have a long list of other feature demands that have that kind of customer intent behind them, and we have to deliver where we think the most value is.
    • Lawrence: though I think this has more strategic value than a lot of the tactical asks.  But customer input is critical.
    • Bruce: we'll put that into the PM process.  What's driving this, Johan?  What might you use it for?
    • Johan: well we don't have a real world use for it really - the most likely use case that we see is that the user in our scenario is on a FactSet workstation, so the identifier is always available / composed and when they want to share it we'll use the agent API to send it to Symphony.  We don't have any real use cases where the composition will take place, but of course we're interested in the case where users don't have a FactSet workstation - where they don't have the proper identifiers, and may not want to have a bot in all of their chatrooms.  But in our case the actual composition is mostly done within FactSet, not within Symphony.
    • Lawrence: there's an interesting opportunity to build a composer app - you really need to have a data repository behind it with the security metadata to operate off of, and you (and others in this group) are in a position to do that.  There's an opportunity to deliver a default composer to many other firms using Symphony.  Look at it as a type of structural branding move - whoever does it first will likely get a lot of people using it.
    • Johan: I see where you're coming from.  I'll bring it up with our prioritising people and see what they say - see if it's an avenue we should go down.
    • Lawrence: many others on the phone who might consider this too.  It's not just FactSet.  
  • Matt G: is the demo recorded in any way?
    • Bruce: we did it live, but it would be useful to have something.  I can email you some screenshots, and I'm trying to get a video together to send to the group.  I have a few pages of PoweRPoint that have some screenshots - I'll email it.

Action items

• Send screenshots of demo app (bot+renderer) to Matthew Gardner @ Blackrock - Former user (Deleted)
• Review internally with Blackrock team re interest in early access to renderer framework - Matthew Gardner
• Review internally with FactSet prioritisation folks re interest in developing a custom composer (perhaps starting as a POC) - Johan Sandersson