Coming out and ranting against federated inventory has been interesting given the amount of anonymous feedback I have received. Anyone wanting to talk about it, let’s connect at TMF next week!

First, any reasonable order management or workflow product out there regardless of federated data requirements can do orchestration of data. Given the pace of change in our industry, do you really want to bottleneck everything through an intermediary system? Remove this requirement and the need for federated inventory starts to fall apart. All of the complexity of data caching and duplication and other operational challenges that federation brings is not worth the effort, if and when someone gets it working.

The easy use cases for federating data such as telephone number management, SIM card management, or CPE equipment management can be found in many resource management systems today. Given a robust API, there is no magic to using them directly.

The core of the inventory challenges reside in connected network services and wireless network services each requiring very different specific answers. If you can address this well with a new platform you will not have data accuracy issues and you certainly don’t need federated data.

My answer includes the need for rethinking inventory needs, addressing the challenge in data migration and removing end users from the equation.

The core issue behind connected network services is the complex hierarchy of services relying on lower level services causing recursive effects during change. In essence creating a complex object inter-relating other complex hierarchical objects. Simple discovery systems cannot reconcile this. You will need one that can address this.

The complexity of migration is substantially reduced if you rely on the network for most of the migration and ongoing sync. Again a challenge with most inventory platforms, so look for one that has been designed to address this.

Many traditional inventory systems were built with the idea that human interaction causes data errors. Rules were built into inventory to stop the inaccuracy but this has been fraught with failure. This is no longer a viable requirement and custom rules will stop you from keeping the data in sync with the network.

Finally, traditional inventory systems have grown fat with useless “other” data required by a workforce no longer able to maintain it. I see this like my basement filled with boxes of stuff unopened for years that I don’t want to throw out because it might be important. Then when I am gone from this beautiful world, someone else will just trash it. So trying to migrate or keep all that important “other data” is a losing game. Don’t migrate anything that cannot be justified and automatically maintained.

The challenge with what I have said is multi-fold. You have entrenched beliefs that the end users are in charge of the data but just as it is now simpler to land a jumbo jet without the pilot’s help, the end users and what they do must be changed.

The core of the challenge is creating an inventory platform that can understand the network and reverse engineer its use in real time, allowing interaction with systems and users as required. Having built this in mind this time, I realize that technology change is not the final answer.

If you look at RFPs today, they are written with the old mindset, looking for fixes to outdated problems using federation as the golden answer and you are surprised you ended up with the same challenges. Why? You got what you asked for. So stop asking end users and people still hanging on to their boxes to give you the requirements to solve tomorrow’s inventory challenges.