Sidebar
3. Risk Due to Poor Community of Interest (CoI) Governance
Governance of a Community of Interest (CoI) just does not happen by chance. It must be a well-thought-out formal organization with strict Policies and Procedures in place to guarantee the whole community is represented and can help formulate the solution or in this case, solutions to solving the Community's problem (i.e., U.S. CBDC). Too often, the Governance is considered by using Open Source Software (OSS). Although having OSS Projects can have an important role in the Governance of a project, it is primarily focused on the development of Software. Yes, the CBDC will be predominately software, but there is much more that needs to be governed than just software.
Examples of non-Software things the U.S. CBDC Community of Interest might need to control:
1. Legal Documents such as
2. Guides
3. System and Software Engineering documents such as:
- Models
- Testing regime ( Unit Testing , Integration Testing , End-to-End Testing (E2E Testing), Smoke Testing , Sanity Testing , Regression Testing, Acceptance Testing , White Box Testing, Black Box Testing , Interface Testing , Interoperability Testing , Test Data, Test Plans and Test Results )
In addition to all these requirements for Governance, the Governance Model itself must reflect the “distributed nature” of the participants in the CoI itself. So far, we have identified 33 different Oversight Authorities that could be part of the CoI (see Table ##REF:summaryStakeReg##, and each one needs to be able to have a voice at the CoI forum or Consortium. See the OMG DIDO-RA discussion of Governance.
The U.S. CBDC will most likely be a System-of-Systems (SoS) or even an SoS of other SoSs. This means that there probably needs to be a hierarchy of CoI not unlike that of the Federal Reserve itself. For example:
1. The U.S. CBDC CoI might be an Ecosphere 2. The development of U.S. CBDC ATM equivalents might be an Ecosystem
- The Development of a U.S. CBDC ATM machine itself might be a Domain
- The Development of a U.S. CBDC ATM network might be a Domain
3. The Development of a Bridge between the ACH and the U.S. CBDC might be an Ecosystem
| CoI Type | Description |
|---|---|
| Ecosphere Community | Ecosphere Community is the highest level Community of Interest (COI) that encapsulates DIDO Ecosystem Communities and DIDO Domain Communities. The Ecosphere usually provides high-level requirements and some funding for the administration of the other CoIs. The Ecosphere's role is to act as a coordinator of the Ecosystems and to provide a framework for all other CoIs to establish working agreements such as Memorandum of Agreement (MoA) or Memorandum of Understanding (MoU). The Ecosphere is often the only CoI that is recognized as a Legal Entity with legally binding Charter, Bylaws and official Policies and Procedures. Often the Ecosphere control Intellectual Property (IP) rights and allowable Copyrights that are acceptable for the Ecosphere and the Domain. |
| Ecosystem Community | Ecosystem Community is the midlevel level Community of Interest (COI) that encapsulates Domain Communities. The Ecosystem has a Sub-Charter approved by the Ecosphere CoI. The Ecosystem usually relies on the Ecosphere for By-Laws and Policy and Procedures (P&P) but can provide addendums that do not conflict with the Ecosphere. The primary role of the Ecosystem is to coordinate the activities of the Domains which fall under its jurisdiction. As a general rule, the Ecosystem does not actually create anything but acts as the integrator and coordinator of all the Domains it is responsible for. The Ecosystem may have more restrictive Intellectual Property (IP) Rights than the Ecosphere. It can only subset the Copyrights allowed by the Ecosphere. The Ecosphere's role is to act as a coordinator of the Domains, however, one Ecosystem can also have a Sub-Ecosystem that it is responsible for. The Ecosystem can have its own bug tracking system that covers integration issues. The Ecosystem is responsible for all Integration Testing. |
| Domain Community | Domain Community is the lowest level Community of Interest (COI). The Domain has a Sub-Charter approved by the Ecosystem Community. The Domain usually relies on the Ecosphere for By-Laws and Policies and Procedure (P&P) but can provide addendums that do not conflict with the Ecosphere. The primary role of the Domain is to produce a product that meets the Functional and Non-Functional Requirements of the Ecosystem and the Ecosphere. As a general rule, the Domain actually builds or deploys things to be integrated into the Ecosystem. The Domain may have more Intellectual Property (IP) Rights than the Ecosystem. It can have a subset of the Copyrights allowed by the Ecosystem. The Domain's role is to build products as per the requirements and maintain products according to the Bug Tracking System. The Domain is responsible for all testing at the Domain level (See: Testability). |
- Note: One way within the U.S. Government to create an Ecosphere, might be to use the Other Transaction Authority provisions within the U.S. Code.
