Interview with a CEO: Solution Evolution, Part 2 of 3

Interview with a CEO: Solution Evolution, Part 2 of 3

Hey, nice to see you again. Thanks for coming back to part 2 in our “Interview with a CEO” series. Just to recap in case you already forgot the last post or in case you are jumping in midstream, I was able to have a chat with our CEO, Jason Tepfenhardt, on a number of topics and one of the things that we ended up discussing was around some of the changes in the Life Sciences industry from 10-15 years ago to today.

It seemed to me that a good way to convey some of those changes was to represent them through our own timeline in the industry and through our solution iterations and evolutions. While we have, dare I say, generally been ahead of the curve in the realm of regulated software quality, we have been able to do so by heeding lessons, recognizing trends in the industry and make adjustments along the way
(go back to part 1 if you would like to learn a bit more about the pre-Tx3 and pre-VERA days), which brings me into the next phase of this series.

The Early Tx3 and VERA Days…….

As we discussed in the last post, the state of regulated software quality was handled a bit differently both leading up to and in the early days of what would become the Tx3 team and VERA. Projects were still very waterfall-based and rooted in traditional thoughts and methodologies around “validation”. Even in that landscape, Jason and the team were developing innovative solutions and processes to achieve regulatory requirements for software quality and testing. Much of which laid the groundwork for a lot of where the industry ultimately ended up going from not only a methodology standpoint but also from an attitude and approach to compliance standpoint.

What I’m referring to is building a path to facilitate the growing want and need to move away from traditional document-based practices that were already starting to prove to be a hindrance as teams began to adopt robust automation across much more heavily integrated SDLC tools and teams. This was really where the start of our push towards a “data-driven” methodology vs a “document-centric” approach began.

The timeframe leading up to the formation of Tx3 was a crucial one because some important lessons were learned along the way. Through working with customers and industry peers, we were seeing common trends as teams were looking to apply traditional compliance approaches to more modern solutions and processes, and it was drastically limiting the potential benefits that those tools offered, as well as the efficacy of the teams using those tools.

That trend sort of manifested itself in two ways when it came to the compliance solutions regulated teams were using.  On one side of it, we were coming across (and unfortunately still do) teams purchasing compliance solutions that were being positioned under the guise of modernizing software compliance but that were really just digitizing the same outdated methodologies they were claiming to improve. Meaning they weren’t pushing teams, or the industry, forward. Instead, these tools were slightly modernizing traditional, paper-based compliance processes and methodologies.

“Traditional CSV is rooted in a manual, waterfall process and many
solutions have propagated that flawed process in a technology solution that just looks to automate the manual, inefficient process, rather than provide a more advanced, effective and efficient way of performing that process.”

While these solutions were familiar and comfortable to many folks, and while they did offer some improvements over a purely paper-based approach, they certainly had limitations that Jason and the Tx3 team had taken note of.

The reality is that these more traditionally based solutions could not effectively accommodate the rapidly changing technology and process landscape without being largely disruptive to modern tools and the business objectives those tools were purchased to support.

Which leads me into the second trend we were seeing among software compliance solutions. As discussed in the last post, in the early days we were heavily focused and immersed in the ALM world.  We were seeing teams adopting solutions like ALM and UFT (for example) for automation of tests and test management, but still trying to graft traditional and often overly complex internal compliance practices onto that functionality and workflow.

This was problematic for numerous reasons and certainly applied outside of ALM as well, but it was a key trend that VERA was developed to address…

“VERA’s original use case was to standardize the process of using compliance solutions with ALM. Over the years our customers ended up over-engineering the use of ALM to match their exact internal manual process and were not getting the benefits of using industry best practices.”

Too often, rather than adopting or adhering to purveyed industry best practices from subject matter experts, teams faced with the potential consequences of compliance deviation felt safer holding on to overly rigorous processes that were founded in methodologies that were already being phased out in other industries.

This led to a lot of counterintuitive behavior. On one hand, organizations were purchasing and implementing solutions to help modernize and streamline their software quality practices, yet they were also trying to hold on to and interject archaic processes that were drastically limiting the solutions they certainly weren’t paying mere peanuts to own and maintain.

As a result, a lot of (brace yourself for a bad word in the world of regulated software) customization was going on. Customization that was difficult to support and expensive to maintain. Not to mention the increased risk profile of utilizing a heavily customized solution in a regulated environment.

As it turned out, there was a way to simplify this and our experience by this point in working with so many life sciences teams had given us the empirical data to put this simplification into action.

“In all reality, our customers all need to comply with the same requirements, and they were already 80% plus aligned with what other life sciences companies were doing. They all thought that they were doing things differently, but they weren’t. VERA helped close this gap by standardizing process and offering a configurable solution based on industry best practices.”

Did you catch a few keywords there?  “VERA helped close this gap by standardizing process and offering a configurable solution based on industry best practices.”. In response to some of the regulated software and compliance trends we discussed, this was a key component in both the initial and ongoing development and improvement of VERA.

As Jason mentioned, software teams in the life sciences world all face the same requirements and those requirements could more easily and efficiently be achieved through standardization and configurability. This model also nicely accommodated the ever-growing need for integrated solution sets in a more iterative based and automated agile software development and testing methodology.

Taking that idea and building upon it, VERA’s capabilities were eventually expanded to become more than a solely ALM based solution.  By applying that same level of standardization and configurability across a number of SDLC solutions, we were able to get closer to the original idea behind VERA and address some of the larger issues and gaps we were seeing across the regulated software landscape over the years.

“The original vision was a complete quality and compliance platform that integrated best of breed test automation, agile and DevOps tools. Customers needed to be able focus more on continuous process improvement and the ability to take advantage of new technologies and processes to help them work smarter and more efficiently.”

Through these developments, teams could now leverage a much more seamlessly infused and nimbler compliance methodology enabled through a standardized quality and compliance hub across various testing and quality solutions. The key outcome here is that teams now could focus on keeping the emphasis on software quality, with compliance deliverables and verification being derived as a natural byproduct of those good software practices (instead of the other way around). Now in 2020, we are starting to see much more industry-backed momentum behind this type of approach and even expect to see some FDA guidance around this later this year.

Which basically leads us to the current day, and where we see the industry now and in the coming years………. but since we’ve already gone quite long, that seems like a good place to break and pick up in the next post.

Feel free to subscribe to our blog if you would like to be immediately notified when the next (or any future posts, for that matter) go up.

Share to: