I recently wrote a Windows service using Microsoft .Net technologies to act as a broker between two heterogeneous systems. Being a service, there is obviously no user interface for one to get feedback on how the process is executing or if it has gone into a state of error. My solution to this was to build a very complex logging mechanism which logs information to the Event Viewer, a text file and when needed snds emails to the administrator.
All of this of course works very much as expected, but what about data integrity. What if one of more of my systems has suspect data? Of course the typical response to this question is for the developer to simply say, "Well the data has to be right since the app has to have good data at the very least in order to have basic operation." So I don't believe anyone reading this would argue with that, but there are times when dealing with third parties that data can become corrupt due to errors in both their database and the communication layer. When this happens, who is really hurt by the bad data? The answer of course is the developer and his management chain. It is not immediatly the third party.
To battle this problem there has to be a mechanism for at least handling data integrity issues so that better information can be sent to the admin to combat the issues. Currently, the way we are dealing with this is by placing in-line rules into the service code as needed and passing as much data as possible back to the admin to further investigate so he can escalate the issues with the vendor.
Many information technology departments, already saddled with a heavy load due to budget cutting in a bad economy will have a difficult time building the appropriate rules into the code simply because they don't have enough time in the day. Currently I don't have a good solution to the problem other than to make sure that every company has a data steward. Just a food for thought blog entry.
All of this of course works very much as expected, but what about data integrity. What if one of more of my systems has suspect data? Of course the typical response to this question is for the developer to simply say, "Well the data has to be right since the app has to have good data at the very least in order to have basic operation." So I don't believe anyone reading this would argue with that, but there are times when dealing with third parties that data can become corrupt due to errors in both their database and the communication layer. When this happens, who is really hurt by the bad data? The answer of course is the developer and his management chain. It is not immediatly the third party.
To battle this problem there has to be a mechanism for at least handling data integrity issues so that better information can be sent to the admin to combat the issues. Currently, the way we are dealing with this is by placing in-line rules into the service code as needed and passing as much data as possible back to the admin to further investigate so he can escalate the issues with the vendor.
Many information technology departments, already saddled with a heavy load due to budget cutting in a bad economy will have a difficult time building the appropriate rules into the code simply because they don't have enough time in the day. Currently I don't have a good solution to the problem other than to make sure that every company has a data steward. Just a food for thought blog entry.
0 comments:
Post a Comment