To Traceability & Beyond! Enabling Software Traceability at Scale

Mara Puisite discusses enabling traceability in production. 

"Traceability means a bajillion things to a bajillion different people" - Mara Puisite, Tasktop.

Based on experience managing (owning) projects for a lot of companies, Puisite shared some traceability gems to help companies become software innovators in the truest sense.

We can learn from Puisite's experience working hand in hand with engineering teams. Even when she's working within the same value stream, the question "When was this work released?" always pops up.

The answer to this simple question took more than checking Jira (or your choice of tool), often requiring the inclusion of the actual developer involved to trace back any activity.

Now a value stream architect working with large firms to iron out process flows and enhance traceability, Puisite encourages continuous learning. Not only around your craft, but also about how companies' actually work. This allows product owners to assist even as a pre-sales engineer should the need ever arise.

To de-conceptualize the ideas she shared, Puisite introduced a character named Andy. Andy is a Fortune 100 bank DevOps manager focusing on automation. This means Andy constantly works on removing manual steps in business processes. Since he (always) gets asked when a product's version or tasks around it was released, traceability is among the initiatives Andy works on.

It's key to note that product managers, like Puisite, generally ask about delivery dates more than others. Particularly when traceability is still vague.

Developers Answering Traceability Questions

Here is a list of typical responses Puisite has received about traceability from engineers. When asked when events had occurred, this is what Andy took her through. According to him, this is what traceability boiled down to:

• an actual walkthrough of the developer's pipeline job in Jenkins,
• a presentation of docker images and their timestamps,
• metadata from relevant commits, and
• the final show of the pipeline job that pushed a task for deployment.

While this leaves Andy comfortable even when audits are carried out, for his audience, it's not necessarily clear for his audience when tasks were completed. Instead, it's a series of steps that drain time and happiness from product owners. Imagine going through ten such walkthroughs on a daily basis. Not to mention how this routine could get really complicated for a top management audience.

Why Traceability Should Matter Indefinitely

Traceability must be a top concern, especially for software as it scales in the future. Without knowing when events happened, it becomes laborious, if not impossible, to deduce how long it took for them to occur. This alone should be scary because, according to Puisite, it means the following:

• Your company loses the capability to measure development processes from end to end.
• New business value delivery estimates become blind guesses.
• Pointing out delivery rate-determining steps is impossible,
• You risk misplacing valuable resources on potentially secret activities.

These vulnerabilities effectively stifle your software project's growth. Even as it grows, the chaos grows with it, and you'll require a critical investment in better ways of doing things.

How to Tackle Traceability

Puisite explains that traceability is not a goal. Treating it as a goal gives managers the wrong impression as it's actually a journey. It always makes sense to define the reasons why you want traceability. Who benefits when you have attained it, and if you were asked, to whom would you present it and how?

This transforms traceability into a less vague concept; that of visibility — knowing when and how things happen and how long it would take were it to happen again.

Even when you know and are working on traceability, there are two types you could aim for: audit driven traceability and end-user driven traceability

1. Audit-Driven Traceability

This type of traceability requires some accountability for any and every action. To reach this state, your developers capture details around each event. Typically this involves  It "doesn't have to be pretty," says Puisite when explaining how to get the ball rolling.

Also, audit-driven traceability needs not be in plain view of the end-user. Often done manually, Andy can pull up specific information when required. This means data collection can happen with some delay, rather than in real-time. Effectively it cancels out the monotonous walkthroughs previously endured by product owners since the information they need is ready on request.

2. End-User Driven Traceability

Unlike the first kind, end-user-driven traceability needs to be readable and accessible even without Andy's presence. Implementation is typically through the tools in use for pipeline management/monitoring, which is Jira in Andy's case. Top-level managers can access this through a tool like Trello, while ServiceNow users should also get a view of the same. This type of visibility has no space for delays — it has to be live.

Most companies will do well with both types of traceability in production. In any case, Puisite suggests starting traceability efforts from the very beginning of building your systems and processes. Focusing on the missing information means your efforts will inevitably lead to visibility.