While they cover how it should be done, I come across many EDA's neglect to account for operationally providing forecasting and predictability. Without gatherin

While they cover how it should be done, I come across many EDA's neglect to account for operationally providing forecasting and predictability. Without gathering from the business what should be expected and implementing that (within messages, for example), we won't know when an event expected to arrive never arrived, nor when too many events arrived within a given time period. This is mainly a function of developers implementing only for the successful execution path and not for failure modes. Mature code bases that haul in the bags of cash for a business in my experience tend to have more code handling the failure modes and edge cases than the path handling the successful execution. It can be a 90-10 split in cases where the business function is considered fully-automated (though of course that is actually an asymptotic, Platonic ideal). IMHO, too little is taught about coding for graceful failure recovery; it should be in the logical journey from TDD all the way through into devops. More often, what happens is this property is ad hoc accreted over time in code bases useful enough to stick around in production for a long enough time.