Before we get started I thought it might actually be quite nice to get to know you a little bit And I realized this is just after lunch and everyone's feeling a little bit Sleepy and full of food. So if you have been professionally or otherwise programming in Rails in 2018 Can you raise your hand, please?  Come on. This is exercise If you were programming in Rails in 2017 keep your hand raised otherwise put your hand down 2016 2015 That's a lot of people been programming in Rails for a few years 2014 13 12 11 10 9 2008 2007 2006 2005 That's is there two of us 2000 2004 The very first release. Okay, that is amazing. You should come and give this talk down Round of applause for the old-timer. I feel so young I was gonna go down to 2003 and then say you're either a DHH or a liar, but I'm glad that Everyone was honest Okay, let's get started. We can take the lights down now. Thanks My name is James Adam and I have been using Rails for a long time I'd like to share with you some of my personal history with Rails Hopefully it won't be too self-indulgent and hopefully I won't bore you before we get to the important bit at the end I also want to apologize apparently every time I come to America now I get a cold So if I cough or sneeze or anything, please don't think I'm gross Anyway, let's get started. So the room is nice and dark I want you to sit back and relax get as comfortable as you can You can feel your limbs and eyeballs Getting heavy all your worries are drifting away, and I'm gonna gently regress you all the way back to 2005 This is me in 2005. I was just finishing a PhD I'd actually discovered Ruby a few years earlier and I'd totally fallen in love with it I rewrote almost all of the code that I was using to do my research in Ruby. I Was so excited about Ruby when I first discovered it that I sent this in an email to my friends who had all gotten proper jobs When they'd left university writing software most amusing Java at the time Now the nature of PhDs is that when you finish you've become a deep expert in a field that's so narrow It can be really hard to figure out how to connect it to anything else to anything in like the real world And I was worried in 2015 2005 sorry that I was gonna be in a similar state professionally because I'd fallen in love with Ruby But there's you know You can't get a job doing something that you love all the time And I was really worried that I was gonna have to go back to Java or C++ in order to make some money But I was actually incredibly lucky because just as I was finishing my PhD this excited Danish guy Started talking about a web framework. He was writing with the weird name Ruby on Rails But I should mention now. I'm gonna show a lot of blog posts. You don't have to read them all I'm gonna highlight all the interesting bits. So don't try and read everything I show So long story short a job in London got posted to the Ruby mailing list And I took the seven-hour train journey down from Scotland to London for an interview and then a few months later I was working in my first job Using Ruby being paid to use Ruby and a very early version of Rails I think it was 0.9 at the time. So that's maybe a couple of point releases after you Now our team was like a mini agency inside of a much bigger media company And the company used a tangled mess of Excel spreadsheets to run their business in like multiple departments using All kinds of crazy stuff inside those spreadsheets and it was our job to build nice clean web applications to replace Some of those spreadsheets at least We were a small team. I think never more than four or five developers But we'd work in a whole range of applications often at the same time Now these days Rails in particular with Rails 5.2, which was just released a few days ago It gives you everything that you might need to build a web application But it's easy to forget a time when Rails had almost none of the features that we take for granted now a time before active storage a time before encrypted secrets before action cable before turbo links or the asset pipeline before resources or rest or even before rack These are the headline features of Rails 0.13 in spring 2005 Migrations were brand new. Can you even imagine a version of Rails without migrations? And in lots of ways Rails 0.13 is similar to modern Rails. It has all the kind of MVC things that you'd expect models with associations and controllers with actions and view templates and action mailer But in other ways, it's actually more similar to Sinatra Than to the Rails that we have today And for example, if you install Rails 0.3 and all of the gems it needs then in total You have about 45,000 lines of code But if today you add Sinatra and active record and nothing else to a gem file and install that you end up with Over a hundred thousand lines of code. So Rails 0.13 is like less than half of Sinatra plus an ORM But the core philosophy of Rails then is exactly the same as it is now convention over configuration using the expressiveness of Ruby to try and make web development fun and Providing most things that most people needs to build a web application So it's summer 2005 Rails is at 0.13 and in our team we're building all these applications And we realize that we're building the same basic features again and again Specifically things like code to manage authentication. That's controlling who can access your application and Authorization so controlling which of those users have access to things like an admin dashboard and stuff like that And I think we had at least four applications under development at the same time Which is around about one per developer and so it just seemed counterproductive that each one of us would be building the same feature Each in a slightly different way, but for no good reason Possibly introducing our own little bugs that would be different in every application and generally making it harder for us to Collaborate on these applications or move around if someone was away After all a big part of the rails philosophy was and is dry. Don't repeat yourself And all these authentication and authorization features weren't particularly complicated or interesting They had the same stuff you might expect today logging in with an email log out something about forgetting a password a User model and a table in the database to support that and maybe some mailer templates to handle user lifecycle So it occurred to us that what we really needed to do was to write this once and Then have a way of sharing it between all the applications that we were writing So that we could all benefit from bug fixes and new features and be able to rotate around these applications in our team more easily So in modern rails, we typically share code between applications by using a gem with a rail tie inside a rail ties just a way of Configuring how you hook into rails initialization But these weren't added to rails until 2009. So they don't exist yet. We're in 2005 Before rail ties we had plugins, but they didn't appear until rails 0.14 We are 0.13. So these don't exist yet either. So we don't have access to that And even using regular Ruby gems, which did exist in 2005 was problematic because we didn't have bundler We didn't have ways of like locking down gems to individual applications So it was fairly typical that you would deploy multiple rails applications to the same machine But if you upgraded the gems on one, it would upgrade the system gems and that might end up breaking your other application rails did add some Rake tasks, I think for freezing gems, which is like a precursor to bundler, but they didn't appear until rails 0.14 as well So we couldn't use that so without any existing mechanism. We had to roll up our sleeves and invent something ourselves so in the late summer of 2005 we extracted all the login and authorization code including controllers and models and views and so on into a separate repository and then wrote a One file patch library which when rails loaded makes sure that our controllers and models were in the load paths for rails and Then made a few monkey patches to rails internals to make the rest of the stuff work like you would expect Originally, this patch was called frameworks, but pretty soon after it got renamed to engines The name engines was actually the idea of Sean O'Halpin It was my boss at the time and has been programming in Ruby probably longer than either of us So that was summer of 2005 in October of 2005 a few months later Jamis Buck added an experimental plugins feature to rails now plugin is just a folder of code that contained a lib directory and a file called init.rb and rails plugin mechanism at this time Just iterated through a series of folders in vendor plugins looking for init.rb files and then loading them and doing whatever was in them You could do anything And we spotted this feature being added to rails and so I emailed Jamis and DHH to say hey We've been working on something similar. We'd be very happy to contribute And we got a very nice reply the gist of which was that sounds interesting. Why don't you package that up as a plugin? And then we'll see how people use it So that is exactly what we did Resulting in the engines plugin Which let you treat other plugins as these kind of MVC slices Which could be shared between applications and this is the very first home page for the engines plugin that was hosted on Rubyforge I also released the first engine the login engine which was super simple It just wrapped up code from one of the existing authentication generators That we had used in our applications along with a few other tweaks that we found useful And this was November 1st 2005 And people got pretty excited like kind of super excited which is really exciting for me being the person who was like proposing this idea There was enthusiasm for the demonstration login engine that we'd released and it seemed that people understood the idea behind what we were doing Somebody even tried to turn typo Which was the first really popular rails blogging platform into an engine so that people could have blogs to their applications and People got specifically very enthusiastic about never having to write their own login code again And I think some people thought that they would never ever have to do that That these engines were going to just like solve this problem for them forever But then somebody got so excited that they started talking about engines within engines depending on other engines And I think it was this idea that ultimately pushed DHH over the edge and about ten days later He wrote the first blog posts about engines on the official rails blog Now in the posts David talked about his distrust of the dream of component-based development And that it's better to build your own business logic than try to adapt something that someone else wrote And that we shouldn't expect to be able to plug in or swap out these high-level components like forums or galleries That sort of stuff and never have to build them ourselves And I agreed with him But tried to clarify that what engines were good for was taking some code that you've written and then sharing a bunch of Applicate sharing it around a bunch of applications that you are writing As long as those features are relatively isolated from the rest of the application And I think David agreed with that And I can see his perspective when you're working on a single application like say base camp Then you probably can and should develop as much of the business logic as you can for yourself So that you can provide the best experience to your users But if you're working on three or five or ten different applications at the same time Then chances are that the balance of value versus the cost of sharing might tip the other way So I was pretty happy with that conversation It seemed like we generally understood and agreed with each other about the benefits and the dangers of what I was proposing I shared an idea and David had just expressed a bit of caution But a bunch of people had become super excited by it and maybe a little bit too excited And then a lot of people on the other side took David's post as a declaration that the idea was fundamentally bad and To be avoided at all costs And so that's basically how things played out for the next three years Every now and again somebody would write a blog post saying maybe rails need something like engines or engines are actually that bad Only to be met with a response like oh, didn't you know the engines are too much software whatever that means And like really bad and then I would write a comment to be like I think it's a bit more complicated than that and then maybe the author would add some clarification to their post But by that point it's too late and you've got people commenting that rails engines are actually evil This is real. This is all real. I call this time the wilderness years and During this time I tried to respond to criticisms of the engines concept with varying degrees of success It was occasionally quite frustrating. I Spoke at a bunch of conferences about plugins and sometimes engines And I also tried to gently steer the development of the plugins mechanism in rails To make it easier to do the things that engines needed it to do so that was adding things like controlling plug-in loading order giving plugins a more structured access to rails initialization and configuration and stuff like that plugins became very popular and Went from originally being shared as links on a wiki page to having their own directory where you could search for different plugins to help you With the application you were building and you could leave comments on plugins and so There's an example of a fun plugin that I wrote for one of those presentations You can see that even though maybe I'm frustrated inside. I am actually having fun And when if I did mention pinch engines gin those presentations I tried to always mention that there were valid use cases, but yes You could get yourself in a mess, but that doesn't mean that people should never ever use them And I'd hope that speaking at those conferences and writing those blog posts if not Convincing people totally to what I believed would at least soften them to the idea that engines weren't a hundred percent evil But then on the official plugin directory you'd get someone tagging the engines plug-in as shit And the cycle would start again. I still don't know who did that Maybe maybe we'll find out one day So some people would go to great lengths to explain why rails engines were bad As an aside, there's a thing called better just love headlines Which says any headline that ends in a question mark can be answered with the word no But I'd write like a short comment to try and respond to each of their points and hopefully clear up any Misconceptions about what the engines plug-in was and what engines were good for And in this particular case though, what was super confusing is the same people then released their own plugins to try and do basically the same thing as engines I've never really understood why that happened and the wilderness years lasted long enough that some companies actually wrote plugins like Engines themselves not realizing that engines had ever existed So I had any Conversation with Brian and we agreed that we should probably try and like coordinate our efforts instead of both having to fight this battle again So all this is happening between 2006 and 2008 during which a new Ruby web framework called Merb appeared And it was designed to be extremely fast Largely because it didn't do very much And we particularly good at handling many simultaneous requests and things like file uploads And unlike rails which at the time was a relatively tightly coupled set of web frameworks Merb was designed to be extremely modular so it could for example support multiple ORMs It was also designed to have clear and stable internal APIs Since much of the Merb framework was written as optional plugins that you could load or not load depending on what you needed And one of the developers whose most involved in Merb was you who the cats who eagle eyed people will have spotted was generally sympathetic to the concept of engines And so it's probably not surprising that in 2008 Merb introduced their own Implementation of the idea called Merb slices to a generally positive response from the Ruby and Merb communities But it's not a huge surprise to me that this is how the most popular rails podcast at the time chose to frame that Kind of like rails engines, but doesn't suck exactly And I don't blame the presenters for thinking or saying that it's just a representation of the opinion Of the rails community as a whole at that time This is a painting of Sisyphus Who in Greek mythology was cursed by the gods by being forced to roll an immense boulder up a hill Only for it to roll down when it nears the top repeating this action for eternity and these days It's a common image invoked to describe tasks that are both laborious and futile So we come to the end of 2008 Rails is about to reach version 2.3 and the controversy has largely died down people who found engines useful We're just getting on with it And I hope they were happy and the people who felt that engines were evil seem to have forgotten that we existed So you can imagine my surprise when I received this email from DHH with the subject line I repent I think I actually became giddy after I received this I may have laughed maniacally Rails core had decided that engines weren't evil and that they were going to be integrated into the framework My work was done Okay, it's not It's not really that simple, but without going into a huge amount of detail Rails 2.3 Is plug-in system absorbed some of the behavior the engines provided They could provide Controllers views and most other types of code and this was released as rails 2.3 in March 2009 In the same time Merb and rails decided to merge and rails 3 would be the result and the goal of doing this in part was to Establish some clear and stable API's within rails so that other libraries and plugins could rely on them and they wouldn't break Every time rails was upgraded and this is a fairly significant rewrite of a lot of the core parts of rails in order to create those API's Yehuda and Karl Lers did much of the work and as part of it They decided that rather than having a rails application and then these engine things inside of it that looked like rails applications and access to the same hooks and Configuration and so on but instead the outer application itself should just be a rails engine with a few other bells and whistles to make it work So I guess the engines inside of engines person actually got their wish after all and this was released as rails 3.0 in 2010 And finally with rails 3.1 in August 2011 the last two bits of work that the engines plug-in did managing Migrations and assets got merged into rails and the plug-in that I had written was officially deprecated My work really was done at that point So you've probably heard of the Gartner hype cycle Which is a way of understanding how technology trends evolve you have the initial creation or discovery of the technology And then the peak of inflated expectations where everyone is like super excited about it and imagining like having jetpacks Or living on the moon or something Then you enter the trough of disillusionment when it turns out it's actually much harder to build a jetpack than we thought And there's a bunch of things that aren't ready before we can start building it Then you start to climb the slope of enlightenment as we figure out all those problems and like understand how you can build a jetpack without setting your legs on fire And then finally you reach the plateau of productivity where everyone is zipping around on their jetpacks And we look back at old movies of people moving around using their legs and laugh at how quaint they seem I think we can use a similar cycle to understand how the rails community reacted to the engines concept So for engines it took just under six years from idea to acceptance We have the same starting point and the same peak of inflated expectations like I'll never need to write login code again But then if you just give me a second, I just need to adjust the axes here. We enter What I like to call the trough of received opinions Where some big names in the community have been like whoa, whoa, whoa, and personally we've never used the technology But we've heard that it's bad. So basically it's the worst thing ever And then for about three years we scrabble up this slope of fear uncertainty and doubt where quietly privately some of us are like Hang on I actually would quite like to share some of this functionality between the apps I'm writing but then you try and figure out how and you discover some old blog posts that say it's evil So you just give up and then finally we reach the plateau of oh are those still a thing And as you can see at the end of the cycle we end up like basically where we were But at the very least I can finally put the boulder down and stop pushing it up a hill So that took about 22 minutes if you'd like a nice summary I found this quote in the rails 3 in action book There was a lot of controversy surrounding engines and James spent a lot of his time defending the decision to develop them Since then however the community has grown to accept the idea Good so What changed in 2008 well, I actually only realized this as I was writing this talk But it's quite simple in retrospect So rails was originally extracted from base camp the software the DHH built and still works on today and at the start of rails life base camp was the Only rails application that David worked on but between 2005 and 2008 37 signals added another three flagship applications along with a couple of other small ones and their small team I think it was for developers at that point had to build and support these applications All at the same time And that sounds kind of familiar doesn't it? Really so that was just my theory amazing That's I might need to kind of go into therapy to fully process that But we'll keep going from now So in the rails doctrine which is a somewhat provocatively titled document that David wrote about two years ago There's a section called provide sharp knives and what that means is that with some of the tools that rails gives you It's definitely possible to get in a mess, but instead of protecting you from misusing them by withholding them all together rails Says that you should trust yourself to use them in an appropriate way and Concerns is one example of this sharp knife if you've ever used or read about concerns Some people think that it encourages sweeping complexity under the rug While others think that used appropriately that's not a big problem and the benefits are where the costs and That's exactly what the engines concept is. It's just a sharp knife For around six years It was a little bit too sharp to be kept in rail silverware drawer But now it seems like perhaps we can be trusted with it and these days a lot of popular libraries are engines You probably all used or heard of device, which is an authentication engine the spree e-commerce platform is Distributed as an engine you can get content management systems like refinery CMS Which is an engine and even the new active storage feature in rails 5.2 is implemented as an engine So that's the end of our trip back to 2005 We're now back in the present with active storage and this is a good moment to take a stretch if you need it But before we start the third act I want third act. I wanted to mention one thing that has nothing to do with rails or engines Most of what I've talked about happened at least 10 years ago and As you can tell I have some feelings about it So when I was writing I wanted to make sure that I hadn't inadvertently distorted any of what happened So I wanted to find the like actual articles and things and all of the comments and posts that you've seen are real They're just they're exactly as they were But when I try to actually find them find all the original news group posts and articles and blogs and so on What I found is that almost all of the sites that I've referenced are either totally gone or only partially available The comments on the rails blog are gone loud thinking is gone Ruby Forge is gone The rails engine site is definitely gone because I'm not paying for that anymore I Think that history is interesting and important and it's kind of mind-boggling to me the information that's only 10 years old might Without archive.org just be lost forever I think that's insane, especially in like the information age. How can that possibly be? So if you can please support archive.org they accept donations on their website, and I genuinely believe they're providing one of the most valuable services on the web today Okay Back to rails So at the start of this talk, I did say that I didn't want this to be too self-indulgent And I don't want to paint myself as some kind of misunderstood genius or hero who's finally proven right And I'm sure that there are many other stories like this one in many other open-source communities But what I think is interesting about this journey is that it shows that the history of rails can be viewed as a history of opinions Rails is opinionated software, which is great because it saves us a lot of time by allowing us to offload a lot of decisions about building software in exchange for some implicit constraints and Following those constraints is what we sometimes call the rails way And some of those opinions are about how we use Ruby as a programming language about how you should express behavior at the level of a single line of code An example of this Of the methods that rails adds to objects like string or array Objects in rails applications tend to have a lot of methods And some people believe that it's better to minimize the number of methods on an object But it's rails opinion that the trade-off is worth it in order to be more expressive And there's nothing wrong or evil about either of those positions They're just two different opinions Our opinions are a more architectural level and are ultimately about how we ought to structure the applications that we're building with rails An example of this is if you build your URLs and controllers in terms of rest and resources Then you'll be able to use a lot more of the abstractions and high-level mechanisms that rails provides But if you like to add a lot of custom actions to your controllers, then rails can't stop you and it won't stop you But you'll have to do a lot more work yourself to wire these things up Well, that's not the same as saying if you don't use resources, then your code is bad It's just a guiding opinion that rails has And what might not be obvious is That over the 14 years of rails life so far those opinions have not always existed and they have not always stayed the same The rest verbs and resource-based architecture weren't a part of rails for two years An inline JavaScript was fine until 2011 when rails decided to use Unobtrusive JavaScript instead and if you wanted to send an email for example when a user signed up up until rails 4.0 You probably would have written an observer and used that to decouple User creation and everything that that's about from email concerns But they're removed in rails 4 and so in the modern rails where you probably handle that by writing a concern Which mixes in a callback directly to your user model? And I think a particularly interesting example is active resource It used to be a part of the rails framework It was an evolution of the action web service framework which supported soap and dynamic wisdom generation and XML RPC and all the acronyms that David mentioned as WS death star and his keynote yesterday Active resource let you let's you load and save remote data using JSON over HTTP Using the same Ruby methods that you'd use if you were interacting with an active record instance And it made it easy to build things like micro services And so I think acted as a signal that you could and should do that But it was removed in rails 4 which might be the one of the first indications of the Current opinion that the majestic monolith is a more productive way to work overall And the purpose of highlighting these changes of opinion is not to say that DHH or anyone who was or is in rails core is Frequently wrong is to show that even in the world of opinionated software opinions can change Fundamentally what is and isn't in rails is driven by the needs of the people who write it And so to a greater or lesser extent that means people building applications like base camp But not everyone is building an application like that I think more and more of us are working on rails applications that have been around for a long time in some cases more than 10 years now and Those kinds of applications have different needs and experience different pressures Than one where the developer controls all the requirements and is free to rewrite it if they wish by any time that they wish According to built with comm there are almost 1.1 million sites using rails right now So it's statistically extremely unlikely that base camp as a piece of software or as a company Sits at the exact center of all those different needs and pressures and trade-offs that those other applications and companies might have Right now there are differing opinions in the community about what the future of rails might include the majestic monolith versus Microservices concerns versus smaller object composition system tests versus unit testing and stubbing and these Explorations and tensions are good because we need people to be pushing the boundaries of the rails way to figure out what's next if We all just sit back and wait for a relatively small group of people to just tell us what the future of rails is What it looks like then that future will only be suitable for their particular unavoidably limited contexts Now in 2014 37 signals changed their name to base camp and returned to maintaining a single application So some of the motivation within rails core for things like engines is naturally going to diminish and that's understandable It's an itch that they no longer have But I wonder how many other software itches there are which base camp doesn't experience But hundreds or thousands of other application developers do And I think we need more voices sharing their experiences good and bad with the current rails way And we need people to build things like trailblazer and rom and hanami and dry rb And we need then other people to try using them and learning from them And probably none of these projects are ever going to usurp rails But they might contain ideas about how to build software or how to structure web frameworks which are new and useful Unlike murb they might end up influencing rails towards something that could be better for all of us They might have already found some Conceptual compression to use a phrase from yesterday That we can either adopt or adapt for ourselves And there's no reason why the people doing that exploration can't be you Because no one else is going to do it You are the rails community. You are the people using rails all the time Who better than you to spot these situations where a new technique or approach might help? Who better than you to try and distill that experience into some beautiful expressive ruby code That captures a common need You can be the crazy ones the misfits the rebels the trouble makers the round pegs in square holes The ones who see things differently As it says at the bottom of the rails doctrine. We need disagreement. We need dialects We need diversity of thought and people it's in this melting pot of ideas will get the best commons for all to share Lots of people chipping in their two cents in code or considered argument Okay, wonderful rails now embraces all manner of opinions under its big tent But what happens when you have your idea? But people don't quite understand it immediately and things get a little bit out of control and suddenly people are decrying it as evil Well, I feel for you genuinely because when I was working on engines the main people the main way that people express this Kind of opinion was in the comment form of a blog But these days we live in the age of the tweet where many people don't think twice about unleashing a 280 character salvo of hot Takes out into the world, but I'm not sure that we live in the age of considered argument anymore So what can we do? Well two things Firstly as consumers of open-source technology I think we could all try our best to avoid sharing opinions like that if you've had a bad experience with a technology or a technique Then that is totally valid and you can and absolutely should share that experience But just don't do it in a tweet or if you must do it in a tweet at least try to be a little bit balanced Or even better than that start a blog or write on medium or anything and write as much as you can About your experience and your context and then share a link to that on Twitter. Where was I?  So this is that first blog post about rails That I showed at the start of the talk on the 37 signals blog in early 2004. I have not edited this Let's look at the very first comment Why use Ruby when you could probably have developed this thing in less time with PHP. Is it just some desire to be different than everyone else? I think what this shows is that the value of why you're doing something differently is often not immediately obvious to other people You will have to patiently explain it. You should see the number of comments that they've had to write after this Sometimes again and again and sometimes for years and years and you won't be able to convince everybody But you might reach somebody who finds your idea interesting or useful And they might reach somebody else and before you know it lots of people are getting value out of your idea And it might end up making a big difference after all So there's one last thing I'd like to say When you make something and it receives criticism on the internet, especially so basically criticism from strangers It can be very hard to deal with and sometimes so much so that we might stop creating altogether or never even try And when I was researching with a stalker found this old blog post by DHH from 2006 That I think captures a good way of thinking about these things. So I'm just going to paraphrase it for you View your idea or the thing that you've made as a pearl not a diamond When someone responds to your idea and points out all the flaws or the situations where the idea doesn't work for them That's okay because what they're asking for is a diamond. They want something that is flawless.


So hynny'n bod ni sl希望 that this session is to really try and look at some of the critical issues facing collecting perhaps better data for MSF in humanitarian crisis settings and overcoming some of the clear constraints to collecting data, most obviously security and access to information Bydd angen o addysg ymhwyl ar y purchasing of activity o ymmwyl? A'r ddod,herwydd o gweithio, cyffredinol, ac o bach o'r ddod, a'r angen ffocosol ar gearnau ar hyn.  So we have with us a stellar panel, this is where my pronunciation hits a record low. Ysaf, Siglyn Netschke, four out of ten I'll give that one. We have Vanessa Creman, Fernando Felera at the end and Francesco Kecky. So Ysaf is coordinating operational research for MSF operational centre Geneva. Vanessa has worked in many roles and countries with MSF and has just returned from Uganda's South Sudanese refugee emergency response. Fernando is importantly an anthropologist and she, we need more anthropologists, there's plenty of epidemiologists. So and she has a role in anthropology, community engagement and health promotion with MSF Spain and lastly but not least we have Francesco who is professor of epidemiology and international health at the London School of Hygiene Tropical Medicine and Epidemiologist extraordinaire. So we're kind of doing this on the fly a bit but with the intention to try and see how we can understand or get better data in such settings and firstly I want to look into this question of how we this potential attention with balancing data collection needs and there's lots of arguments why we need more and better data with operational priorities and activities and how we can impact or reduce the impact on operational activities. So perhaps starting with Vanessa, how can we achieve that balance between data needs and operational priorities? So I guess from a purely sort of field perspective and to consider what the purposes of our data capture are and primarily to the purposes of why we collect data certainly in an emergency context. So to direct our operations is why we collect our data to monitor our interventions to make sure that we're doing the right things for the right people at the right time and to inform our advocacy and I guess alongside that the whole raft of operational questions that we have to improve the humanitarian response and the medical response and I guess that the ultimate crux of prioritising those questions and making sure that we collect the right data at the right times without being able to compromise that day-to-day interface and where we want to be which is in front of the patients and of the community. I think one of the challenges we face is to not only measure ourselves against the people that we see walk through, you know, the MSF clinic doors, but also to the wider communities that we need to serve and to make those people who maybe are invisible to us because they haven't seen us before. How do we bring visibility to that? I think the last few presentations show that balance between survey which is looking broader and also against our routine data capture and that's that perfect interface. Do you want to follow on from that? Yeah, sure. I think me I see it in really same way. I think that the real question is what is the context and why we are collecting data, why do we need it? And in emergencies I mean firstly we need data to be able to do the work so we need to understand where we are but also we need enough data to understand if we are doing it's good or bad so just but basically the even our healthcare and the data from the clinical facilities if you aren't able to analyse enough to see whether the our patients are dying or not it's difficult to to be good in what we are doing and sometimes in acute emergencies we actually struggle to collect even the very basic clinical data because our HIS systems are complex and it takes time to put that in place but then another big part in to be able to run emergency operations is to have enough data to be able to also to document what we are doing and to document the situations of the populations that we are serving where the surveys come in place where the primary goes maybe not necessarily directly to direct our interventions but also to speak out on behalf of the populations and lastly in the same context where I think those that work in the emergencies know and people that are immediately demanding data are actually communication colleagues that need data to be able to say what we are actually doing in this context and I think I hope we'll come back to that. I think outside of that is then like what we would call really research within the emergencies I think especially of the epidemics that need different setup but where we need to think in advance what questions we want to answer in what context. Sure I'm just going to bring Fernanda in here and then I'm going to bring Francesca in after that. Thank you so let me get the anthropologist David in the room. Now Chester I agree with my of course with my colleagues are presenting like if we take the question right what do we know I will go for like the what the why the how and the when the when will I think take us to different moments and different kind of information that we need and the way to collect it that will be also defined by the when but then the how we do it and from where we are standing right as MSF that's that would be my my starting point of questioning you know like a kind of anthropology of the institution. Today the opening Vicky was mentioning that governments should put people at the center like I would say do we do it systematically just one example look at the cloud here look at the cloud and see where people are like here small patient tiny here refugee here IDP here but the rest where are the people this is diseases this is issues that MSF needs to tackle from a very medical and scientific way which I'm not saying is right wrong I'm just saying let's understand who we think we are and how we project ourselves when we are in the field and how we relate to and with the people we are aiming to serve that also will condition the way we establish a relation with them we build trust and then we are able to understand the reality that was also a bit shown in the in the research that was presented here you know like we see what we want to see we look at inside the clinic we analyze our data the or we look we go to the houses but we look for a specific target population also we label everything we love that so we look for that like Jordanias I mean I think we need to widen a bit the analytical scope and understand reality a bit better and give the place to the people to tell us a bit we need to learn also from locality and maybe there are positive things also happening at local level that can help us to improve you know what we do and do it in a much better way and localize way using the resources also in a much better way it's a win-win situation but it's a change of scope change of approach and it's not easy okay thank you Fernanda and um so taking a much more people-centered approach and not not necessarily just patient-centered approach can I just bring in Francesco now who uh before the session raised the the rather fundamental question of of can MSF actually say its programs are performing well yeah this is not at all a plug yeah so uh yeah just to uh would you would you care to elaborate on that please Francesco thank you I feel shy after Fernanda because no you're absolutely right I think I think I see a connection there though in that um I mean I mean what I would what we see a lot of and that's it's very good in in some of that for example in some of the scientific days of the years is is really good data being presented by MSF when they become interested in specific services or vertical programs be they SGPV surgery then you know HIV at the most extreme and in terms of quality of monitoring and then and then of course there are these these attempts to measure health status in the population or prevalence of malnutrition or perhaps even the prevalence of NCDs but I guess my worry is that if I and this is a little bit presumptuous perhaps if I asked the general director or the medical director of of any of the OCs how confident they actually are that some of their general emergency health programs are performing and that they are actually delivering the stated package of health services you know directors don't shoot please I'm not so I'm not so sure that that that that information would be necessarily readily available and and interpretable so um and that for me is a huge matter of matter of accountability um I know that for example health information systems are actually being rolled out by the different OCs in different ways that's very good um and and I don't think that it's possible for to overburden programs by by collecting details sets of indicators for each for each health service say antenatal care or routine EPI um so practically I think what I'm what I'm seeing as possible is to actually zero in on a few really carefully selected indicators that of course are flexible given the local package of health service given a local epidemiological profile but but really what it's important I think for me is to is to think of I'll yield my time later is is to think of three types of indicators firstly you need to know about the availability of of health services so most of the all of the population that you're targeting needs to be within the realistic catchment area of your services be they comprehensive management of of obstetric emergencies for example secondly you need to know about the coverage of a service so whether people are actually utilizing it and that's the in a in a way the link with fernanda because I think that often if you measure coverage you realize it's low and then anthropology really needs to come in because it needs to actually explain why that coverage is low by going to people and stopping you know no longer seeing people as as objects or patients or medical problems but rather understanding why they're not accessing care for example and lastly your quality so those are three quantities that if you multiply them really allow enable you to infer performance services are available they have high coverage and they achieve high clinical quality of care a few carefully selected indicators of each should enable you to have a proper picture they won't explain why certain problems come into being that's where anthropology I think comes in thank you you look like you want to respond I would just like to react I think that's very nice and that would be great I just find it rather difficult to I think the to measure those three indicators you would need different approaches we can't measure those through the routinely collective data in any case so we need to understand to get this data through the population understanding so I see it rather difficult to do it routinely and to be able to monitor our interventions this way so it's just a challenge just adding on that I think there there is a possibility to work on developing like a framework that is fit for purpose that's actually what I'm working on like but based on the reality of humanitarian interventions not only humanitarian in general but MSF MSF way of operating MSF identity the principles all these things like taking all these into account for the building up of this framework of a fit for purpose tool that can allow you not to be perfect in a sense let's say scientifically based research based but operationally you know that will allow you to widen this analytical gaze in a simple manner and you will not need anthropologists in the field let's say you know we have security issues we're operating remote we need solutions for that but we need to be there in the community in those that's the reality of how we work so we need something simple you see that the whole team can I call it ask the why question it's very simplistic I know but it's at the end it's that it's going a bit beyond what you collect as data and then asking the why you know like you were presenting your information then the reasons why but that is not a common thing people ask you did take the pill I give an example did you take your pills no next question and then there's no why then let's get the why and then let's work out those barriers and let's also ask for the positives that's something we don't do we look at everything outside like that what doesn't work it's not good yeah all we collect all that but also there's some resilience there's coping mechanisms people survive without MSF being there we need to understand how they do it to build up on that we can construct together we can add on something you know to the reality of the place but it has to be done together that's reality of life you know we don't live in a vacuum or in a lab sure so uh when's your framework going to be ready you need your framework uh Vanessa you had something to say I completely agree with princess go I think um availability access coverage quality all much much needed and I think for all those seeds we've been online with a with Hiss which very much looks inside the house uh seldom outside um so I think it is the the valid next questions for us to to explore but I do think we need to be realistic around the operational challenges that we face um especially in acute emergencies and I guess that's where any of these contexts I mean looking at Jordan it took us years to get to that point if we're going to ask those questions in all honesty so um being being clear about about those ambitions and those timelines I think those questions can be asked over time when we're settled into a context and we have some understanding but in acute emergencies I think we come back to often we know very very quickly what needs to be done if it's around water access around establishing healthcare around vaccination because there's an out an outbreak of measles for me the the the key questions around improving what we do and and our data capture would be around not only looking at the what but the how and how do we inform ourselves rapidly um from the community about the best ways to go about designing a basic healthcare program or how should we go ahead with a mass vaccination in that population what are the key informations we need from the that community to make sure that those interventions are are accepted other that they're fitting um for within those populations needs so I guess it's around two stages one is that acute stage and what we can do and the triage that we have to do the priority setting that we need to have and make those choices and then looking at that longer term view which absolutely needs to include availability and coverage and quality and can I ask to what degree is that it may already exist but is there a sort of an overall framework not necessarily your framework but within MSF that provides that guidance on the key information requirements for for example it could be touching on elements around access availability quality uh or is there a need for such a framework or governance framework around data collection priorities and research priorities and activities uh or is that seen as too much of a top down approach should it be more fluid and free and let let it be very much context driven and from the bottom up I don't think such framework exists but I don't know if someone I think realistic I think today there is a lot of efforts being put in improving the health information system so I think over all OCs there is I think all OCs are working on that to try to standardize to be more coherent in the way we collect the data and also to be able to even if the systems are not necessarily exactly the same between the sections to be at least able to compile the data when needed and the however I think even with this so this is just about collecting data from our patients you know so it's not it's patient based either compiling data or individual data but the I think even with those systems what remains difficult is the complexity of the data collection systems and when it comes to emergencies we have really difficulties to even if we have standardized system in place to implement it timely in the field so that's and this is just the part about the patient care and I think the around how we don't have I'm not sure necessarily we need to have standardized approaches on I think we have to look at the context what additional information we need from the population to be able to answer these other questions around the advocacy and the and how to adapt programs based on the population data but I think that then this key issues of the access accessibility coverage I think that has to come and I think it will very much depend on the each context and I think I really think what we have to if we want to get good data we need to be we need to prioritize we need to know what in this context we need and for what purpose to be able to get most out of it sure Francesco yeah I didn't want to give the impression that I you know that I think we should be overly complex I mean I think if you're if you're in the acute emergency phase then really I'm just thinking you know consultation rate right so firstly firstly take some time to establish the population denominator that that can be very very important because unless you know like how many people are in the catchment population it's really difficult to to say anything about performance so that may take maybe a few days sometimes in but but it really it really brings a lot of really really brings a lot of boons but then you know a simple and a simple metric of utilization is the consultation rate if you've got a the population estimate then then every MSF program can tell you how many consultations have done in the last week they should so so really I didn't mean for to suggest you know hundreds of indicators from the very start but a few carefully selected ones I think is probably feasible there is some technical difficulty with for example implementing a DHIS2 which I know MSF and others are looking to use for HMIS in the acute phase because it's a little bit clunky so but that's that's more in the area of I think of software platforms and simplifying that and it's possibly something that can be can be tackled with technology not completely but we're still in a stage where probably most emergency settings we can't we don't disaggregate at all by by age or gender so we're still at an informative stage and I think this is the right moment I think for for the movement to harness those next big questions looking at Uganda for example just over 50 over 60 mortality rates what is the right thresholds what should we define an emergency what are the actions around that that we should be taking and I think these are these are key questions for us now we've we've got by on the under five we've got by on the crude and now now what's next and I think we're going to have to invest somehow in house to to start to look at that to start to look at those bigger groups we're working with an aging population almost everywhere we work so I think we've we've got some some big work and big challenges ahead in that area that's what I was asking is about the question anyway maybe you do need some sort of framework because not every field team is born equal you know some are very inexperienced some are less and two another two another teams yeah that's the point I was going to bring now the human again anthropologist like when I when I when we are saying like people's centre is also understanding who is working in the projects who is in the field and what kind of stress they're undergoing what are the capacities their skills their approaches to the work that we are intending to do because it might change and also the rotation of staff one person there's an article very interesting that talks about humanitarian aid not being evidence-based because it's eminent space it depends who comes it's like I have my experience you know we do this like this like that and then the next person six months later changes everything and I was like okay so that has an impact of course in you know how we do and one person may have an approach the other one another so we work also with tools with standard right procedures with with um framework so let's define one but in a way that is kind of flexible enough and useful enough to be contextualized it's like an oxymoron let's contextualize systematize no let's systematize contextualization an oxymoron but that's that will be the key you know how do we make it systematic but also ensuring that we contextualize and we look for the things that we need to look for in order to be able to operate be in that program whatever that be and be that context whatever that context is not easy but think about the human think about reality that's for me the key thing you know not in a lab or in a vacuum or special situation you know it's like reality let's get not the picture the video where they're coming from what's going on how the situation affected the life of people what is good that is left that we can work with and then what needs to be you know supplied and you know what kind of support we can provide within the reality okay thank you finanda so i'm sure some of you may have some points or questions so i'm going to open it up stefana i think you you had a point that you wanted to make if we could just bring a mic down here uh and uh also one point up there and if you could keep them brief because we only have a few minutes left please thank you that is for francesco uh actually i disagree a little bit bit i mean i think that in during this panel discussion uh something was a little bit neglected and that is i mean we we do need data on the quantity of activities and as you said it's very important to have the target population and then the number of consultation but within msf we tend to forget that we are a medical organization and also the quality of what we do is very important because we can do very many consultations and often most of the people is happy with that but then if you prescribe the wrong drug or you actually you do the wrong diagnosis and i still think that there is a little bit more to do on this side because is that it just you know to put it simple the operational attitude is still prevailing with msf and there is not always the right concern about the quality of the medical on you know of the medical performances that we give thank you so we have one question up there and then also a question from the online audience hi sidwong msf my question is around how data informs operational choices so let me give you an example an urban setting of acute conflict within that setting um there are patients that are visible um for example the war wounded but there are also patients that are invisible victims because the healthcare structures around the violence is just completely crippling around us to what extent and how much more should we be doing um to actually capture quantify and and make visible those victims that aren't necessarily apparent to us thank you for that i mean i think some of the points you certainly both of you have raised at the end yeah i think we need to get out of the facilities for sure and there are ways but maybe we don't have these ways localize i mean no like we need to understand locality and understand what are the existing networks people still live in that reality that for us from our perspective it's impossible we cannot move we cannot go out but they somehow live and they survive in that reality let's listen to them but active listening and understanding the networks understanding what works for them and then we can you know see where msf can you know chip in not only getting the information by getting the connections the community engagement like the key people that not key people are always related to leaders or religious you know key persons but it can be you know thinking from our intervention that is very specific like we are a medical organization we work here with let's say malaria okay let's look at key people for malaria in this community let's try to get there and ask the right questions to the right people sometimes we undermine our national staff like the cleaners the drivers they are people from the community they know a lot of things let's have dialogue with them and not treat them as inferior sorry i'm not being but sometimes this happens there's a division us and them you know just to bring in the other other panel members is it i would just like to comment on that because i'm not sure like in this context i think the what from the the story from ymen that was just presented or what we are doing in iraq today i think you are in the war context we know that there is no access to other health care so as soon as if there if we provide possibilities for taking care of other patients these patients would come so i think just like in the case from ymen or other examples i think by us providing these services we will know that people need them i'm not sure we need i think understanding the context and knowing that there's no other health facilities available should be enough for us to offer these services and then we will see from the patients we have as well what the actual needs are and then we can go more in deep but i think just knowing the context and where we are and knowing that obviously it's not just the war wounded in any population there is women delivering can't acutely ill people whatever the context is sorry so final question i'm afraid uh so that comes tomorrow online audience jane so i think it's a question directed probably to venessa and isa and it relates a little bit it links in with innovation day tomorrow um and relates to the fact do we do we prioritise getting results and data on treatment results and neglect some of the process process data that maybe we could collect to innovate what we routinely do i think we do prioritise results now comes yep absolutely have we i'm trying to think now of some indicators that that outline process and i'm struggling outside of maybe hiv care and tb care i think that might be a little bit on vaccination i guess so yeah no we have some major gaps on performance of our care and i think with that will come a triage of what are the key indicators that we need to capture on that for outside of of our chronic diseases i guess i'm not sure if i really understand what i'm sure we and i think actually i think we should prioritise the patient outcomes because i think that's our key purpose and i think the understanding how our system and that comes a bit to the i think the point of Francesca i think we need to understand how we work and how to optimise the our performances but i think as msn i think our i think if we have to prioritise we will always prioritize towards the patient but then i think we should think how in our routine reporting we we captured the other elements but i guess the process no the way you do it impacts the outcome so you have to understand the process to be able to change it soon enough to have a better outcome i think okay so i'm going to wrap up there it uh we've been advised that it is an opportune moment to take many of these issues forward clearly msf is uh in the lead of being able to take this forward it has the position the advantage of being able to to do that and so in a sense there is a responsibility on msf to keep leading the way in this work uh and to be able to address this oxymoron of systematic contextualisation uh we'll follow up on that next year and your framework


What is up everybody? Jason here for jazzebyscasebrakes.com. We just sold out 2019 Canadian National Treasures Football one box break, pick your team number four. Last box of the case here, guys, and here we go. So Joe got the last two teams, guys, which was the Jacksonville Jaguars and the New York Giants, and here's everybody else in here. Thank you guys, and good luck. All right, we got treasured moments to 75, Marshall Falk. Little chippings are at the bottom, but Rams, that's going to Brett, and then Evan Ingram to 35. Giants, last spot mojo of under Joe. Tyler Lockett's 99 for the Seahawks, going to EA. And we got a DK Mecca, that's a rookie relic there to 99. Another one there for EA. We got NFL gear duels, Irv Smith Jr. and Alexander Matheson. That's for the Vikings and Douglas. Then we got a nice dual relic, two color patches as well, Nick Bolser rookie relic. 49 is going to Andrew. That was actually just refunded today, and look at that. Andrew picked them up and on the board. Then we got ourselves a Trent Dilfer, nine out of 35. Tampa Bay Buccaneers going to Tyler. Then we have a Justice Hill. I'm still there with the Ravens. Little patch autograph to 25. Raven's going to Aaron. And we have a Benny Snell Jr. to 99. Steelers going to Michael Gallucci. And look at this, guys. See, this is why. Still giving it a shot, guys. Last spot mojo, Joe. I know a lot of people are doubting this guy. Tours AC out for the Giants this year, but hey, he's still going to be their guy next year. That is a true RPA there of Daniel Jones, one out of 25. And again, he was one of the bigger quarterbacks of the 2019 class. There you go. Last spot mojo, nobody wanted the Giants. Look, man, just let this sit with you for a little bit. Off-season happens. Maybe they get some key free agents. You know, draft someone big, and then all of a sudden the Giants fans will start talking again, and then all of a sudden people like Daniel Jones again. You know? So not a bad one to hold on to. And there you go, guys, just like that. That was the break. I believe we have more. We have to just double-check. And if we do, we can repost more. And it should be from a fresh case, so all new possibilities for all of these teams. So, appreciate it, guys. JaspysCaseBricks.com.


Rwy'n cymryd ar gyfer gweithio gyda'r mynedd. Roedden nhw'n bosbermau, ac rydyn ni'n gwaith cyfreid, ac mae'n edrych yn gallu'n gweithio yr Hollwyrg validatedr. Mae Feon Actynd fel GAB anhins i'r dŵr, mae'n gweithio'r hollwyr phynol a gweithio'r gweithio'n gweithio'r hollwyr. Yn ymgyrch yng Nghymru â'r roli, mae gennym yn cyflwyng ynghylch yn ei angen ar gyfer y wneud. A sy'n bod yn dechrau yng Nghymru, As we met in the ISDROFISIS six years ago and really talked in depth about what does the right construct look like, how do we really want to build an industry standard for the industry to use and we really got down into the details of this idea of building blocks that allows us to really define the entire industry and the financial products that are used in the industry. talking about what is the CDM, but as a quick summary it really is an industry standard that defines all the financial products that the financial industry trade, but it goes one step further and also defines how we actually process life cycle events for those trades and positions. Actually earlier in the year I was at the ISDA AGM and the chairman of the CFTC said we really need clear data definitions and machine readable code. And I think that's absolutely what the CDM does and those of you who have been involved in the recent regulatory go live earlier this week as which I have been. Hopefully you'll start to see how we can use the common domain model to really help drive that. The other big benefit we wanted as we looked and started the CDM was how do we actually capitalise on the new technologies out there so blockchain and DLT and hopefully you'll start to see as we talk through over the next 20 minutes how that can be used as well. Before we get started hopefully you can see on the screen behind us we have three trade associations coming together so ISDA, ISLA and ICMA. So perhaps I'll get you all to introduce yourselves and then we'll get started. Thank you everyone. Hi I'm Georgina Jarrett from ICMA that's the International Capital Markets Association. We work very closely with CIFMA here in the US and look after the debt capital markets industry globally. Hi, good morning everyone. My name is Alan Milligan and I'm representing ISDA this morning classically at the derivatives side of business. My role at ISDA is Head of Data and Digital. How are you everyone? I'm Adrian Dale. I'm the Head of Regulation, Digital and Market Practices at ISLA which is the Security Learning Association. Excellent so let's get started. Perhaps you could take us through what's excited you most about the journey so far with the CDM perhaps we'll go in chronological order so let's start with you Alan. Thank you very much Theon. ISDA's been part of the CDM journey for five years. It's obviously not new to ISDA and it's particularly exciting where we find ourselves now with the CDM. It's extending the crosswalk coverage of CDM beyond just derivatives so securities and asset lending with ISLA, ICMA and more recently Finals. Over the last month we've seen some very exciting developments. We've seen a real world industry implementation of digital regulatory reporting. I think it was a press release some weeks ago from a member firm and that's an end-to-end test now in production for CFTC regulatory reporting. Of course the press announcement last week from Goldman Sachs. Perhaps you can touch upon that later Theon. Great, agent. I forgot what the question was there for a second. Luckily I've got notes. So our journey was a little bit different. We started off in 2019 with a series of papers called The Agenda for Change and we were looking at how the market was evolving and also the evolution of the technology at the same time and how we can combine those two aspects to improve the way the market operates. The conclusion was that we needed to have of course standards which is probably the most used word you're going to hear today across everything. Looking to what our fellow associations were doing as well it was quite obvious that that's where we needed the direction we needed to go in. So all of those papers actually are online and we produced another one just very recently actually. It's on the ISLA in Mia website and you can see the work that we've been doing on that and how we've evolved to where we are at the moment. The exciting thing, that's the question right? So the exciting thing is I've been in the industry for a long time and there's just problem statements coming out all over the place. To address those things the way that we've been doing things historically is looking at an individual problem statement solving for us and then just creating more complexity. So the exciting thing now is where we have standards that we can start actually working to solve all of those things and that's the future that's going to respond to. Excellent, Georgina, how about you? Last but not least, ICMA has just very recently, well not so recently but over the last couple of years sort of been working hard to add the bond and repo transaction life cycles to the model. That business for those of you who know about it is very very fragmented and actually hasn't done a lot of whole scale transformation and to end on that trade life cycle. So there's gallons of opportunity. I think excitement and the words modelling and data models are sometimes quite difficult to marry out but we are genuinely really excited to be part of this initiative and indeed actually working together as three trade associations to simplify and standardise transactions that really are important and as we all know create massive cost and complexity that just isn't necessary. So yep, we're very very happy to be part of that. Perhaps I'm one of those geeks that gets super excited about model. No, I shouldn't actually say that. Your decision is big so I don't know those but... Excellent. I'll add a tagline into that because it's an important thing of what we're all doing. It's the market building something for the market which is something that hasn't happened before. There's normally a vendor or a firm doing something and at the same time that we're doing that it's called for by the regulators and their tagline from the European side anyway is what can we do to help so that shows that the regulators are really involved, invested in what we're doing as well. I think there's definitely the problem statement out there that we need to solve and I think this absolutely is the solution. Perhaps let's look a little bit into the future then. What do you hope for the CDM over the next couple of years and perhaps also touch on the impact that should have for the financial industry? Georgina, let's start with you. I think it's hugely why we're here actually. The associations have built with a lot of input from all of our vast membership between the three associations so the banks, the asset managers, the investors in our case, the issuers, et cetera, all the technology firms, some of the law firms and all the other participants in the market. We've built a model that we believe is a pretty good start to show how these transactions work. If we could all rewind the entire evolution of the industry and start again then maybe we'd have all done it together the same way and then our regulatory pain would have been a lot less. I think the exciting part now is getting it out into the community which is what this is all about. I'm getting people to actually start to use these models and properly embed them and as a result more brains makes it better, richer, more effective, more efficient. This is real testing to all of us techies. We're actually going to test it in the real world so that's the next step from our perspective and it's great news I think. Great and Alan perhaps you've had the longest so what's the next six years? You know what you're doing. I think the key statement is that why are we doing CDM and some of the use cases like DRR? The key proposition is we're doing it to maximise cost efficiencies through industry mutualisation. This is not theoretical. We demonstrated that in the last year with digital regulatory reporting DRR. We've seen and witnessed those cost efficiencies. This is a great opportunity with the other trade associations to extend the breadth and depth of CDM beyond just derivatives to new asset classes. Great and Adrian. I want to go a bit about those problem statements I mentioned earlier on. We've got regulations, we've got sustainability, we've got the high cost of operations which is to the point in the panel earlier that Colin made a point about why should they be contributing. There's a business case in there because the cost of all of this infrastructure at the moment is enormous. There's a lot of focus on it from firms and also what's the solution it's actually to come up with these standards. There are too many standards so there are lots of people creating their own standards at the moment and actually it needs to happen in a common place which is the trade associations and of course on Finos as well. There's two examples I want to give for the future that we can look at. A common practice in financial firms is that you have to do a transaction and you have to do lots of other transactions to support it to get to that point in the future where we can do all of these transactions and it can all be expressed in a single sort of standard and then that means you get this interoperability between all the platforms internally and externally. Internally within a firm they've got a big mess at the moment trying to connect all the different platforms together and that needs to be solved and externally I mean about regulators for instance or talking to your counterparts or interacting with exchanges. The other thing is that to get away from this paradigm we're in at the moment where there's a regulation we take SFTR which is a European one but you've got the 10C1 which is a similar sort of thing where the regulator says I want all this of all these fields and that actually isn't the right way to do it it should be the market saying what our transactions look like and then the regulator saying fine shopping list I'll take out of those things. The future is that we don't spend five years trying to figure out what the regulator wants we just say this is how it operates and they're satisfied. Yeah and I think the other one and Alan mentioned it a little bit before and I sort of talked about blockchain and DLT the other space is how do we start to really use the technology that's out there in the industry and just two weeks ago I think it was GS announced the launch of our GS DAP so the digital assets platform and we did our first bond insurance on there on the chain and the interest rate hedge for that actually uses the CDM as the model and so that's sort of the first implementation for us of the CDM out there on blockchain and DLT so definitely starting to see this adoption happen when you've worked on something for six years it's really exciting when it starts to actually come to fruition so that's really exciting. We've covered a little bit now about the CDM but we are at an open source conference so perhaps we should turn and talk a little bit about that so perhaps take us through why the trade associations have decided to actually open source the common domain model at this stage in its journey and Adrian let's start with you. So trade associations have a sort of more altruistic view I suppose in the way that the markets operate if we take example of what we do as trade associations we create apart from looking after legal agreements we also create best practices such as decorating procedures I think it's the other term that's used and that to be a market standard it needs to be out there for everyone to look at there's no point in it being ring vendors so it made complete sense to go through some process to distribute that more widely to create that standard and it's exactly what members were asking for we've had it time and again over the past decade people saying where's that conversation going to happen it has to happen in an open place so that we can all adopt it but they need to have the feedback into it as well so that people can be engaged with it and it's open for everyone to use and it creates a standard not just for our members Yeah great Georgina Yes so I mean these things are never developed for commercial gain I mean nothing that the trade associations ever do is on that basis they are not for profit organisations albeit not arguably not a charity but let's call it a charity for the financial services industry and I think actually we've touched on regulation it's quite important that we're now being seen as even more important between the industry so representing the whole industry in this case three industries or three parts of our financial services industry on their behalf so taking this to open source as I mentioned before is really getting it to live, getting it to fly there are three of us even though we're all independent of the actual market participants themselves but there are now three of us so we need to put it somewhere where it's independent of all three of us as well I think that's the reason we want it for open and free use and that's open source really isn't it? Yeah great, Alan? Yeah I think open source offers a neutral third party source of contributors beyond just the typical participants you might see I think that brings great value and it also increases transparency to the regulatory community globally and I think that's very important having that transparency and the neutrality of those contributors there's no commercial proposition we're trying to do it for good cause for good cause and good reasons so I think that's a core benefit Yeah I think it is that the adoption of a standard is the only way that actually we gain the benefit from it so for me and some of the reasons why I love working in the open source community is it allows us to get more participants and also to therefore accelerate the build of these things as we get more people to actually contribute to it and hopefully it makes all of you guys feel a bit more responsibility for what's going in there and so as it starts to get adopted you've got a little bit more of a confidence in what's on there so super exciting I'm sure there's lots of people out here and I know I've heard a couple of people talking about it earlier on perhaps we should just touch on how did you land on actually using fin-off to open sources Alan I don't know if you want to take that one So thank you three trade associations were involved in the selection process the rigorous formal RFP process with six candidates after an extensive process of scoring we decided I think unanimously in fact it was unanimously on fin-off I think some of the contributing factors were cost efficiency reputation and legacy especially with the history of fin-off and the Linux foundation and transparency it's a very transparent governance process which I think helps with communication with regulators Adrian anything to add? I just love the sound of it the non-profit organisation we're non-profit organisations yes we had to go through the RFP process because we had to have that transparency to our members because that's where we're funded from so there was great news that we ended up where we are using fin-off perfectly aligns with our values as well which is why and it's just a great opportunity Georgina anything to add on you? Just really touching on the fact that the associations don't naturally work together actively very often actually so this is quite a truly groundbreaking project because we all look after our individual businesses but actually the ability through an RFP to aid the process properly but also B come to a joint completely agreed well-governed decision is very very important otherwise we feel like somebody's made a decision without the other party having full input so I'm going to contradict You're going to contradict? Just a little bit so especially on regulations where there's no point we're very similar related in terms of the way our markets operate and where we especially on something again like regulations it makes sense for us to align so we have been aligning on certain regulations to make sure that our best practice is going to align Fair adjustment Adrian but it's give and take though sometimes you come up with better ideas and they get adopted into ours actually with a very large body of trade associations on some of the regulations that are going through at the moment there's like 10-15 of us get together globally and we agree what the standard should be just because it makes sense to do it like that not for any of the fairest reasons I think it's a big thank you if I can do it on behalf of the financial industry that you can't bring together to bring this into one place so I think that's great If you're interested in hearing more I know we've touched on little bits here but there's so much more going on today about the CDM you've heard a little bit about it I know there's a session that will look at the history of it so if you're interested in what happened over the last six years there's a session happening on that there's also going to be showcases of how it's being used in the industry you've heard from a couple of us but actually there are other people in the community that are doing it so please go and find that session as well perhaps a little shameless plug from me so my role within Finos is also as co-chair of the financial object SIG and over the last couple of years we have been contributing to the CDM through that SIG but we have great ambitions of what more we can do now that sort of this launch is happening and so if you're interested in anything we've spoken about please do come and find me or my co-chair Ian is somewhere around in the room the back over there please do come and find us we would love to hear how you'd like to get involved or how you'd want to see this sort of move forward over the coming years so please do come and get in touch perhaps to finish us off because we've spoken about quite a few things can you each give three words that you want people to take away from this session today and as they go and sort of enjoy the day to Regina it's been corrected by Adrian in all seriousness it's all about collaboration us and the whole of the Finos community foundational and then in bed and deployed that's four but they're the same so in bed and deployed excellent Adrian so I'm going to be cheeky and I'm going to try twice my first attempt is adopt our CDM that's an obvious one that's obviously to financial firms and regulators as well and then we're going to use some sort of standards sort of terms like standards future and efficiency great and Alan to finish us off I think I've touched upon it mutualisation of effort which also ultimately means cost several words there that's not quite one but hopefully that suffices industry standardisation I think is a key part of the of the remit of trade association and machine executable interpretation that was loads of words I've cheated that's why I put them at the end excellent well thank you so much to our esteemed panel thank you for being here and hopefully you can all see and we'll get involved throughout the day thank you