Data associated with information systems
Can you tell whether an application will be a data graveyard—much information being created within it but virtually no information coming out of it? No organization can afford this kind of application anymore. How do you write this into the specification?
If you are involved in specifying, designing, evaluating, programming, testing, or supporting software applications then you know how much data is created around those functions. Configuration data about a large application is, by itself, complex enough and critical enough to merit a data management effort all on its own.
Every aspect of software acquisition or development as well as project management creates and maintains massive amounts of data. SOA (service oriented architecture) relies upon specifications for services being available throughout the company to those who may want to use the services. Any architecture involving the creation and use of reusable components depends upon being able to make specifications and perhaps even the component itself accessible everywhere.
If you are a web master, you are very familiar with the need to find every page that contains a changed link and if you're a web user you know the feeling when one of those links is not updated.
Again, power tools exist for the various processes but if you want to bring all the pieces together to answer the really interesting questions like
- Where is this service or module being used and what are the top five support issues for it by business function?
- How do component developers and testers compare in terms of the number of support calls for their components?
- For the components with the lowest/highest frequency of support calls is there any clustering around tester, developer, designer or analyst?
The best information for the best decision.