Fashion, like a lot of industries, deals with huge volumes of data. From customer profiles and cross-channel engagement and conversion analytics, to the spreadsheets and systems that try to bottle hugely complex supply chain processes, the average brand or retailer has more information in their hands than ever.

As a direct consequence of the volume and variety of data that fashion businesses need to manage, identifying the right systems to house and – crucially – communicate that information has become not just an I.T. task, but a whole-business imperative. At a basic level, sales and returns data should be a valuable source of insights for the next cycle of design and development. As a deeper example, data gathered at the point of raw material sourcing should, ideally, make its way downstream, where it can be used to enable shoppers to make informed buying decisions.

If you represent a brand or retailer, and your data isn’t that interoperable and accessible yet, don’t fret: you’re not alone. Solving the challenge of universal data accessibility is one of fashion’s largest contemporaneous challenges. And while web standards and open APIs have done a great deal to improve system integration, it’s still common to have information in one system that you know would be useful elsewhere, but to be unable to bridge those systems without manually duplicating the data.

Ease of integration, though, is all but guaranteed to change in the near future. Businesses large and small are making increased use of platforms and services that run on public cloud architectures such as Microsoft Azure, Google Cloud Platform, and Amazon Web Services.

The primary catalyst for this move is normally a commercial one; the cost for owning, administering, and maintaining servers is a tough pill to swallow when cloud infrastructure offers compute and storage on tap. And this is especially true because the shift from upfront cost on ongoing expense can allow companies to migrate a significant segment of their I.T. budget from capital to operational expenditure.

The second driver behind increased cloud adoption is current circumstances. Some of the world’s workforce might be returning to offices within the next month or two, but not all of them will be going back full-time. Hybrid working is becoming the preferred model – several days in the office, several at home – and to cater to this, everyone from the creative designer to the sourcing team will need consistent access to the same information wherever they are. And aside from private and managed clouds (which remain an option), public cloud architectures offer the easiest and most future-proof route to making information available when and where it needs to be.

The push towards public cloud is good news for data interoperability because cloud architectures and web standards go hand in hand. Solutions built on Azure (or its competition) tend to offer open APIs built on codified web hooks, which is creating a self-fulfilling prophecy whereby openness begets openness, and public cloud SaaS solutions end up integrating much more easily to other public cloud SaaS solutions.

This is what Accenture refer to as “desegregation of data fabrics,” and it’s categorised by them – and by other analysts – as a top cloud trend for this year and beyond.

To put it bluntly, that means that integration is becoming the software industry’s job, not a task passed on to the end user. Today a blend of documented APIs and cloud middleware can take care of most integrations with little – or no – bespoke work. And over time more and more solutions are becoming cloud-native, reducing the need for bespoke work even further.

I don’t mean to trivialise a persistent challenge here, but the trend is clear: enterprise software is moving towards openness, and the data that brands, retailers, and their suppliers want to enter into and extract from their software is destined to become more interoperable by default.

The value of all this can be a little tricky to visualise, though, when we’re talking about data as an abstract concept. So let’s consider the same requirement for universal access (within security and governance rules, of course) through a different lens: assets.

What is an asset? In purely semantic terms it could be anything, but for fashion’s purposes it normally means something digital in nature that comprises more than just alphanumeric information. A 3D render of a garment is an asset. A text-only list of material suppliers isn’t. The distinction can feel a bit arbitrary at times, but the same core principles apply to both assets and information: they need to be portable, because they’re used in multiple different processes, for different purposes.

Sticking to the pure technology side of this topic for a moment longer: assets also tend to be larger, in filesize terms, than text and integer data, and to comprise multiple different elements. Text and numerical information places comparatively little pressure on networks and systems, since it can be transmitted quickly to almost anywhere in the world from a single centralised location. Assets are a bigger burden: their size makes them less practical for centralisation, since a hypothetical 200mb file that resides on a server in California will take much longer to download in Europe or Asia than it would domestically.

This is where another strength of public cloud architecture comes in: replication and content distribution. Rather than having one instance of an asset, AWS et al automatically create duplicate instances of those assets in different strategic locations around the world, so that when they are requested by an end user, they are served up quickly, from the most proximate location.

This approach to asset decentralisation is one of the building blocks of the modern web, and it’s also integral to services you no doubt use daily. When you watch a film on Netflix, or listen to something on Spotify, you’re not accessing a root file that’s held in just one place, you’re streaming from the server closest to you. This is what’s called a Content Distribution Network, or CDN.

To provide some idea of scale for reference, and to underline why those examples I cited matter, Netflix has more than 1,000 nodes in the proprietary CDN it built in partnership with regional internet service providers, and Spotify has a similarly robust CDN strategy. But while those companies are distributing films and music to consumers, a fashion brand might want to make, say, high resolution product photography available to retail partners around the world, without serving up archive-quality assets from just one place.

But what if fashion went a step further and started thinking about products themselves as assets? What might that look like? And what lessons could that teach us?

For most brands today, it would look like centralisation. Products are designed in one place and manufactured in another, before then entering a global distribution network. In some cases, and in some product categories, manufacturing happens in multiple different factories to make up the desired volume, but even then production is mostly consolidated in just one or two regions.

To me, the parallels between the way products move today and how assets moved prior to the creation of CDNs are obvious. In both cases an asset housed in one location needs to be used in another, and without replication and redundancy, the trip from one end to the other will always take time. In the case of a digital asset that hop can be measured in milliseconds; in the case of fashion, the timeline could be months, spread across sampling, production, and logistics.

Which brings us back to the idea of the public cloud, but instead of looking at it as a resource to be used for asset distribution, we can look at it as a model to be borrowed for fashion’s core business: getting products to people who need them, as quickly as possible.

In that scenario, product creation would still remained centralised the same way that filmmaking and music composition and production does, but like those industries, the finished product would then be replicated and served up from the closest location to the end consumer.

Unlike those industries, though, fashion consumption is not a matter of playback. (I should note, though, that digital fashion very much is a matter of playback, so the analogy works without addition.) For a garment or a pair of shoes to be consumed, they need to be sewn, assembled, and packaged. And this is where fashion would need to make a leap of faith.

Picture what a CDN for production would look like: smaller, more agile manufacturing nodes set up not just in-country, but potentially in-city. A given product would be designed and prototyped digitally at brand HQ, and then “published” so that it becomes available for production across every node at once. Depending on how that brand calculated demand, production might then begin until an inventory-holding cut-off point was reached, but the truly transformative approach would be for production to begin only once a consumer order is received – with that order being assigned intelligently to the shopper’s closest node.

The advantages of adopting this CDN model for production would be, essentially, the same as they are for regionalised content distribution in other networks. End users would receive their content at the speed they expect, with no visible disruption to the user experience. For the brand, the same shift in expenditure could take place that’s already taken place in I.T.: manufacturing could be reframed as a tap be turned on as needed, in a hyper-localised way.

To avoid this being filed away as a pipe dream, though, consider that on-demand microfactories are already a proven concept – and one that can be replicated. And by placing microfactories close to distribution hubs (or making them into logistics centres themselves) it would be feasible to go from online order to consumer delivery in just a few days. And while that’s something customers are already used to, rather than ordering from inventory, they’d be ordering instead from a catalogue of assets.

The difference to the consumer of adopting this model might be imperceptible. The difference to the brand could be revolutionary. But that revolution will require fashion to think about asset management in an entirely different way.