Ikey,
Guess we will have to disagree; I am unsure of your IT experience but mine spans 3 decades including several transaction system project which involved processing credit card transaction. My participation in these project included writing the initial project proposals, designing the systems, and reviewing the final contacts between the parties. I sat in meetings which rejected a targeted uptime of 99.99% since this represented a downtime of greater than 52 minutes per year. This was said to cost one customer of >$135k in missed income.
High availably transaction servers are the reason an entire industry exists which addresses downtime. This includes companies spending large amounts of money on geographically diverse fall back transaction systems which instantly get rolled over to in event of one location goes off line. Other industry participants include those which develop and sell server health monitoring and alarm products. You will find that the majority of today's existing transaction system service providers which tout this kind of uptime (100%). These facilities also have incredible power management and fallback systems in place. Again, an entire industry exists which serves up redundant power management systems and services. Companies spend millions very year on this alone; allowing them to instantly switch over to backup battery power in event of a power failure.
As opposed to your example of the power grid not needing to be up 100% of the time... please allow me to give an example that is a bit closer to what we are talking about. Every single credit card transaction server in this country (in the world actually) is established with 100% uptime capability. These companies get paid a fraction of a penny per transaction and handle millions of credit card transaction per month. They demand 100% uptime and have zero tolerance for even 1 minute per year of downtime. There also exists a thriving industry for secure data centers. These 100% uptime systems are located in old salt mines and missile silos and can instantly switch over to other secure locations if one goes off-line. These are designed to offer customers 100% uptime access to their data.
So your definition of a transaction server must be difference than mine if you believe that it is ok to deliver a transaction system in which it is acceptable to miss several hours of income per year. Keep in mind that missed transactions may represent more than just dollars, it could mean the loss of customers too. I concur that Amos probably would not require 100% uptime but if they shopped a transaction system or service they would find that it would be offered as a basic capability of such a system.
As for supporting web site users with quickly and simply insert code into their web sites; I find your example as being native and grossly over-simplified. It is not as simple as 'cutting and pasting' some code. If anyone thinks for a second that throwing some code into a web page and giving web site owners the ability to download it as that being all there is to it; I would suggest that they have no experience in supporting this kind of system or service. Even the most basic 'contact us' web forms have evolved into support issues for web developers and owners. Just paste some code into your web page and it instantly works on every computer, tablet, and smart phone? Across all browsers including every version? Across every operating system including all versions? All that without the need for any support? Sorry, this doesn't sound realistic to me.
I also disagree with your assertion that web site owners would willing absorb the month fees that a catalog company might charge without passing them along to the end user. Being a monthly recurring charge it is especially noticeable and a constant irritant. Of course if the monthly charges from a company like Amos were very small (i.e <$5) then perhaps they would absorb them. But in a heavy trafficked web site, or if Amos needed to generate the majority of their income from this form of payment, the monthly charges would be significant and unlikely to be simply absorbed.
And lastly you are not addressing the cultural and business model changes that a company like Amos would face. Amos legacy business model is firmly entrenched as is their culture and organizational structure. Anyone who thinks it is easy and risk-free to make these kinds of changes to a legacy company is simply wrong. There is no 'dipping a toe into this pool' with this kind of change in a company. You would be asking them to walk away from their existing business model and take an entirely new approach to making money. Jobs would be lost, people would be lost. New jobs and new people would need to be established. Just look at the paradigm shift various magazines and newspapers had to experience to see how this might shake up a legacy company like Amos or SG. (Hell, an Amos employee confirmed that they don't even have the existing catalogs in a centralize database right now. As I previous mentioned, they aren't exactly considered a early adopter of digital technologies.)
Dreaming about the possibility of a philatelic organization establishing a high end transaction system is fun. It certainly is technically possible but reality gets in the way. There are many, many examples of companies which went out of business instead of changing their legacy business models in this digital age. And while I certainly hope that organizations like Amos, SG and APS can make this transition, their history so far does not support this outcome. They are all clinging to the legacy 'charge for access to any worthwhile information' model while the rest of the world has already moved to offering much of the same info in real-time and for free (i.e this forum). So probably like you, I would love to see them try to make this transition and wish they had gotten started 10 years ago. I guess hope springs eternal but I stand by my opinion that company like Amos would be very, very hard pressed to pull this off successfully (if at all).
Don
|
Posted 08/15/2015 9:19 pm
