4 ms·

I think GP's point is more along the lines of When the Ministry of Education and the Ministry of Whatever are both customers (separate instances) and want cross

I think GP's point is more along the lines of When the Ministry of Education and the Ministry of Whatever are both customers (separate instances) and want cross instance reporting. 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.

Twisell 10y ago
Except that in real world you can't automagically create cross report from separately defined data structures. 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.
r2dnb 10y ago
I agree with Twisell. The solution is to create a super data-structure so this really is an architecture and abstraction issue - ie. design things in a way such that these structures can be added in an incremental and painless way when the need appears. 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.
- debaserab2 10y ago
  What exactly is a super data structure? 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.
danmaz74 10y ago
> cross instance reporting Isn't a DWH the best solution for this?
jbergens 10y ago
I evaluated another system where we needed something similar. Adding cross data reporting was not hard. Combining whole installations was a bit harder but it was probably not harder to solve it when needed instead of solving it early

Twisell 10y ago

Except that in real world you can't automagically create cross report from separately defined data structures. 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.

r2dnb 10y ago

I agree with Twisell. The solution is to create a super data-structure so this really is an architecture and abstraction issue - ie. design things in a way such that these structures can be added in an incremental and painless way when the need appears. 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.

debaserab2 10y ago
What exactly is a super data structure? 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.

danmaz74 10y ago

> cross instance reporting Isn't a DWH the best solution for this?

jbergens 10y ago

I evaluated another system where we needed something similar. Adding cross data reporting was not hard. Combining whole installations was a bit harder but it was probably not harder to solve it when needed instead of solving it early