This is going to get a bit technical (and probably long) but bear with me, or ignore me and move on.
So I am a Computer Scientist. My early work was in database systems - which, 40 years ago when I started in this business, was a very new specialty. Trends and companies have come and gone, but the fact remains there are really only so many ways (like 3) that large databases can be implemented.
While I don't have any direct knowledge of how Disney has chosen to architect the MyMagic+ initiative, I have spoken with a number of Disney IT folks (well former Disney IT folks, since they had all been outsourced) and nearly went to work for one of Disney's original outsourcing partners to work on the Disney account. That, 40+ years of systems experience and my own experiences with Disney's systems, gives me at least a modicum of insight into some of the issues here.
Mostly, the issues appear to be of Disney's own making, or rather of their inaction (think "penny pinching"). The core of the specific issue reported here is the fact that Disney does not have one cohesive system, but rather a multitude of disparate systems that were created at various times for various purposes, using a number of different technologies and tools. If you've ever had the opportunity (I have) to peek around the front desk counter and look at the reservation system the CM is using to check you in at your hotel, you'll immediately have a flashback to the late 1970s/early 1980s. Nothing at all state of the art about those systems. I can only imagine what the backend database engine is.
Overall Systems Approach
Each of Disney's systems, hotel reservations, ADRs, FP ticketing, etc, are pretty obviously individual systems and have little similarity to one another. Likely they each use a different underlying technology (whatever was popular at the time it was built). This makes it very difficult to integrate them into one cohesive unit - which is exactly what Disney tried to do with MyMagic+. But instead of integrating them at the foundational level ($$$$$$$) they chose to try to mask the issues by putting up a nice, modern user interface for the consumer to see ($) and build bridges and interfaces between the various systems behind the scenes. In all of computing history, this strategy had never actually worked for longer than about 2-3 years before things start to fall apart. I've seen it tried and fail in some of the largest and most tech savvy companies (Disney doesn't fit in that later category). It always ends up costing far more in the long run - both in dollars and in customer satisfaction.
Database Issues
The problem here with corruption of data and the inability to just "delete old data", is one of the by-products of using "glueware" (software designed to transfer data back and forth between two disparate systems without changing either of them). The database concept of "referential integrity" comes into play big-time under these circumstances. For any database to be useful, the data stored must be as correct and current as possible. It just doesn't work well if some necessary piece of information suddenly goes missing.
Database management systems generally work by storing a data item only once and providing the necessary links (called pointers) to and from all the places that information is needed. Within a given database, it's pretty difficult for these pointers to become corrupted. The database management system is specifically designed to prevent that from happening. At this point, several decades of work has gone into the theory and application of database systems. Enterprise level data engines are very solid. But only within their own framework.
When a company decides to glue multiple systems (and their underlying databases) together, they quickly run into referential integrity problems. Pointers (links) to/from data in multiple databases using different database engines have to be maintained "by hand" - neither database engine can do the job alone. Which means, that if I have an
MDE profile in db1, linked to a hotel reservation in db2, I can very easily screw things up if I delete the reservation, but don't remove the link to it from the MDE profile. It's that possibility of data corruption that leads companies that are using glueware to enforce referential integrity by
absolutely forbidding data that is involved in these cross platform relationships from ever being deleted. It seems so simple, until the data volume become unwieldy and corruption starts to occur anyway.
The reservation system probably couldn't care less if a canceled reservation was deleted, other than from a historical/analytic perspective (how many reservations were canceled in 2017?) But if the reservation goes away and the MDE profile isn't updated properly, the whole system begins to spiral out of control and will eventually collapse into a pile of useless goo. Having more than two databases involved only increases the potential problems exponentially.
So there is technical issue at play here. But reality is Disney could solve the problem by either massively redoing ALL of the systems involved or by specifically creating a cleanup process and systems that would remove unnecessary data from MDE profiles. But it appears they've chosen, for the present at least, to opt for the simple (for them) option of making their guests suffer.
Because, it is, of course, all our fault.
Steve
