Further to Glenn his points.  TCO (Total Cost of Ownership) is a really important one.  License cost is only a fraction of the entire picture for this kind of solutions.  You can compare it to buying a slightly cheaper car, and ignoring the fact that whatever you save on the initial purchase will evaporate within 6 months due to a far higher fuel consumption of the cheaper car.  Unfortunately, TCO is far more complex as compared to fuel consumption.

For this type of solutions, fact of the matter is that within the overall TCO, the initial purchase & deployment cost typically represents only a small portion of the TCO.    In general, TCO also includes components such as the sunk and overhead cost, the operations & maintenance cost, the cost of evolving the solution, the expected life cycle of the solution, and much more.  And therefore, not surprisingly, the simplified and short-sighted approach of comparing monitoring & orchestration solutions solely based on the initial cost very commonly results in very poor business decisions from a TCO perspective.

Note that this is also about software, where possibilities are endless, and it is extremely hard, if not impossible to capture the real value of a piece of software simply on the basis of some sort of compliancy with requirements.  Or in other words, while many software applications might check all the exact same requirement boxes, the actual value in practice between those different software applications can easily range from very poor and close to not usable, all the way to a great perfect match for what you need.  And this due to nobody's fault or shortcoming, it is simply impossible to capture the real value of software on the basis of requirements.

The key problem here is the following: a small detail that is missing from a certain functionality in the software can easily reduce the value of it in your specific operation to zero, i.e. you thought it was going to be exactly what you needed and then in reality it turns out to be useless.  And what is the cost of NOT having certain functionality?  All we can say is that it can be considerable, very considerable.  But it is not tangible and very visible.  It's a bit like saying, what is the cost of not having a fire insurance? If you consider what I'm saying here, then you will understand that for example the relationship with the software vendor can already have a big impact on your TCO.  Are you dealing with a vendor with whom you can have a long-lasting strong relationship, and where you can count on that vendor listening to your specific needs?  Or are you dealing with a piece of software that you will have to take and accept as it is, and will have no leverage on how it will evolve in the future?  The difference between those two can have a considerable impact on your TCO.

There's a lot to be said about this, and it is a very complex topic.  But by far the number one reason why the TCO for DataMiner is typically considerably below any other product, is it versatility and flexibility.  Enabling users to leverage it as a truly unified platform across their entire operation, and all possible aspects of it.  Many operators invested in DataMiner over 10-15 years ago, and still up to today manage everything they have with that platform, everything in their operation has evolved and has been replaced multiple times, except the management platform.  And that has an enormous positive impact on TCO.

Unified operation also increases security considerably (smaller attack surface, more professional, etc.), lowers the training expenses, lowers the contracting cost, the support cost, the ever more important north bound integration cost (ticketing, inventory, planned maintenance, portals, etc.), the upgrade and evolution cost, and so much more.

Again this is a very broad topic.  But fact of the matter is, DataMiner offers a superior and very competitive TCO, and for this kind of solutions, the initial purchase cost is only a fraction of the TCO equation.