PEM increases efficiency as trading partners can maintain their records remotely on their own. Interestingly, the create operation in PEM is given utmost importance, as organizations want to quickly onboard their partners while ignoring the other essential operations like read, update and delete. However, if the capabilities of PEM are not fully leveraged, it will not provide the necessary self-service capabilities. For example, the partners cannot update their details like certificate, SSH keys, PGP keys, hostname, etc., post onboarding if an activity is not implemented to handle the update operations.
I recommend having a detailed solution design on all the create, read, update and delete (CRUD) operations to provide self-service capabilities for partners and lines of business.
Overcomplicating by creating hotchpotch tasks in an activity
By using poor methods to decode the tacit knowledge of partner onboarding in an organization, and converting them into PEM activities and tasks, creates interdependencies between activities, where the tasks of one activity are dependent on another. As a result, the intertwined activities lead to complexity, thus decreasing the ease of use of PEM and increasing the activities in the active state, leading to erroneous reporting.
In PEM, an activity is a collection of tasks, and a task presents a series of form-based dialogs. At a high level, there are two types of non-system tasks – Partner Task and Sponsor Task. So, I recommend breaking the onboarding tasks into multiple independent tasks and stitching all these tasks into different loosely coupled activities with the right mix of partner and sponsor tasks that are coherent.
Let's take an example of a typical SFG onboarding with an initiating producer partner, a listening consumer partner, and a routing channel. Here, I recommend three different activities, first, for creating an initiating producer partner. Second, for creating a listening consumer partner. And third, for creating a routing channel to connect the initiating producer and listening consumer. This isolation of activities allows the organizations to efficiently onboard their partners.
Not validating the PEM and B2BI APIs early enough
The REST APIs are the lingua franca between PEM and the downstream components. Both PEM and B2B APIs have hundreds of REST APIs for performing CRUD operations on various components during the onboarding. In PEM, these REST APIs are orchestrated in an activity to manage the configurations of a partner. Sometimes, the REST APIs might not satisfy all the requirements because of the way those are designed.
So, I recommend listing all the REST APIs required for an activity and the corresponding request and responses during the design phase. This helps to mitigate the risks of constraints with the REST APIs early in the implementation. In addition, PEM developers should develop as per the guidelines set in the design guide and avoid usage of hardcoded values while constructing the REST API requests if not explicitly mentioned in the design.
Executing both sponsor and partner tasks as a sponsor during stakeholder demos
In PEM, a sponsor can execute the partner tasks. It is a convenient feature for the sponsor to act on behalf of the partner and complete its tasks. However, this idiosyncrasy will not clearly separate the duties of stakeholders (e.g., line of business, partners, etc.) during the onboarding demonstrations. It will create more confusion than clarity.
I recommend implementers to wear the stakeholder's shoes and avoid ambiguous demonstrations. Instead, login separately as a partner and as a line of business, probably using two different browsers, and let the stakeholders know when switching between the browsers.
- IBM. (n.d.). IBM Sterling Partner Engagement Manager https://www.ibm.com/docs/en/spems/6.1.2.
The views expressed are solely my own and do not express the views or opinions of my employer. I shall not be accountable for and does not accept any liability or responsibility whatsoever for any inaccuracies, omissions, errors, misleading information, loss, or damage howsoever arising (including without limitation, incidental, punitive, exemplary, special or consequential damages, loss of profit or damages resulting from lost data or business interruption), be it by negligence or otherwise, or expense resulting from:-
- Using the information and contents of this article, whether with or without authorization;
- Relying on the information and contents of this article, whether downloaded or not;
- The performance, operation, functionality, non-performance, unavailability, inaccessibility, or corruption of this article;
- Refer vendor-specific documentation for any latest information;