In Finland, there are a lot of summer houses – approximately one summer house per ten Finns. Not being able to travel currently but willing to leave the city buzz for a while, summer houses have become even more attractive choices for recreation. Our family also has one, located halfway between Turku and Hämeenlinna, with the national road ten passing near the location.
That specific road has a long history dating back to the 9th century. Back then, the road was called Oxen Road of Tavastia (Hämeen Härkätie in Finnish), connecting the two cities, and used for trade ever since. Today, the road ten is constantly filled with trucks moving goods to be used for households as well as different industries in those areas.
However, the road itself – its construction, its route, and the way it has been maintained, certainly has changed over the thousand years of its existence. It has been gradually developed according to the current requirements and standards and according to the assets that it carries.
The same development is present on today’s information highways. When the electronic exchange of information started, it was slow, expensive, and clumsy based on today’s standards. However, the technology at the time served its purpose – otherwise, it would have never been used and developed further. From dial-up connections to the Internet how we see it today, there has been a long road – and one of the earliest and maybe one of the most interesting concepts are value-added networks (VANs).
Value-added networks of today
From the perspective of a 21st-century developer, VANs are a difficult concept. They were originally designed for interchanging information between different organizations and are still used for that purpose today, carrying a huge percentage of all global trading information daily. However, VANs started as a technical mean to exchange information reliably between trading partners – something that modern Internet protocols have made possible on the network level already for a few decades. The 21st-century developer knows the importance of exchanging information between different entities – both internally to their company or externally between trading partners. This developer knows how to connect to various parties using modern APIs, and when that is not possible, how to utilize Internet-based protocols varying from FTP and SFTP to AS2. However, the concept of a VAN may remain vague for them – why not to use the standard Internet infrastructure? Why to use an extra middleman when you could connect directly to your trading partner?
There are a lot of historical reasons for VANs to exist. When VANs were originally introduced, the Internet-based interfacing was either not yet available or still in its early childhood. Trading partners needed tools for more efficient document exchange technology than traditional mail. As volumes in VANs started to grow and more and more trading partners were connected to the VAN “cloud”, the networking effect made sense. Today, this networking effect is still valid – but it also creates a vendor (or technology) lock-in to the current VAN infrastructure.
Today’s VAN network is structurally somewhat similar to the traditional postal network. There is a limited number of VAN providers (like national posts) who have interconnected with each other. They all provide services to the local end-users, and when a trading partner needs to exchange information with a trading partner connected to a different VAN provider, providers utilize point-to-point interconnections the same way as national posts do for delivering international mail. Just like the networking between posts, current VAN interconnectivity is a closed network – you cannot introduce new providers (or new local national posts) without letting everyone else to know about the newcomer and creating interconnectivity relationships to keep the network functionable. In the current VAN network, there are around 100 interconnected VAN providers who serve around 800 000 trading partners worldwide.What is the problem then if it works? Well, there are a few, and they are mostly caused by the fact that the de-facto networking infrastructure – Internet – has developed significantly over the last few decades. The current VAN networking infrastructure is not necessarily the best fit when developing your business further – either from an economic or from a functional perspective. Some of the problems with the current VAN infrastructure include:
- Fully asynchronous model. VANs are based on document exchange based on different EDI formats. This approach has been copied from the way we have been accustomed to do business over several hundreds of years – using documents. However, in today’s world, there are ways to deal with others in a synchronous manner as well. Starting from the 19th century, we have had telephones, making decision-making and dealing with your trading partners more real-time. Today, the majority of modern business applications are primarily exposing real-time APIs – not document import/export functionalities.
- Static routing within the VAN network. The VAN network is fully meshed, with all the access points needing to know about all the others. Introducing a new VAN provider requires changes everywhere in the network instead of the dynamic introduction of new VAN providers. As this is a hindrance for new service providers to start providing services to trading partners, it is also undesirable from the end customer/trading partner perspective, as it limits the competition between VAN operators.
- Network complexity. Static routing, combined with the increased trading partner numbers and the fact that trading partners will start requiring API operations in addition to the EDI document exchange, will lead to a situation where different VAN providers need to start providing their own solutions for multiple emerging requirements. Without standardization, the network will eventually transform from a mesh into a mess where interoperability – the main reason to use VANs – will become endangered.
Value-added networks of tomorrow
VAN networking has a lot of good characteristics. The idea of a trading partner connecting to just one VAN provider is a simple approach for any organization – a VAN provider acts as a single-entry point to the world, just like modern iPaaS vendors characterize themselves. However, inabilities to communicate with API-based systems, as well as the home-grown network architecture between VAN providers (as opposed to adhering to widely deployed Internet standards), create huge challenges for the current VAN network to survive in the long run.
It is very improbable that current VAN networking with hundreds of thousands of connected organizations will simply vanish. Instead, the current shortcomings need to be addressed in a way that is feasible for existing VAN user organizations, VAN providers, and business application developers who are willing to utilize the existing network but who have never heard about EDI. The approach that should be taken is not to forget about the existing network, nor trying to switch all the existing information exchange to something new as a “big bang”. Instead, the possibilities and opportunities of the latest networking developments must be considered, and the current VAN mesh needs to be extended to meet the emerging needs. New lanes on the information highway need to be built and give the trading partners the possibility to switch the lane when they are ready for it.
You can still use the old roads. The old path of Oxen Road of Tavastia still (partly) exists as a combination of small local roads and streets, and it is not forbidden to use them. However, when you are driving a long combination truck, having a tight schedule and budget, and having your family waiting for you at home, you are tempted to go for the shortest and fastest route. The same is true with networking with your trading partners; as the information highway evolves, the most economical routes will eventually be followed. But changing your habits is not necessarily easy – the change happens when you are ready. Alternative paths will be there, and you can use the existing and modern ways in parallel – switching gradually to the pattern that benefits not only yourself but the whole ecosystem.
