Tool Design

An oft overlooked aspect of the software service design is the adminsitrative tools used to maintain said services. In the case of Traceability, the tools need even more attention to design correctly. However, this extra attention to detail is a good thing overall. The benefits will not only give you better understanding of how a given service is processing data or handling a customer's data, but will even provide faster customer service, since you will be able to more quickly ascertain and resolve issues that customers may contact you about.

It should be strongly noted that a developer will very likely be asked to interpret the any trace data that comes from these tools. This should not be a surprise, since the trace data is explicitly centered around details of the code, and it not generally expected for business or service center to have much experience with software development.

Web Admin Page

One way to access the trace data is have it available through the web admin pages used to administrate related business functions. The trace data could even be integrated in such a way that it is an option in the page to be used as necessary.

Something that could be done is to parse the trace data, and then generate the page from that. This way, anyone who has access to the page has the ability to drill into the information in a more friendly way. If this additional parsing is added, the trace data should still be accessible as a separate data display.

Read Only Pages

Integrating Traceability into a page that merely gathers and reports data is conceptually straightforward. The trace data is simply another data set being gathered and displayed on the page.

Since the amount of trace data can become very large, it would be advisable to display it in a separate pane.

Write Allowed Pages

Adding Traceability to admin pages that allow authorized people to update customer information can be very useful. Now we can verify what logic and data was actually being used when the update took place.

An option to add to these pages would be to intercept the data, and either store it in a special database, or display the query and parameters on the page. The purpose of this option is to allow people to test how changes to customer data may impact the customer without actually just making the changes in the live data and hoping for the best.

Separate Application

In addition to integrating the Traceability into web pages, we can integrate it into testing applications. This way application support personnel may take advantage of Traceability in their tools as well.

In this case, you would want the trace data to be shown in a separate pane / window, or even to write it to a file. The advantage of writing it to a file is that then the data is ready to sent to a developer for more specific analysis.

Data Interceptors

Another aspect that needs to be ascertained is how the data is being fed to the systems with Traceability. If we simply have a Traceable service connecting to the databases and other data feeds as the regular service, then there is not much extra to do; we simply use the same connections. However, this method limits us to current data, and often we are asked to look into issues that occurred some time in the past.

A more interesting, and complicated setup, is to have the ability to get the state of the system at a specific date and time. This way, when we investigate an issue with a customer's account we would have the ability to use the specific data that was present when the issue occurred.

A good example of software that implements this concept is accounting software. The data set starts at a known point in time, and with known values. Transactions are then added to the account, and the values are updated. What is happening under the hood is that the transactions are being replayed against the initial data, and the values are being updated with each transaction. Periodically, a known stable value is added as a hard point in the data; for example the account balance at the beginning of each month is stored. This way we only need to go a bit backwards in time to a know value, and then replay the transaction forward from that point to the point in time we need.

Data that is updated occasionally (for example: display preferences) can be stored with audit records. This way, we could go back in time, and see when the values were changed, and ensure that we are using the appropriate values when troubleshooting an issue.

Once we have these abilities implemented, then we are able to go to any point in time, extract the data, and then use Traceability to see exactly how it behaves in the services.

For a more detailed look on how to set up the databases in the above manner, please see Time Relative Database

Next: Legal Aspects