The Inovis Blog

Here is the first official post on the Inovis blog from John Thielens, Vice President of Product Marketing and company guru of Managed File Transfer.

Managed File Transfer is getting a lot of attention these days as companies wrestle with security, compliance, capacity, and reliability issues around their data movement strategies.  But what exactly is Managed File Transfer anyway?  To a certain extent, that depends on your historical perspective.  When looking at the history of Managed File Transfer, it is important to remember that MFT has several different heritages, and that each heritage comes with a particular bias, perhaps, but also a particular set of lessons.  Let me explain.

Here at Inovis, we are best known for our VAN/EDI heritage, and the VAN/EDI heritage teaches that SLA’s are important, that Visibility and Tracking are important, that understanding the business process context of why you’re moving data around is important, and that understanding the file itself and being able to match the confirmation to an order is important.  This leg of heritage is a very transactional, measurable perspective because VANs serve this particular function.

In contrast, a version of MFT that stems from FTP or Secure FTP provides a very different set of lessons because the purpose of purchasing an MFT tool kit instead of just using FTP is usually for security reasons. Therefore, the focus is on security and compliance. The lessons learned with this version of MFT are about service and authentication technologies as they tend to be authentication centric and not peer-to-peer. One of the inherent benefits of operating an FTP server or an MFT server that comes from this particular flavor of MFT is that people have to connect to you and log in, so you can therefore impose the security policies and manage their credentials. Banks like this aspect of MFT and have traditionally operated this way. There is a lot of real secure file transfer heritage in that side, and from the Secure File Transfer market we’ve come to understand that security is but one aspect of management.

Inverting the bank’s perspective where the bank is always the server in charge and everyone else is always the client leads to the third important heritage of Managed File Transfer that I like to call spoke-itis—always the spoke and never the hub. This means that initially you were dealing with lots of different rules to talk to your hubs and maybe it was proprietary software you had to use, but usually as you scale up, you wind up scripting it. You may have a Unix administrator or a Windows guru or perhaps a programmer that will script the interactions with all of these environments, and you consequently develop your own mini hub. There’s a very flexible scriptability and lots of adaptability in dealing with all of the rules imposed by the hub. It also means that there are other aspects of security that you need to worry about because you are managing credentials from the other side. When you’re the server, you keep public keys and password hashes, but when you’re the client, you keep private keys and passwords. Security is different but equally important with this kind of interaction. The real lesson, truly, from this leg of heritage is that file transfer isn’t really just about moving the files. Managed File Transfer is about integration and about making a business process work with someone on the other side. Part of this is moving the file, but most of this is how you manage the credential, what you do before and after you move the file, whether you have to rename it, whether you have to get them something minutes later, and the rules around doing that. What you’re really attempting is executing some kind of a business interaction profile. You’re not JUST trying to do file transfer.

When looking at all of these different breeds of Managed File Transfer, we come to see that Managed File Transfer as a category is actually incredibly broad. Gartner poses a statistic that 80% of the data that binds businesses together is files, and that includes both those collaborative human files as well as the structural and application files. When you’re looking at MFT solutions today, you can’t choose a product or a solution that has a particular heritage; that’s not going to do it for you. The challenge to us as vendors is to give equal weight to all of the requirements, and all of the use cases that derive from all of those important heritages. For the purchaser, the obligation is to look for solutions that meet those needs and to demand that kind of completeness. In my opinion, the way that’s going to happen initially is not that we’re ever going to build the mega product that does all things to all people. Instead, what’s going to happen is we’re going to focus on the M part of MFT and have management and visibility solutions that are at least able to instrument what’s happening around the different aspects of that 80% glue. Start with a holistic view of what MFT means and how to manage it. Instead of trying to find some mega product that addresses possible use cases, look instead for openness, standards, and interoperability. Even your e-mail system is technically part of the MFT infrastructure and you most likely aren’t going to buy e-mail and EDI from the same guy. Do, however, consider what they’re doing to manage your perspective, especially with regards to visibility and your process of securing that Managed File infrastructure.