Draft proposal on the organisation of the CCB
mjbrichards opened this issue · comments
The attached is a draft document with proposals for how a multi-API change control board might be organised. Please feel free to comment here.
Multi-API CCB Structure.docx
Please find some initial comments below. In general, I like the proposal of having special interest groups.
Open API definition
- The name of the existing API is not "Open API definition". This name is very generic and could mean just about any API. The name of the API is "The Open API for FSP Interoperability" (or just simpler "FSP Interoperability API").
The Mojaloop design authority has proposed that new extensions of Mojaloop functionality, such as PISP initiation of transfers, settlement and support for cross-border transfers and foreign exchange, will be implemented using separate APIs rather than extensions of the existing Open API definition.
- I don't see why there should always be separate APIs. There should in my opinion be a decision each time if new extensions are valid in an existing API or if there should be in a new API. For example, cross-border transfers and foreign exchange should not (or at least does not have to) deviate much from the existing FSP Interoperability API. Depending on the required changes, it may be a part of the existing FSP Interoperability API.
The CCB will be responsible for defining best practice in API development and documentation, and for satisfying itself that SIGs have followed best practice in the development, modification and publication of their APIs.
- The current CCB is mostly made up of FSPs and their technology providers, meaning people who might not be experts in Mojaloop itself. I would think that there will be Mojaloop APIs that do not concern FSPs. It feels a bit strange that the existing CCB will define best practices for Mojaloop APIs that are not related to FSPs. In my view, this CCB should be responsible for all Mojaloop <-> FSP APIs (which currently may be all or most of the Mojaloop APIs), and some other CCB can be responsible for other Mojaloop APIs. Then there of course needs to be cooperation between these CCBs to establish common best practices and documentation so that all Mojaloop APIs can work in a somewhat similar way.
The CCB will be the final authority for approval of APIs. The grounds on which it may reject proposed APIs, or ask for them to be revised, will be restricted to the following:
- What if for example the SIG for PISP comes up with an API that would not work in a good way for FSPs? Then there are according to the list no way for the CCB to request for a revised API as long as the proposed API adheres to the best practices, documentation standards, or efficiency recommendations. I would like the CCB to have some more control of the API. For example the PISP API, there is not much use in the API if the FSPs cannot adopt it in a good way.
The Open API definition is actually the APIs for FSP interoperability. I am unable to understand why there is a need to have separate APIs for cross currency, cross border etc. and not handled by extending existing APIs. The APIs related to FSP transfers should be handled by current CCB group. If SIG creates an API, that do not work with FSPs, it may create issues. Other APIs can be handled outside CCB. It would be useful to have some specific examples.
First of all, please accept my apologies for miscalling the current API. However, I want to ask whether this is an appropriate name for it going forward. If, for instance, we are to have a separate API for PISPs to use, then I think that PISPs are a kind of FSP: the fact that they're not deposit holders doesn't mean that they are not providing financial services. So it might perhaps be more appropriate to call the current API the Open API for FI Interoperability, or for Funds Transfer, or some such. I don't have any strong opinion on this, but I do think it should form part of our discussions.
Second, let me pick up Ritvik's point. The reasons for proposing separate APIs in the first place were as follows. First, there are some OSS APIs which don't affect FSPs directly at all: the Settlement API is an obvious example. As Ritvik says, these could be handled outside the CCB; but the fact is that they're not being handled at all at the moment, and we thought it would be useful from the perspective of the community overall to have a governance structure which would bring them into the same context as the InterFSP API. Second, it was suggested as part of a CCB discussion of the PISP requirements that it might be more sensible to partition the PISP interfaces into a separate API. This would mean that DFSPs, or schemes, which did not want to support PISP functionalty would not need to trouble themselves with the API at all. In addition, the current expectation is that a DFSP who wants to support the InterFSP API needs to commit to supporting all the endpoints of the API. Splitting the APIs by role would allow us to continue to support that principle.
After this option was suggested in the CCB, it was discussed from a technical perspective in the DA. They too found much to recommend it in terms of segmenting processing and efficiently checking whether a participant was allowed to work in a particular role or not, and the proposal was therefore approved by the DA. I think, therefore, that the CCB would need an outstanding reason now to go back to the DA and say that its original proposal was withdrawn. That's not to say that it couldn't happen, of course; and I'm happy to re-open the discussion if Ritvik (or anyone else) has a substantive objection to the existing proposal. But I don't think that such an objection has been raised at present, unless I've misunderstood.
Next, the question of how we should decide on whether a new API is required or an existing API should be extended. I agree with Henrik that a decision should be made on whether to create a new API or extend an existing one. The questions are, I take it, how should such decisions be made and what should be the criteria for making them? We should, I suppose, table this as an item for discussion at the next CCB.
As for the question of the definition of best practice: I was expecting that the existing CCB, composed as it is of technology providers and implementers, would become a SIG. The new CCB would contain representatives from all the SIGs and some other members, and would be responsible for questions that need to be settled centrally, including best practice. I'm open to other suggestions for how this might work best, of course.
Finally, there's the question of how to ensure that all the parties to an API are happy with the way it works. My feeling about the example you raise, Henrik, is that it would be best approached by having DFSP representatives on the SIG rather than by having a regulatory approval regime, which might delay decisions until a later stage in a project when the ideal all round would, I think, be to arrive at the earliest possible moment at an API which was attractive to all the stakeholders. I don't have any settled views on what the best approcach to that might be: again, we should discuss it at the next meeting. But you're absolutely right, Henrik: it will be fundamentally important to the success of any project that the API changes it requires are palatable to all the parties who will have to interact using the API.
I don't like changing names of existing APIs which are already in production use (unless something fundamental in the API would change). To me, the most logical would be to name the API covering the PISP functionality "PISP Interoperability API" or similar to distinguish between the two.
Regarding your (@mjbrichards) second and third paragraph above: As far as I can tell from the comments above neither Ritvik nor I have suggested that PISP functionality should be part of the FSP Interoperability API? Or was this part of the discussion in the meeting that I unfortunately missed last time? My only point is that there should be a discussion each time regarding if new functionality would fit in a new API or in an existing API. I still want the PISP API to be a separate API as they cover two different functions (one being a back-end API to handle transfers between FSPs, one being a front-end API for end users to handle their financial accounts via a third party).
Having the current CCB as a SIG for FSPs sounds good, as it would make the best use of the knowledge in this group.
Of course it would be great to have representatives from the FSPs in the PISP SIG as well to be able to handle key decisions early on. But as always, it is a matter of prioritization in our respective organizations. To me, it is a fundamental key to success of the API to have participation of the FSPs and their technology companies in the PISP SIG. Without any FSPs that would like to implement support for the API, the API will never be successful. If one of our FSPs would like us (Ericsson) to implement support for the PISP API, then I'm pretty certain that we will participate in the PISP SIG as well.
Here's the updated version of the CCB proposal. All comments are welcome. It now appears that we have until the date of the convening to come to a final agreement. As you may have seen, an earlier draft of this document has been posted on the Mojaloop Community Council's Discourse page (http://community.mojaloop.io/) and comments have been invited. This discussion will close on the 8th of October, and I guess we should probably arrange to hold a CCB on Tuesday, October 13th for a final vote on the proposal. In the mean time, your comments would be most welcome.
Multi-API CCB Structure v1.2.docx
Thanks Michael,
Please find some initial comments after a very quick read in front on the CCB meeting today.
- The following two parts of Section 4.1 sounds like a repetition to me, but not having the exact same meaning. At least I interpret them as having some slight deviations between them. The second version explains the process better, including defining what an initiative means.
Each new initiative which will result in the definition of one or more APIs will define those APIs through a Special Interest Group. We envisage that, for new initiatives, a SIG will initially be formed from among the design and development teams working on the initiative, and that it will subsequently be expanded by recruits from organisations which have a particular interest in the area covered by the API(s). ...
SIGs will be formed as a consequence of new functional initiatives being adopted by the Mojaloop community. However, not all functional initiatives will require new APIs to be developed, and hence new SIGs formed. The decision on whether or not a new functional initiative requires a new API will be taken by the CCB, to which requests for new functionality will initially be directed. Since the CCB will contain representatives of all the existing APIs, it is the natural forum in which to assign new functional areas to existing APIs, or to mandate the formation of a new API and hence a new SIG. The responsibility for forming the SIG itself, if the CCB decides that a new one is needed, will devolve to the group which is developing the functionality.
- The following gives a lot of power to the convenor (from Section 4.1). I would assume that there would be some kind of discussion in the SIG, instead of just having the convenor to decide.
The convenor of that particular SIG will then make a decision to have the registrant join as a non-voting member.
- Should the following text be a header? It seems kind of misplaced right now..
How and when should new SIGs be formed?
-
The updated text regarding how new interested parties can join a SIG sounds much better.
-
In the charter, the following is mentioned: "The Technology Consultant and the Program Manager will be non-voting CCB team members." I assume that these two roles are Michael and Sam in the existing CCB. Will this be the same in the new CCB, that your roles are non-voting? Otherwise, to be frank, it gives a lot of voting power in the CCB to Modusbox (please note that I'm not saying that it is a good or bad thing, I just want to know how the CCB will work). The current proposal does not really mention how voting in the CCB would work as far as I can find now.
Please find my additional comments regarding the draft proposal below. I have not reviewed the charter as I expect this to be updated.
- I would like to have a confirmation what the respective responsibilities the groups DA and CCB will have in the future, based on the two parts below of the document. Is it a correct interpretation that the DA is just proposing how anything related to APIs could work, and it will be up to the CCB to make the actual decision if it involves APIs? Because I would not like to have two groups that have very similar responsibilities. Reading the related "Proposal to Restructure the Design Authority", this document is pretty clear on what that group is not doing, but this seems to be mostly decisions regarding business, not anything with APIs. To summarize, it would be great to document the exact relation between these two groups and their responsibilities so that we do not end up with two groups making different decisions in related questions.
From Section 2:
The Mojaloop design authority has proposed that new extensions of Mojaloop functionality, such as PISP initiation of transfers, settlement and support for cross-border transfers and foreign exchange, will be implemented using separate APIs rather than extensions of the existing Open API definition.
From Section 4.1:
SIGs will be formed as a consequence of new functional initiatives being adopted by the Mojaloop community. However, not all functional initiatives will require new APIs to be developed, and hence new SIGs formed. The decision on whether or not a new functional initiative requires a new API will be taken by the CCB, to which requests for new functionality will initially be directed.
- I don't understand why it should be the CCB that is responsible for proposing the change in the text below? In my opinion, it is one or more SIGs that will see a need to update the common object, propose the change towards the CCB, then the CCB will handle the change request and make sure that the change is aligned between the SIGs using the common object.
When there is a need to modify the structure of a common data object, the CCB will be responsible for proposing the change, ..
- Related to the last bullet in last comment, it would be good to include some text regarding how the roles of Rapporteur and Convenor of the CCB are appointed (this could be for example appointed by the Mojaloop Foundation, or something similar) . For all other roles in the CCB, it is easy to understand how they are appointed as they are either working in the Mojaloop Foundation directly, or as convenors of one of the SIGs. It would also be good to know the responsibilities of the Rapporteur, this could be based on the text in the charter for the technology consultant if that is still valid.
Just two more comments for now, sorry for spamming the thread..
- To be nitpicky and get the history correct regarding the paragraph below, it should include that the PISP API was originally suggested to be in a separate API in this CCB (#62 (comment), or even earlier in #58 (comment)). The paragraph below make it sound like the proposal came originally from the design authority and downplays the role of this CCB.
It appears likely that the future of Mojaloop will contain multiple API definitions. The Mojaloop design authority has proposed that new extensions of Mojaloop functionality, such as PISP initiation of transfers, settlement and support for cross-border transfers and foreign exchange, will be implemented using separate APIs rather than extensions of the existing Open API definition.
- Related to earlier comments regarding voting, are all the Mojaloop Foundation members supposed to be voting members of the CCB? Four members out of 12 (or 8 if you only count the current number of SIGs that has a convenor) is a fairly large share of votes for what I hope should be a community driven committee. In the charter, the Gates Foundation is supposed to have two votes where an agreement can't be made unanimously. I would suggest something similar for the Mojaloop Foundation in this CCB.
I've prepared another draft, based on the comments I've received. I've also made some revisions based on the fact that we now have a product manager. In particular, I've assumed that she will be an ex officio member of the main CCB, and will be responsible for representing the interests of actual and potential implementers, so we shan't need a separate implementers SIG (that will be the product group that she will, I assume, chair...) Anyway, let me know what you think.
Thank you, Michael. This new draft seems to address all of my comments. The only thing left is the documentation of the exact relation between the DA and the CCB, and their respective responsibilities so that we do not end up with two groups making different decisions in related questions. But I'm fine with having this documented elsewhere, as long as it is clear what the responsibilities are.
Thank you Michael for the updated proposal. It addresses all the queries.
Closing this issue as the organization of the CCB has been changed according to the proposal.