Business Problem

The project addresses the missing implementation rigor needed to implement an industry standard business component model for digital banking in production environments. You can see a demo of Mercury in action in this video.

Proposed Solution

Mercury provides architectural blueprints for the implementation based on one banking industry standard, the BIAN Semantic APIs. It includes a framework to automate the CI/CD pipeline.

The project illustrates the exchanges needed for independent services to modularly compose into customer journeys.
For developers, it provides informational direction and pre-defined accelerators for cloud native development

Current State

Three of the six key data exchange types are explicitly defined, namely:

Real-time: An immediate response is expected. Caller waits on the called Service Domain
Best-time: The response is expected in a few second, caller may ‘multi task’ activity
Notification on Update: A timely/instant notification – triggered by a status update as a prescribed to service

Working groups are being established to formalize accelerators for the additional 3 not currently documented, which are:

Instant/Concurrent: The called and calling Service Domain need to complete activities in parallel
Delayed Response: The response expected in the future, typically after some manual intervention. Caller monitors for response
Scheduled/Synchronized: Scheduled broadcast synchronization of non-volatile information as a prescribed to service

Project History

Developed internally at Red Hat using open source licensed APIs from BIAN atop Red Hat’s open source project portfolio, Mercury has been under active development for the past six months. The project has seen interest and is in POC phase with two Red Hat customers and given its early traction we would like to open the code to the community for their own use and augmentation, as well as to get wider feedback on our opinionated approach to these business problems.

Existing Materials

FINOS staff (Mao) has access to our private GitHub repos.

Development Team

Marius Bogoevici, Red Hat, Chief Solution Architect, marius@redhat.com, GitHub: mbogoevici (maintainer)
Rafael Marins, Red Hat, Technical Marketing Engineer, rmarins@redhat.com, GitHub: rmarins (maintainer)
Sadhana Nandakumar, Red Hat, Specialist Solutions Architect, snandaku@redhat.com, GitHub: snandakumar87 (maintainer)

Contribution process (v. 1.0, last updated on October 2, 2020)

Below is the list of tasks that FINOS Team and the contribution author go through in order to complete the FINOS contribution process.

Please do not edit these contents at contribution time!

FINOS Contrib POC

[ ] Identify and Assign FINOS Contrib POC

Identify project meta (Lead: FINOS Contrib POC, Support: FINOS Marketing)

[x] Project Name - Mercury
- [ ] Assess current trademark status
- Define new project name (if applicable)
- [ ] Design new project logo (if applicable)
- [ ] Trademark new project name and logo (if applicable)
[ ] Category and sub-category (for FINOS Landscape)
[x] Existing code or new Github repository
[x] Existing code releases (and which artifact repositories are used) - No
[x] Team composition: lead maintainer and other maintainers
[x] Meetings (existing/yes/no) - No
[x] Meeting minutes, agenda, attendance tracking (existing/yes/no) - No
[x] Continuous Integration (existing/yes/no) - No
[x] Documentation website (existing/yes/no) - No
[x] Define project slug - mercury

Maintainers, contributors and CLAs (Lead: FINOS Contrib POC, Support: FINOS infra)

[x] For each maintainer identified in the previous step, collect: the following info:
- Fullname
- GitHub username
- Corporate email address
[x] Identify other existing contributors (assuming there's a contribution history (eg Git history)
[x] Check if maintainers and other contributors are all covered by FINOS CLA
[x] Engage with FINOS Legal team to figure out what’s needed to cover all maintainers and contributors with FINOS CLA
[x] Reach out to contributors and employers to coordinate CLA signatures
[ ] Invite GitHub usernames to GitHub FINOS Org
[ ] Create <project-name>-maintainers GitHub team and invite users

Project Communication Channel(s)

[ ] Ask maintainers which communications channels they'd like to use and if more than one are needed. These may include
- [ ] Creation of one or more project mailing lists (e.g. general@, or dev@ and users@)
- [ ] Creation of one or more Slack or Symphony chats for the project
[ ] Create the identified communication channels during infra set up
[ ] Link communication channels linked front and center in the project README.md.

Code validation (only if code is contributed) (Lead: FINOS Infra)

[ ] The codebase doesn’t have HIGH or CRITICAL CVEs across direct and transitive libraries (WIP - first scan done)
[ ] The codebase doesn’t have any unfriendly licenses across direct and transitive libraries (WIP - build failures prevent scanning)
[ ] (optional - if a build system is provided) The build process runs successfully
- [ ] finos-admin is Admin of the GitHub repository to transfer
[ ] The codebase doesn’t include any patent or copyright that conflicts with FINOS Governance and bylaws (to be validated with FINOS Legal team)
[ ] The codebase complies with FINOS Project Blueprint
[ ] All incubating criteria are checked and documented below

Voting (Lead: FINOS Infra)

[ ] Assign issue to Executive Director (@mindthegab) to trigger voting
[ ] (optional) at the discretion of the Executive Director: bring projects to the Board for additional socialization and approval
[ ] FINOS accepts the contribution (and the contribution process can move forward)

Code transfer (Lead: FINOS Infra)

[ ] Check GitHub repository transfer requirements:
- [ ] finos-admin has Admin to all repositories to transfer
- [ ] finos-admin ia allowed to transfer repositories out of the org
- [ ] if the repository is owned by a user (and not an org), the user must be able to transfer the repository to finos-admin
[ ] Transfer all code assets as GitHub repositories under github.com/finos

Infra setup (Lead: FINOS Infra)

[ ] Add project to metadata
[ ] Update release coordinates to include finos
[ ] Add identities, orgs and affiliations to metadata
[ ] Invite GitHub usernames to GitHub FINOS Org
[ ] Apply project blueprint contents - see ODP docs
- [ ] ensure that the proper project governance is in the CONTRIBUTING.md file
[ ] Update project badge
[ ] Update code namespace (best effort)
[ ] Add logo to FINOS landscape
[ ] Add project maintainers emails to finos-project-maintainers@finos.org list
[ ] Add project maintainers GitHub usernames to the project-maintainers Team
[ ] Enable security vulnerabilities scanning
[ ] Enable meeting attendance tracking (optional)

Define support model for project constituents (with special attention to ticketing systems, SLAs and support across timezones)

[ ] Developers/ Contributors
- [ ] internal developers (i.e. developers from the contributing organization)
- [ ] external developers/ contributors
[ ] Consumers

Announcement (Lead: FINOS Contrib POC)

[ ] Work with FINOS marketing to send out announcement to announce@finos.org , checkout announcement template at https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/83034172/Contribute
[ ] Notify FINOS Contrib POC and FINOS marketing manager once the announcement has been sent out (FINOS infra)

Press Release (OPTIONAL) (Lead: FINOS Contrib POC)

[ ] Identify quotes for press release
[ ] Draft press release
[ ] Send embargoed press release to reporters
[ ] Coordinate social media promotion of the press release with FINOS marketing
- [ ] Post on FINOS social media
- [ ] Post on LF social media

Onboarding and training

[ ] FINOS Project Governance
[ ] FINOS Project Lifecycle
[ ] ODP Training

finos / community

Project Contribution and Onboarding - Mercury #76