The key to get ready for MFT self-service

Let’s take a minute to think about your current process for new MFT data flow creation. I’m sure you have tried to optimize this process based on the corporate standard tools and your own technical skills. Most teams gladly share an Excel spreadsheet with some computed values in protected cells, a few data field validations, and some rudimentary MS Basic macros. This is the first step, but I’m sorry to say: this is so 1990s.

Maybe you’re more in the 2000s, presenting a web application to collect the right information from your business? A few screens to click through, a few dozen (technical) fields to fill in… Well, at least you’re not receiving hundreds of spreadsheets a month, and you’ve have gotten rid of poor version control based on file name. Nice! Can you do better? Certainly! And it’s actually pretty easy if you rely on an MFT Services portfolio.

Why develop an MFT Services portfolio?

Despite your well-thought web application, you still have to face recurring business users’ complaints.

• “Why do I have to pick the receiving folder when I’m the one sending the file?” That’s a valid point…
• “How am I supposed to know which are the ‘allowed ciphers’ for my transfer, when I don’t even know what a cipher is?”. Fair enough…

You’re walking a fine line; the receiving folder and ciphers are required as part of the technical configuration. This configuration is a direct translation of your business users’ needs. But they don’t seem to be able to select the right option. In addition, the sum of requirements sometimes adds up to a completely new type of implementation. Deploying this configuration requires heavy testing before it’s released in production. This slows your time-to-market and frustrates your users who don’t understand why this particular request takes twice as much time.

What if you could only ask your users to provide a minimal set of business-related data? And what if all the technical information would automatically be deduced from this business context and your approved file transfer services? Sounds unrealistic? You’re wrong, that’s where the MFT services portfolio comes into play.

How to define your MFT Services portfolio?

Let’s agree on a definition for “MFT Service.” An “MFT Service” is a business representation of an MFT Template. Moving on to answer the question above: an “MFT Template” is the skeleton of a file transfer, a partial configuration model according to which all related file transfers are defined and implemented. This skeleton enforces a subset of attribute values, specific to the scenario that it covers. When a model is selected, those attributes don’t need to be provided, simplifying the collection of data needed to define the flow configuration.

Trying to make it more tangible, let’s pretend your company is a clothes retailer and you have to onboard a new store in your systems.

• The new store manager will connect to your company web portal to create its account and provide some information about this new point of sale, including contact details for the main business contact (store manager in this case) and information about their preferred method for sharing data
• The store manager is presented from headquarters with a list of services that he can enroll in. Since winter is approaching fast, he’s signing up for the “Order new flannel shirts” among other services like “Download weekly sales offer.”
  • Those are 2 examples of business-oriented MFT Services.
• At the end of the enrollment process, the store manager selects his preferred method to share this data: Upload/Download the files from a specific section in the company portal. The other option (install a pre-configured agent that can send or retrieve files) sounds too technical for him.
• Each method offers the same two MFT Services but works based on different MFT templates:
  • The web portal is based on an API-based integration with the MFT gateway and supports 2 MFT templates: 1) HTTPS upload (from the store) to SFTP push (to the Order Management System) for the Order service and 2) SFTP push (from the marketing system) to HTTPS download (from the store) for the weekly sales offers.
  • The agent configuration is implemented using the same MFT gateway and an end-point agent: 1) PeSIT push to SFTP push for the Order service and 2) SFTP push to PeSIT push for the sales listing.

Hopefully, this simple example gives you a better idea of what we call a (business) MFT Service versus a (technical) MFT template.

How to define the right service portfolio?

Based on the previous story, I’m sure you can already feel what makes for a good set of MFT services:

• Addressing a reoccurring business requirement for data transfers.
• Easy to understand (and therefore: select) for a business user with no technical skills.
• Self-explanatory for someone who has no knowledge about your internal IT/MFT solutions.
• Related to a unique MFT template.

You’re on the right track. What about the MFT templates then? We can certainly start with the following criteria to decide if it’s time to create a new template. As you will see, they strongly depend on the Digitalized MFT solution architecture that you decide to implement:

• Direction (for company external-to-internal transfers and vice-versa)
• Number and sequence of segments in the exchange
• Technical protocols used per segment
• Delivery mode per segment (like push, pull, retain)
• Routing operations between segments (like archiving, zipping, encrypting, encoding…)

But usually, we see customers go into an extra level of details, by adding some other criteria like file type (binary or text) or default pre-/post-treatment.

The tricky part is to find the right level of granularity for your organization. What if we need to add a technical acknowledgment when the file is downloaded from the web portal? Or if we want to use PeSIT over SSL instead of plain PeSIT in the second scenario?

In most cases, the ACK doesn’t fundamentally change the technical configuration of the flow or its behavior. So I’d suggest leaving it aside from the model and for the business user to choose. However, adding SSL encryption to the PeSIT protocol should lead to a different model.

Several reasons for that: adding SSL support changes the configuration; it potentially requires involving different actors (security team) in the design process; and also because it can be decided that this template only applies to a subset of participants (by example: for external partners, but not internal participants).

How to initiate and maintain your portfolio?

So, how many MFT services and templates should you define? Unfortunately, there is not a single truth that would work for all companies. Obviously, this highly depends on your MFT solution: direct transfers between internal end-points will require fewer models than if you use an external-facing MFT gateway with FTP-SSL, SFTP, and HTTPS protocols. That’s a fact.

But also, the fewer MFT Services you define, the less differentiation you can include in the predefined attributes, therefore the more you’ll need to ask from your users. Remember that we try to provide a self-service MFT, so asking too much will not reflect well on your users. On the flip side, managing the lifecycle of too many MFT services will add strong overhead to your team. We are walking a fine line here.

My recommendation would be to start by creating less MFT services and templates (and asking for more information from your business). By analyzing how your users select and fill up the various fields, you can progressively tune your MFT services portfolio.

You may realize that some services are not selected as much as you’d think (plan to deprecate them?). Or that your users are always entering the same values, which you can include in your MFT templates to save their time. Outside of these metrics, it is also important to sit on a regular basis with a representative set of your business partners.

This gives them a chance to provide feedback on your self-service solution, which they may not be able to share through the tools. This will provide valuable feedback on how you should evolve your MFT service portfolio. And it will also make them feel more involved in this initiative, which will certainly accelerate the adoption.

It sounds like you have the key to start improving the customer experience around your MFT solution. Your MFT Center of Excellence is crucial for this initiative, since managing the portfolio of MFT services, in line with the platform capabilities and business expectations, is one of their main responsibilities. Now you also know how to engage to get started!