Banco do Brasil (BdB) is fully automating the process of building an MLOps pipeline that uses CP4DaaS as one of theirwork environments. Such a pipeline relies on administrative functionalities and execution triggers that are directly
linked to their on-premises environments (such as internal identification/authorization policies, archive storage,
production inference servers for trained models, etc). Such on-premises components thus do rely on the provided
CP4DaaS APIs to automate tasks critical to the overall pipeline operation. One such automation has to do with the
creation of the working environment a team should have when tackling a machine learning problem. Such a working environment is
comprised by (but not limited to) a CP4DaaS Project as well as a Deployment Space, both sharing the same set of users/roles.
To achieve process scalability, the creation of such a working environment for a given Banco do Brasil team is done through the
CP4DaaS API calls, triggered by an administrative component running on-premises, according to the employee roles/permissions
(in other words, only specific employees, say team managers can execute such a task). The described automation is of great
importance to Banco do Brasil since it allows them to offer strong guarantees regarding regulatory needs as well as flexibility
to adhere to their internal architectural requirements and extensibility demands.
They are, however, facing an important and limiting issue regarding a key API usage for automatically creating such work environments,
that prevents them from adopting CP4DaaS as their de-facto working environment, namely the creation of deployment spaces via API.
Users in the PENDING state (a.k.a. users that have access and were invited to the platform but still haven't access it yet) cannot be
administrators of a deployment space, although those users can indeed be administrators/members of a cp4d project. So, for project
creation the API allows proper automation, but for deployment space creation the API does not allow full process automation since it
requires a human intervention (to change the user from pending to active state) without a concrete business purpose: the user has all the
roles/privileges to be a member/admin of such a deployment space but there's no real need for such a user to access the platform prior to
space creation.
To clarify even more: BdB automates the project/deployment space creation in order to keep all management tasks in a centralized platform that runs
on premises. In this on-premises platform, a user with correct roles creates a "BdB Project" which consists of (1) a cp4d project,
(2) two cp4d deployment spaces, and (3) a set of users added to the project and both spaces as members.
The user that creates this "BdB Project" is the cp4d project/space admin.
Point 1) The user that creates "BdB Projects" is usually a manager, without technical expertise. So he usually does not access cp4d.
All management tasks that he needs to do (such as creating projects, assigning users to projects and deleting projects) is done
in the BdB platform (on-prem), no need to reach our dataplatform.cloud.ibm.com .
Point 2) This process works as expected when creating the project since a user with cp4d access role can create projects via API
even without having its first access to the platform done.
Point 3) This does not hold for deployment spaces, since there is an additional pre-condition that says that the user creating the
deployment space must access the platform beforehand to be considered active to the platform. This additional requirement, which is
not consistent on the way project creation works, is the main concern.
Why? Consider the following situation: A manager "A" has a team with 5 employees. They want to work on a brand new machine learning
solution using cp4d. Manager "A" creates a "BdB Project" inside their platform (on-premises side). This starts a procedure that
creates a cp4d project and adds the 5 employees as project members. The manager is the project admin. That works as expected.
However, this procedure also creates two deployment spaces (which are - at BdB side - associated to the created project).
The 5 employees should also be members of both deployment spaces. Now the problem is, the 5 employees can not access the complete
working environment because the deployment spaces can not be created UNTIL manager "A" accesses the platform for the first time
(and thus be considered active instead of pending user). And such a user can perfectly never access it anymore - since its perfectly
fine to expect such a user to NOT be a data scientist or the like - it's a people manager. Clearly, this blocks the overall automation
because now the environment creation process requires a "man-on-the-middle" manual intervention, which is not automatic not automatable.
