Managed File Transfer

 View Only

10 devastating mistakes that IBM Sterling Partner Engagement Manager adopters make — And how to avoid them (Part 1)

By KALYAN PAVAN KISHORE CHAKRAVARTHULA posted Thu July 22, 2021 03:40 AM

  


With so many organizations choosing IBM Sterling Partner Engagement Manager (PEM) to reduce the time and resources required for onboarding, I thought it is essential for organizations to know about common mistakes made in PEM implementations and how to avoid them. In this first blog of a two part blog series, I have listed five of the top ten mistakes during design and implementation that organizations adopting PEM make and the steps you can take to avoid them, whether in on-premise or cloud.

             


 Implementing PEM activities without a holistic view

The heart of an IBM Sterling Managed File Transfer (MFT) solution is either IBM Sterling File Gateway (SFG) or IBM Sterling B2B Integrator (B2BI). The workflows in SFG/B2BI use the trading partner data to process and deliver the files. It is crucial for the PEM consultant to know what components are leveraged in the SFG/B2BI solution for partner onboarding and to understand what needs to be populated in those components. For Example, an SFG/B2BI consultant might leverage Text2 in the code list to store an IP address of the remote destination. A PEM consultant needs to deep dive into the SFG/B2BI solution to understand the rationale behind every parameter used in the partner onboarding.

 

I recommend that the PEM and SFG/B2BI consultants should not work in silos and be cross-trained in both the solutions.

 


 Not planning all the partner maintenance operations during the inception phase

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.

 


References:

- IBM. (n.d.). IBM Sterling Partner Engagement Manager https://www.ibm.com/docs/en/spems/6.1.2.

 

Disclaimer:

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;

 

 


#Featured-area-1
#Featured-area-1-home
#filetransfer
#DataExchange
2 comments
2174 views

Permalink

Comments

Thu May 05, 2022 12:06 PM

Great List. I think, pre-planning early and understand the big picture and then to detail level ( APIs etc) is great point.

Wed August 25, 2021 08:19 PM

As a Tech Seller of PEM, the last is the one that I would agree with. Don't know why people do that.

Show the difference with multiple browsers as Sponsor and Client tasks.

Great list.