Chris Trueman

Hello, everybody. My name's Chris Trueman, and I'm part of the products team here at Tricentis. Today, what I'd like to talk about is how we de-risk our enterprise app integrations.

I'd like to cover three topics with everyone today. First, to reinforce why we believe that testing is an incredibly powerful tool to help us deliver enterprise application innovation. For me, quality is a function of both process and data. With our ever-increasing reliance on the data that our integrated enterprise applications produce, we need to be mindful of the integrity of that data. So I'd like to spend a few moments talking about that. Finally, I'll try to do my level best to predict the future and get it right by considering new sources of innovation, how we can future-proof our enterprise applications to accommodate those, and what that will mean for the future of testing.

We need to frame all of that within the context of the digital transformations that are underway in all of our organizations. What we observe is that there are four key themes or challenges that CIOs and their teams are faced with. The first is: how do we increase release velocity while at the same time trying to reduce the cost of delivery? Since we're talking about this suite of enterprise applications that we've worked so hard to integrate, we need to be mindful of how we de-risk changes in those environments and always work to deliver high-quality outcomes in production.

The good news is that customers are achieving this today. Here's one example that I've drawn from our consumer products customers, where using Tricentis LiveCompare, they've been able to increase their release velocity by eight times, going from 11 to an incredible 88 releases per year.

If we think about innovation for a moment, simplistically, it's about taking ideas and bringing them to market. If we get a little bit more specific and think about our enterprise applications, we need some way to organize all of our efforts in terms of how we transform those ideas into working software running in production. Throughout the history of software development, there have been lots of different ways for us to organize our efforts, but today, the current established best practice is some form of Agile DevOps. My particular focus is on the role of testing to support that, and I do truly believe that testing is a very powerful tool to help us achieve our aims with our enterprise apps.

It's not just me saying this. I've drawn from the most recent World Quality Report, where just looking at some of the words that are used to describe the role of testing reinforces this idea of how it supports innovation: contribute to business growth and business outcomes, ensuring end-user satisfaction and customer experience, and, as we move to the top three, people reflecting on the existential events of last year, things like quality at speed, speeding up the software delivery process with good quality, tying that back to those key challenges that CIOs and their teams are now faced with. I especially like the first of these, where it's about supporting everybody in the team to achieve higher quality.

Software quality testing, for me, means answering three important questions. First, what to test? Then, does it work? Finally, does it scale?

When we think about those questions, it's worth digging into how enterprise applications are tested today. From our own observations, what we see is that the majority of customers rely on their key users to test the changes that they're making. This has one very clear advantage: our key users understand how those systems support our business processes better than anyone else. However, there are some disadvantages. First, and I know I'm stating the blindingly obvious, it's not their day job. As a consequence, we find we have to have a risk mitigation process put in place because we have to deal with defects that show up in production. That risk mitigation process is known as hypercare.

With hypercare, in software just like in the biological equivalent, it's now a life-or-death situation. We bring together our most talented resources from key users, development, and operations, and their job is to fix the defects as quickly as possible. There's not just a high cost associated with this because we're relying on our most talented resources. There can also be implications for the reputation with our business partners and customers. On an individual level, if you've ever been part of a hypercare team, you'll know that sustaining that level of intensity can be very hard to do. While all of our great resources are tied up on hypercare, the backlog continues to grow.

What actually happens is that we build this incredibly powerful engine to deliver innovation in our enterprise applications, and then we stick this enormous limiter on the engine. Some case studies that I've read online talk about how a one-month project extends into three months because of two months of hypercare. Well, now a release means we can do four releases a year. That's far from 11, and certainly a long way from the 88 that our customers are achieving.

So what can we do to eliminate hypercare, to basically remove that limiter from this incredibly powerful engine? At Tricentis, what we offer is a way to integrate dev and ops for optimized testing, and we do that through a set of capabilities that we call change impact analysis. With change impact analysis, we're going to ingest all of the changes that have happened in development, and we're going to combine that with all of the data that we've extracted from production that tells us what's actually being used to support our business processes. Through an analysis of that data, we will answer the question, what to test, automatically. We will identify the most at-risk capabilities that we must test in order to assure the quality of our business process support. For us, risk is largely a function of the frequency of use, which represents the dependency that our business processes have on these integrated enterprise applications, combined with an assessment of the damage that we're causing through the changes we're making in development.

I don't wish to scare everyone by putting a frightening diagram up on the chart here, but this is actually a live SAP system that we've analyzed with change impact analysis. You're probably thinking, I can't make out anything in that diagram, and that's actually the point. Each of the components that are unreadable represents something that makes up the implementation of SAP. In fact, this isn't a complete SAP application. I've chosen just one transaction amongst many that are used day in, day out by customers to support their business processes. This is why it's unrealistic to expect our key users to be able to do that complete testing job for the changes that we make, because the environment they're operating in is so sophisticated.

Using Tricentis LiveCompare, we can turn that into a set of most at-risk capabilities to test, and through our integration with Tosca, we can even find all of the test cases that we have available. What about gaps? With gaps, we actually know who those subject matter experts are in our key user community, so we can go back to them and have them help us close the gaps most efficiently and most effectively. In fact, we have tooling available today which can record their daily interaction with their SAP applications to essentially codify all of that great expertise that they have.

Demonstration

Let me show you how that actually works in practice with a demonstration.

What can we do to ensure that the changes we make in development don't create unpleasant waves in our packaged apps? Let's bring the benefits of CI/CD pipelines to our packaged apps, especially automated actions like code quality analysis and running unit tests. To this we'll add unique impact analysis that will tell us if the changes we're making cause ripples or waves. Let's shift left and focus on supporting our developers.

Tricentis LiveCompare will monitor our SAP development systems and analyze every commit. LiveCompare examines each commit from four perspectives. It identifies the impact of every change, so is this a ripple or a wave? It runs all the available unit tests, reporting failures directly to each developer. It identifies code quality issues when it's cheapest to fix them. And yes, we can see how things have changed side by side across all commits.

At the end of each sprint, LiveCompare analyzes all of the changes to identify the most at risk to test and integrates with Tricentis Tosca to identify test hits and gaps. Putting all of the pieces together, we now have LiveCompare working hand-in-hand with Tosca to run all of our functional, API, and integration tests as part of one seamless CI/CD pipeline. Talking of running tests, it's worth highlighting here Tosca support for the latest SAP GUI Quartz theme. As much as I enjoy using the new Quartz theme, running tests one by one isn't very efficient. So LiveCompare and Tosca will use the distributed execution service to leverage all of the available compute and run our tests in parallel. As testing progresses, LiveCompare gives us the complete view of what's passed, failed, and still to be run from the perspective of the most at risk to test. We can shift right using LiveCompare to monitor our production SAP systems, tracking issues, categorizing them, looking for the root cause, and providing feedback to developers. In short, Tricentis LiveCompare and Tosca combine to eliminate unpleasant waves in our packaged apps.

Chris Trueman

We've seen a demonstration of all of that in action, but what does it mean in concrete terms across a range of customers? I've surveyed a number of our SAP LiveCompare customers, and what I can see is the benefit of using change impact analysis. This first column represents the sort of traditional response to changing SAP, which would be, "Oh, we have to test everything." The second column represents the results of the analysis, identifying the impacted capabilities. This is good. It's certainly a reduction, so we're going in two ways to address the challenges that our CIOs and teams are facing: we're going to spend less time testing so we can increase release velocity, but we're also going to be focusing our testing on those damaged capabilities that we depend on, so we're minimizing risk and improving quality.

The challenge, though, is that there's still a lot here to test. By using LiveCompare, we can reduce this to those most at-risk capabilities to test. It's this that delivers an average 85% reduction in our test scope. Using this, we can eliminate the need for hypercare, so we can remove that limiter from this incredibly powerful engine that we've developed to deliver changes in our enterprise applications.

Let me focus now on data. I said at the beginning that quality is largely a function of process and data. Today, our organizations depend on data like never before, and so it becomes very important for us to consider the integrity of that data, especially in the context of the distributed and integrated enterprise applications that we run.

Here's a very simple example of a business process that's, in this case, documented as supported by SAP. This represents order to cash. We look at diagrams like this and think our business processes are quite straightforward: a whole sequence of activities, one after the other. But the reality can be quite different. Business processes are incredibly variable and complex.

This is an actual example from one of our pharmaceutical customers. This company happens to be responsible for delivering the majority of pharmaceutical drugs throughout the United States, and this is their distribution process. We can see from the chart that they depend to a significant extent on different SAP applications. But it's not just SAP. I can see Salesforce listed; I can see custom applications. The key takeaway is that all of these applications have to be integrated in order to support that business process.

When it comes to de-risking change in an integrated enterprise application environment, we need to pay special attention to these end-to-end business processes and how they decompose into individual applications. It won't be enough simply to be able to automate the testing of SAP. We really need to be able to support not just all of those packaged enterprise applications, but also all those different technologies that we're using to build our custom apps.

That's testing the end-to-end process, but we then also need to pay special attention to the data as the data flows through all of these integration points and is acted upon by these different systems. Traditionally, paying attention to data integrity was a very expensive endeavor because it depended on an extremely specialized set of skills that often understood at a very detailed level how each of the different systems persisted and operated on their data. We were often having to write very low-level SQL scripts to try and extract the data and then combine that with data from other sources. So it was a very expensive endeavor and very high cost, and thus difficult to achieve.

But we need to pay attention to it because data flows through this incredible pipeline from original transactional systems where maybe we don't retain the data, so we have data loss. We may have duplication of data given the different systems that are storing and processing it. We may have developed integrations using ETL-like tools, so we need to understand any transformations that are taking place. Be mindful of missing constraints and inconsistencies. The point is, as we go from left to right, the cost to fix data integrity issues just grows, to the point where those information reports that are served to our business users, who then make informed decisions based on it, can be extremely expensive to rectify. It's a classic example of garbage in, garbage out.

Here's an example of a customer that's achieved outstanding success through their use of Tosca Data Integrity, a specialized set of components designed to address this problem directly. At Worldpay, an enormous amount of money was invested in applications designed to help their business leaders make informed, data-based decisions. If there are any errors in that data and in the pipeline that delivers those information reports, it can have significant effects. Worldpay were able to achieve extreme success using Tricentis Tosca Data Integrity. They've been able to reduce the time to market, so think of that as increasing release velocity. They've been able to reduce cost by an astonishing 90%. What I think is most marked about this is that rather than traditional methods, which maybe sample a few data records here or there to judge whether we had integrity, with Worldpay, they can take a forensic approach and examine everything because of the incredible performance that Tosca Data Integrity provides.

Coming now to the third and final part of the session, what I'd like to reflect on is some of the new sources of innovation that we see and how we can future-proof this incredibly powerful engine that we've developed to support change in our enterprise applications.

If we consider the enterprise applications that are available to us today, then some level of capability is shipped in the box. We install the software; we're going to have some level of capabilities. But that's not going to be enough to support our business processes. All of the leading enterprise applications provide some level of configuration control. These are things where we go in, we don't need to be a programmer to affect change, but we do need to have a combination of domain expertise in the software application as well as subject matter expertise in our business operations. This is a larger pool of resources that we can draw on to support this work.

But at some point in all of these enterprise applications, we reach a hard limit, and that's the barrier that separates configuration from code. Just as I think it was Grady Booch who said that the history of software engineering is the rise in abstractions, we're always striving to produce tools that are far more expressive in helping us design solutions to solve problems that we face.

What we now see with the rise of low-code, no-code tooling is that the notion of who is and who is not a developer is changing. More and more people, from traditional developers to subject matter experts to power users and users, are being equipped with the tools they need to create solutions for themselves. Enterprise applications like SAP, Salesforce, and ServiceNow are very much a part of this trend. SAP recently acquired AppGyver, a provider of low-code/no-code tooling.

What that means for us in our organizations is that as this barrier is pushed further and further away, we can expect to see more solutions delivered on those enterprise applications. In a sense, those enterprise applications will provide a set of services that will be composed by and consumed in these new innovations. This is going to create a change in terms of the number of integrated applications. In some research that we conducted recently with the Americas' SAP Users' Group, organizations are forecasting a 31% increase in the number of integrated applications that they expect to support in their environments. So it becomes ever more important for us to focus on the data, to focus on the end-to-end business process.

Life is said to be about choices. We can go faster, we can reduce risk, we can lower cost. Well, with Tricentis, you can choose any three. Thank you very much for your time today. I hope you enjoy the rest of the summit. Thank you.