Table of Contents

Date

05 Dec 2017

Attendees

Name	Organisation	Present
Aaron Williamson	Symphony Software Foundation	Y
Gabriele Catania	BlackRock	Y
Former user (Deleted)	Scott Logic
Doug Friedman	Tradeweb
Lawrence Miller (Deactivated)	Symphony LLC
Rhyddian Olds	Deutsche Bank
Former user (Deleted)	IHS Markit	Y
Former user (Deleted)	Credit Suisse
Ken Watson (Deactivated)	Ipreo
Peter Monks	Symphony Software Foundation

Actions items from previous meetings

Task report

Looking good, no incomplete tasks.

Add new action items here.

Agenda

Time	Item	Who	Notes
5 min	Convene & roll call
10 min	Review action items from previous meetings		See above
15 min	Discussion: technology division organizations	Aaron Williamson	A discussion of how members' technology/engineering groups are structured and related to each other within the organization, with a view to understanding how an open source program would interface with them.
15 min	Discussion: identifying points of collaboration	Aaron Williamson	As the Foundation begins welcoming new platforms, we'd like to facilitate conversations between firms on which pieces of common infrastructure would be most beneficial to develop collaboratively. Who are the right people to involve? What are the barriers in your organization?
5 min	AOB & adjourn

Meeting notes

AW: How is technology organization structured and how does that affect open source program?

HS: Over time, tech function has been horizontal across resource pool. Some vertical groups that are independent and can manage involvement in open source independently. But have to differentiate between contribution, consumption, and committing code back to projects. Today, if you want to use open source in your project, due diligence is standardized across the organization. For contribution, that’s committee-based and more process-driven and involves peer review (by developers outside the project) and development manager review.

AW: Technology organization of IHS Market?

HS: CTO, then direct reports are divisional CTOs (four divisions, e.g. capital markets). One step below, product groups have their own CTOs. Below that, a lead architect and product lead for each product function: development, infra, devops, Q/A, etc. Product resources sit outside technology.

GC: Jody leads product as in face of tech to clients. Our structure is more business-oriented. So within APG we have teams that cater to different business areas.

HS: The structure depends on the group itself. It’s a matter of understanding where that group is in its life. Do you need a more startup-like mode, or more governance?

AW: Gabe, can you give an overview of BR’s structure?

GC: Regarding technology teams in BlackRock, the main top level organizations are APG (the Aladdin Product Group), BRS Digital Wealth and Tech&Ops. Aladdin Product Group (APG) looks after the Aladdin Platform, an investment platform both used internally in BlackRock and sold to several clients worldwide. BRS Digital Wealth is more focused on the retail side of technology (distribution channels, institutional websites, etc). Within APG, development teams servicing specific business areas are organized under a wider Investment Systems org, while the core development support is provided by the Core Platform org (CSI - infrastructure, CSO - operations, other dedicated teams for data and quality). Product development stands as a cross functional team within APG and supports all development teams as required.

HS: Help Desk bot was something that BR contributed to. Would that have gone through CSI for approval by the OSRB?

GC: Help Desk bot was developed by a diverse team with members from different corporate structures inside and outside of technology as part of a corporate Hackathon. As in this case, the decision to opensource would be made by CSI after liaising with Legal & Compliance.

AW: Awareness of open source policies across those groups?

GC: BlackRock's developers are very keen on open source contributions and APG leadership is working with Legal & Compliance to produce a minimum viable opensource policy. The current aim is to open up the possibility for developers to contribute in their own time, using exclusively personal resources and knowledge, and without associating with BlackRock.

AW: Who is the right person at your firm to identify pieces of infrastructure to mutualize costs on?

HS: I’d say the criteria you want is, is there a competitive advantage to offering it, and if not, determine what can be shared to mutualize costs?

AW: Would it be possible to facilitate conversations between people at your firm and others about which pieces of infrastructure could be mutualized?

GC: Our approach so far has been to look at things internally and, if they’re not differentiating or IP-sensitive, make a decision to opensource them. I see limited scope for a cross-company joint approach at management level as it would require a level of "institutional" transparency from both BlackRock and other players that we would have no incentive to provide. It would be better to explore synergies with a bottom-up approach, facilitating opportunities for developers to meet and share the way they solved common problems, e.g. organizing meetups with appropriate topics.

An example appropriate topic would be build systems. BlackRock has done significant work in streamlining their build process, solving problems that other big fintech players potentially have. Our developers would be enthusiastic to share their solution and explore possibilities to opensource parts of it.

Browser not supported