In the second blog of a two part blog series (you can read part one here), I have listed five more of the top ten mistakes during procurement, design and implementation that organizations adopting IBM Sterling Partner Engagement Manager (PEM) make and the steps you can take to avoid them, whether in on-premise or cloud.
Neglecting the strategy for migrating the partners
Two kinds of organizations implement PEM – an organization with an existing IBM Managed File Transfer (MFT) solution or an organization migrating from a legacy solution to the IBM MFT solution. In both cases, the MFT architects use different onboarding design patterns for different customer requirements by leveraging different configurations/components. Some components to capture the trading partner configurations are code lists, custom tables, custom property files, out-of-box trading partner configurations, etc. The business processes extract the trading partner details from one or more components mentioned above, process the files, and deliver the files to the destination. So, MFT implementations are not comparable as the MFT architects are enticed to different design patterns based on the customer requirements.
I recommend creating a migration strategy to populate the partner data in PEM, to provide a self-service capability for the existing partners. This proactive preparedness helps organizations efficiently use PEM as a record system for new and migrated partners. Just a general word of caution – don't plan big bang migration approaches. It may lead to a disastrous situation if not properly executed.
Failure to leverage role-based activities
In an organization, different stakeholders are involved in various stages of the partner onboarding—e.g., line of business, firewall team, MFT administrator, etc. These stakeholders perform the partner onboarding by configuring disparate systems for establishing the connectivity between the partner and the organization for file transfers. In a single role PEM implementation, a line of business person performs all the tasks in the PEM activities, leading to compliance issues due to asymmetric information between the line of business and the actual stakeholder who perform the activity. It creates an irreparable damage to the downstream systems and the organization's brand reputation.
I recommend leveraging the power of role-based controls to restrict the line of business users on the organization side from performing all the tasks on behalf of other stakeholders. Organizations can implement role-based controls by leveraging different permissions types (e.g., Sponsor Administrator, Sponsor Advanced User, Sponsor Standard User, Partner Administrator, and Partner User) coupled with different roles (e.g., Sponsor role, Partner role, and Both). This approach dramatically increases the ownership of the tasks and reduces the rework due to invalid configurations and compliance issues.
Underestimating the importance of design
In PEM implementations, the rule of the game mandates a comprehensive solution design document before starting the development. Everything worth doing takes time, so does a solution design. Some organizations consider the speed of movement over the direction of data flow. As a result, they give less importance to the design, which has a cascading effect on the PEM implementation.
I recommend a well-defined solution design with wireframe diagrams/mock-ups, branding, email message customizations, sequence diagrams with each task relating to the wireframe diagrams/mock-ups, definition of tooltips, usage of right controls for the right purposes, and REST APIs list. Finally, the stakeholders' signoff is mandatory on the design to avoid surprises post the go live.
Unnecessarily traversing through load balancer for intercomponent communications
PEM is comprised of different components like Portal, Partner Repository, Partner Provisioner, API Gateway, Community Manager, Swagger, JMS, etc. Most of these components communicate internally via TCP when a partner creates or updates their configurations.
I recommend configuring the docker host details appropriately in setup.cfg, instead of the load balancer details to avoid unnecessary round trips and network latencies, although some of the interfaces are exposed on the load balancer.
Not considering the cloud security requirements during the procurement phase
Today, most cloud providers offer two types of Infrastructure as a Service (IaaS) –classic infrastructure and VPC infrastructure. In the VPC infrastructure, most organizations separate non-production environments and production environments into two separate VPCs and restrict communications between the environments. This security requirement will limit the PEM to auto-provision the trading partner configurations into non-production and production environments using a single PEM instance.
I recommend factoring in these non-functional requirements during the procurement phase. These new patterns and security requirements need additional PEM licenses and might need additional hardware to separate non-production and production deployments.
In conclusion, as PEM is the nexus of partner onboarding between the partner and the line of business, codifying best practices from the inception phase is the holy grail of the success for the PEM implementation; otherwise, the cost of a poor PEM implementation can be very high. I hope this blog series helped you make informed decisions while implementing PEM. In addition, IBM Expert Lab Services may assist organizations in preventing from falling victim to mistakes during PEM implementations.
- 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 to vendor-specific documentation for any latest information;