Only a minority of people are good at that. I'd also note that there is a correlation between the importance of such needs and the ability to anticipate them at the initial design stage. (ie. is it reasonable to be surprised by the fact that a holding owning several supermarkets asks for consolidated reporting at some point ?).
If you're good at abstraction, modularity and composability, there really isn't any gotcha to fear. Stuff don't just come out of the blue.
How do you create a data structure for a requirement that doesn't exist at the beginning of the product?
Most of the time when I've seen someone design data structures in a way that attempts to design for unknown or predicted future requirements, the design ultimately becomes over engineered and a nightmare to maintain or expand in ways the actual product requires down the road.
I'll always pick the concrete implementation as long as future requirements are unsure.
I don't know how you get good at magically guessing how your product needs to evolve, e.g., what new industries is your sales team going to crack into, what direction does marketing want to take your product, etc - the only way you could be "good" at that is when the direction is extremely obvious or you have unilateral decision making on every point of your road map.
If you want cross report you will define a super-data structure able to talk to both monoliths. They incidentally become "microservices" but at a higher level.
We had this at one of my previous places, exactly the same setup. Identical monoliths * shopping malls, the issue is that Companies own more than one shopping mall and they really want cross mall data, something that was extremely painful to add in at a later date.