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 and ultimately to charge consumption of IT services based on usage. Obviously MFT must join the move and to be part of the enterprise ITSM initiatives.
The problem with this assumption is that the owner of MFT services is rarely included in ITSM initiatives.
Up to now MFT owners are only seen as wiring the routes for files with no clue about business logic, constraints and requirements. There is no link between the demand - need of 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 and 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.
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 is not answering our question on DevOps and ITSM.
To provide the missing link, there is a need of two additional pieces:
- a MFT services repository, this will act as a CMDB for 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 that allows the application owner and the transmission manager to differentiate technical MFT services such as “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 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 benefits of 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:
- MFT is now able to integrate the business application life cycle
- Configuration and flow management services are now exposed through the ITSM portal and MFT can be included within DevOps
- APIs are available to ease integration with new apps and applications
More information on Digital MFT Shared Service on: www2.axway.com/boost/2