Failures within and between applications cost money, lost productivity, and even loss of morale within and outside IT. What happens following a failure determines if the impact is relativity minor or a disaster costing significant dollars and possibly loss of jobs, contracts, and future opportunities.
What happens next is what this talk is about. In an ideal scenario, the right people are notified by the exception event with all the information relative to the error (who, what, when, where, and why). In the worst case, the most highly skilled (and compensated) programmers are called upon to find the cause of an exception armed with little more than “something broke”. Maybe the notification is an hour later, a day later, or maybe when a quarterly report reflects numbers that “can’t possibly be right”. Maybe the error is easily reproducible – maybe it’s not.
Whether you’re an ISV, a consultant, or an IT staffer, there are simple, cost-effective steps we can take during and after the development process to minimize the impact of failure, free us to focus more on new development, and improve the bottom line by reducing the cost of ownership.Matt Fritz and Tom Demola will be facilitating the meeting with samples of what has worked for them and some mini case studies of when not doing these things causes companies problems. Please bring ideas to share on what works for you and let’s compare notes! INVITE YOUR BOSS!
Four Proposals
- Activity Logging
- Smarter Notification
- Message Queuing
- Locking down data manipulation between systems (Excel)