In my last post titled AS3 Has Failed, I described the challenges the AS3 standard has faced in receiving widespread market adoption. AS3′s failure will not halt the process of businesses transferring files amongst each other. There are numerous other FTP options available on the marketplace. However, the cost of file transfers will remain unnecessarily high due to the proliferation of standardized and proprietary FTP variants.
FTP – Five Transfer Protocols
The base FTP standard does not offer adequate
security controls for exchanging sensitive information outside of the
enterprise. As a result, enterprises typically augment basic FTP with
additional security capabilities. The result is that there are
multiple different permutations of FTP including those with data level
security such as PGP and X.509 digital certifications and those with
network level security such as VPN, SSH or SSL. So in other words, the
FTP used for B2B is, in fact, not one standard, but actually many.
With AS3 we had the opportunity to unify the various different FTP
standards into a common framework that could be consistently applied
between trading partners. Instead, it seems the FTP variants are here
to stay. Perhaps, we should change the "F" in File Transfer Protocol
from "File" to "Five."
FTP Madness at a Typical Large Enterprise
Software Vendors Milk the MFT Cash Cow
Not only are there several different
implementation models for FTP, but the best capabilities are packaged
into proprietary software packages called "Managed File Transfer"
(MFT). MFT packages augment basic FTP with the security features
listed above. In addition MFT software includes capabilities such as
checkpoint/restart for large files; monitoring of transmissions for
exceptions and compression technology for enhanced performance. Here
is the catch. The vendors who have developed these MFT products
require the use of their own proprietary communications protocols to
gain the full feature set.
Proprietary protocols are a lucrative business
model for software vendors, especially for B2B scenarios. In order for
external business partners to exchange files using MFT, they too must
also license the same vendor’s proprietary MFT package. Once the hub
is sold, the entire trading partner community has little choice but to
comply with the hub’s mandated file transfer protocol. The revenue
opportunity isn’t limited to upfront license fees. MFT vendors are
typically in the position to charge a premium for maintenance once a
large community of users has been established, because the customers
are "locked in." Even if the customer decides to migrate away from a
proprietary product, it may take years for them to convince all of
their trading partners who also purchased the MFT software licenses to
migrate their connections. There are numerous large financial
institutions, government agencies and telecommunications providers that
pay over $1M per year in maintenance royalties to MFT vendors.
Leading MFT software vendors include Sterling
Commerce, ipswitch, Proginet and Axway who recently acquired
Tumbleweed. These vendors generate hundreds millions of dollars from
licensing and maintenance fees for proprietary MFT products. For
example, Sterling Commerce has a substantial MFT software business.
Gartner research note published in September 2005: "Sterling’s
Connect: family, with its customer base of more than 5,000 companies,
generates more than $100 million in annual revenue. This represents
more than one-third of the $250 million to $300 million managed file
transfer (MFT) suite market."
A Conflict of Interest?
Why haven’t open standards emerged for FTP that
include many of these common file transfer capabilities such as
checkpoint/restart; compression and management? AS3′s introduction
would have offered the perfect opportunity.
One cannot help but wonder if there are larger
commercial influences at play in the struggle to unify file transfer
protocols. What would happen if end-users could gain the benefits of
MFT features without having to use proprietary protocols that lock-in
trading partner communities? My guess is that the vendor offerings
would become quickly commoditized lowering their potential revenue
opportunity.
What would happen if the AS3 standard had been
functionally at parity with MFT software features? A migration away
from proprietary MFT protocols towards such an open standard would
represent a significant reduction in revenue for software vendors.
The situation gets even more interesting one
considers the potential conflicts of interest between the open
standards efforts and software vendors. Many of the committee members
who join together on industry task forces to develop new, open
standards are representatives from the software vendors. In the case
of FTP standards, these software vendors would also be the ones
realizing lucrative returns from their proprietary MFT software
products. What incentives would MFT software vendors have to push for
FTP standards that include their historically proprietary features?
Perhaps, we have the answer as to why AS3 was
not more functionally robust with features such as checkpoint/restart;
compression and management capabilities.
Proprietary Wins the Battle, but will Open Standards Win the War
Of course, these conspiracy theories are pure
speculation on my part. I am not aware of any efforts to deliberately
prevent AS3 adoption. We will always face potential conflicts between
the desire for industries to unify around open standards and the need
for commercial software providers to differentiate their product
offerings. Competition amongst software vendors is generally a
positive influence on the technology sector as it results in faster
innovation and pricing reductions than would otherwise occur. The key
question is – When do vendor efforts to differentiate their products
result in barriers rather than accelerators to technology adoption?
From my perspective, there is little value in having ten different
proprietary standards for a common utility such as file transfer. This
represents an additional barrier to electronic commerce and drives
unnecessarily high infrastructure costs. Perhaps, some day the
industry will rally around a single unifying FTP standard. Until then
it seems we are at the mercy of the MFT vendors to drive FTP technology.
© Copyright 2008 GXS, Inc. All Rights Reserved.
