Service Virtualization and Enterprise Resource Planning Platforms

With modern software relying on myriad interactions with other components, greater complexity in development and testing has become inevitable. Nowhere is this more evident than with enterprise resource planning (ERP) platforms, where dozens of modules are interdependent upon one another for data exchange, processing, and other core functions.

Add to this the likelihood that an ERP system may also need to interact with software platforms running on the systems of external partners, and the challenge of testing in a service-oriented environment can appear overwhelming. Fortunately, tools and technologies exist that can address this challenge, not only for software testing in general but also for ERP systems, specifically.

As many developers and testers know, one well-publicized mechanism to enhance both functional and performance testing with modern software is service virtualization. Yet, given how readily an enterprise can acquire a truly robust service virtualization product (often called an “SV tool”), I am continually amazed at how many enterprises have not adopted the approach.

For those who are developing and testing ERP platforms, such a decision makes thorough testing nearly impossible, essentially guaranteeing problems in production. If you are a developer, tester, or business analyst working in a company that hasn’t mastered service virtualization - and especially if you work with ERP platforms - there has never been a better time to advocate for change.

Stop Stubbing; Start Succeeding

For more than a decade, stubs have been the “go-to” solution when software under development relies upon components, whether third-party or internal, that aren’t ready or available. R&D folks (most often, developers) write stubs to simulate the necessary action from the missing component, enabling development to continue. The developer owns the code; he or she controls its destiny and specific functionality.

When testers need to test the same component, they have the choice of trying to borrow a stub that might not perfectly suit their needs or write their own (or get someone else to do it). Both of these solutions are highly inefficient. On the development side, the developer is wasting time managing stubs. (According to the companies with which we work that use stubs, 20-40 percent of their developers’ time is expended on stub management.) On the quality assurance side, testers’ efforts are being delayed or quality is being reduced due to stub acquisition and/or programming.

Especially in agile development, which is all about self-service, this approach simply isn’t practical. The people who need to access the components also need to control their own destiny. If they have a need or an idea, they should be able to handle it themselves and not disrupt the flow of development and testing.

Stubs also aren’t scalable; they aren’t adaptable enough to accommodate different scenarios or data sets; and due to the specificity with which they are written, they often aren’t even repeatable. For a process that consumes so much development resource, that is untenable.

Let’s compare this scenario with one in which an enterprise has adopted service virtualization. There are three key differences between service virtualization and the traditional approach of using stubs.

- Availability: Once a behavior is virtualized, everyone has access to the same virtualized service, which not only expedites development and testing but also ensures consistency. Even if the component hasn’t been launched yet, team members can program the tool to deliver the expected input and output, allowing testing and development to continue.

- Scalability: SV tools aren’t constrained by human resources. Whether a test needs to be run 100 times or 100,000, the tool is up to the challenge, with little to no manual intervention.

- Adaptability: Virtualization supports different scenarios and data variations - including not only varied responses and response times but also errors. In modern software processing, unanticipated changes are common. For software to perform nimbly, it must be able to adapt to longer or shorter transaction times and perform consistently even when results don’t match expectations. Testing must address these needs to ensure quality, and service virtualization makes it easy for testers to accomplish that goal.

Modern SV tools also make a quantum leap in terms of self-service. There is no need for a developer to relinquish the code for his stub; no need for a tester to write his own. I say modern here, because not all SV tools are created equal.

Early SV tools were programmatic in their implementation. This approach helped the R&D team but did not take into consideration the differing skill sets of the testing area. Indeed, these early solutions resulted in a second set of code that a developer had to manage and apply changes to, as well, increasing their workload and not really solving the issue of tester dependence on R&D that was introduced by stubbing. 

Modern service virtualization solutions, such as those I am describing here, are designed to greatly reduce the complexity of creating and managing service virtualization while maintaining flexibility across different protocols.  This approach enables the developer, functional tester, and performance tester personas to fulfill their service virtualization requirements without requiring the assistance of others.

Until now, we’ve been discussing service virtualization in general and not how it applies to ERP platforms. I wanted to set the stage for the central theme of my assertion, which is, “all the challenges of traditional simulation methods, such as stubs, are amplified with ERP and other large-scale, modularized software systems.”

With ERP systems, users aren’t relying on a single, stand-alone software program (or even a composite) to interact successfully with other components. That’s difficult enough to test, but with ERP, an array of internally connected and interdependent modules - essentially composite applications in themselves – must successfully interact with one another. They also must be able to interact across corporate boundaries and with other external components and services. Additionally, multiple users must be able to work and collaborate simultaneously from within that grouping of modules.

If a salesman’s corporate quote generator experiences a glitch when it cannot connect to an external service for shipping rates, for example, the salesman apologizes and tells the customer he’ll email him the quote when he returns to the office. When the plant operations module in an ERP platform cannot connect to the inventory module and confirm availability for the next job run, it could shut down the manufacturing line.

Even worse, the error could replicate across the entire interconnected system and leave all users experiencing errors and outages until the faulty code is identified and corrected. In B2B environments, where two companies that use ERP software might communicate via the platform itself, problems can be even more disruptive.

From the testing perspective, ERP systems (and for that matter, any large-scale, modularized software platform) bring additional challenges, as well. One of the most prevalent occurs when multiple testers are working in the same test beds. It’s nearly impossible for them to perform their tests effectively if they cannot change data to perform different tests, and yet doing so is almost certain to negatively impact the activities of other testers. Service virtualization resolves all these challenges.

To illustrate my point, I’ll share a real-world example with you. This is from my direct experience working with companies running SAP, a leading ERP platform, and using the integrations of HP Service Virtualization to handle their service virtualization needs. (I like this case, because HP Service Virtualization is the only SV tool to have been certified by SAP.)

In this case, a large, global product developer and one of its manufacturers in China both run SAP. The developer wanted to test the manufacturer’s SAP “background systems” - such as customer service, accounting, and manufacturing - which would be receiving instructions directly from the developer’s SAP system in the U.S.

The manufacturer wasn’t willing to allow testing on its live system, because the developer’s testing team would be hitting it so intensely that it would impact other operations. With the help of HP Service Virtualization’s SAP integrations, the developer was able to virtualize the manufacturer’s SAP modules and perform necessary tests against them. The order went forward, and the launch was a success.

To see how this worked so well, let’s break down the activities that the SV tool accomplished or enabled:

1. Captured all SAP-to-SAP communications between the two companies’ systems.

2. Virtualized only those modules to which the developer’s SAP system would make calls.

3. Allowed testers to fully test the targeted processes with an array of variables.

4. Worked around testing restrictions and eliminated the possibility of any real-world performance impacts, since no live SAP systems were tested.

In essence, a module-to-module connection is a long daisy chain. Once testers have provided the test criteria, SV tools will find the relevant modules and isolate them for virtualization.

This design enables enterprises to identify the modules they need to test for other reasons, as well. For example, with historical data from performance logs, organizations can pinpoint the modules that might break with a new update and virtualize only those elements. There is no need to virtualize the entire ERP platform, and there is never a reason to stand up a completely separate ERP system and make calls to actual modules in real time.

Of course, implementing service virtualization for ERP, SAP, or even stand-alone software cannot 100% guarantee that a production error will never occur. What it will do is expedite service testing, enable teams to scale their testing exponentially to explore unlimited scenarios, and increase productivity and test coverage within the same resource pool.

For ERP platforms - and for that matter, any software ecosystem that involves communication among myriad enterprise departments and potentially trading/business partners - seamless, efficient, any-to-any data exchange is becoming paramount to operability. Service Virtualization is the only testing solution that can meet that challenge.