Mapping Your Enterprise GenomeHow much do you know about your IT infrastructure? It pays to find out
by Karen Kazimer-Shockley Continued from Page 1 All these business rules were, of course, present in the user metadata as part of the final system so that no matter which legacy system the end users were accustomed to, they were able to ascertain the current definition and processing rules. (See "The Confidence Game," March 8, 2002.) Data SourcesWhen the data requirements were well in hand, we addressed the problem of receiving source feeds. As I mentioned earlier, the data feeds came from systems enterprisewide, on varying schedules, and with different levels of handshaking and validation. Consequently, we needed to develop data synchronization rules, based on the data elements that were required from each source system, the processing that was to be provided, and when the data had to be presented to the user. Although our spreadsheet was very large at this point, we added another few columns, which listed next to the legacy system the number of computers that sent the data, as well as the frequency of this data. (See Table 2 [PDF, 12K].) Again, by using the transformation rules, which dictated which elements from each system had to be present to create the target data element, we were able to determine a schedule for processing the many feeds that were sent to the legacy systems. Target DataWe also had to develop similar rules for the targeted output. Each legacy system had its own schedule for presenting reports, storing data and readying it for query, and sending data on to other systems. We applied the spreadsheet technique yet again. Thanks to the spreadsheet, we had a comprehensive list of all the reports and queries, by system, with the data elements (and their transformations) contained in each one: We had the perfect tool for determining which reports were duplicated across systems based on their data and target audience. At this point, the user advocates came into play again to prioritize reports and queries and determine which reports were to be produced, the data elements used, and business rules provided. The last step consisted of matching output to the schedule for producing elements; we were then able to determine an order for producing the reports and ensuring the data was available to the appropriate users. Happy CustomersOnly after all these steps had been accomplished were we able to broach new functionality and how and when it should be incorporated into the target system. An added advantage was that by the time the legacy requirements were captured, we had an in-depth knowledge of which data was currently being used and why. This knowledge in itself is crucial when embarking on any new strategic IT project. In addition, we were able to use the legacy system requirement process to gain support from essential members of the legacy user community. This support was invaluable as we parlayed the knowledge of how their processes worked into building a new system that could streamline and enhance the effectiveness of these processes. Most important, the project was deemed an overall success by the user community. In particular, the format of the requirements allowed traceability of the data throughout the system. This approach led the users to trust the integrity of the data, which in turn made the software "acceptable." More and more users are turning to the new functionality, which includes ad hoc queries, in lieu of the standard legacy reports. The data from the data warehouse is also being used as a data source to feed new systems that are in development. Slowly, but surely, the user community is moving toward one version of the truth. Karen Kazimer-Shockley [k.kazimer-shockley@att.net] is a senior consultant working for Alltech Inc. Karen is a senior systems engineer with experience in the full software development life cycle, from requirements analysis through integration testing.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| |||||||||||||||||||||||||||||||
