Time to have MFT as a service through your ITSM portal

Managed File Transfer (MFT) is used for years to move files within and without the enterprise. As most of these file transfers are triggered by applications and automated, it naturally felt under the responsibility of IT. IT is now grouping its services under IT Services Management (ITSM) portals. The ambition is to rationalize, reduce costs and delays. This is ultimately to charge consumption of IT services based on usage. Obviously, MFT as a service must join the movement and be part of the enterprise ITSM initiatives.

MFT as a service

The problem with this assumption is that the owner of MFT services is rarely included in ITSM initiatives. Up to now, MFT owners have only seen as wiring the routes for files with no clue about business logic, constraints and requirements. There is no link between the demand. The need for a data exchange between applications wherever they are and whatever is the exchange methods–and the configuration of file transfer engine on both sides.

Consequently, there is a gap between application owners and the MFT owners. The gap is bridged through manual processes, poorly and hardly maintained documentation (i.e., spreadsheet-based forms).

File transfers activities have been left behind. Other data exchanges using middleware such as Enterprise Service Bus and application servers are perceived as part of the complete business application lifecycle.

Therefore plugged into ITSM and DevOps initiatives. Generally, the related assets are populating a CMDB (configuration management database) acting as a repository and are exposed through the service portal.

Question remains

So, the question remains, how can my MFT be part of the ITSM initiative? The Axway response is the Digital MFT Shared Service approach.

Many large IT organizations have already put in place either internally, either through outsourcers, Center of Excellence for MFT and Shared Service for MFT. This increased operational efficiency and governance capabilities but this are not answering our question on DevOps and ITSM.

To provide the missing link, there is a need for two additional pieces: An MFT services repository. This will act as a CMDB for the flow of data and will maintain the link between applications, MFT components configurations, routes configurations available in one single place. A complete integration with all ITSM components.

Axway is offering the two within its MFT stack. The Axway API Management solution is populated with APIs from all Axway MFT components: Central Governance, SecureTransport, Transfer CFT. Therefore, access to MFT services is much simpler and much more reactive.

Leveraging this new combination, the Digital Managed File Transfer Shared Service approach is creating a paradigm shift. This allows the application owner and the transmission manager to differentiate technical MFT services. This is so you can “create and deploy new route through template” or “provision new partner” from business application level services such as “payroll payment” or “inventory update.”

The first benefit

The first benefit of the DMFTSS approach is that the application owner is now aware of existing MFT services and can leverage them through the same way he is already using other services. Consequently, new Apps usually interacting through Rest API can now benefit from legacy ways to exchange data and can leverage the core integration foundation of the Enterprise Digital Platform.

To summarize the benefits from a Digital MFT Shared Service fall into three folds:

1. MFT is now able to integrate the business application lifecycle.
2. Configuration and flow management services are now exposed through the ITSM portal and MFT can be included within DevOps.
3. APIs are available to ease integration with new apps and applications.