Service virtualization solves bottlenecks amid complex billing process for German telco

German telco EWE TEL has solved performance complexity across an extended enterprise billing process by using service virtualization, which improved applications performance and gained predictive insights into composite application services behavior.

Written by Dana Gardner, Contributor Dec. 5, 2013 at 9:39 a.m. PT

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: HP.

The next edition of the HP Discover Podcast Series details how German telco EWE TEL has solved performance complexity across an extended enterprise billing process by using service virtualization.

In doing so, EWE has significantly improved applications performance and quality for their end users, while also gaining predictive insights in the composite application services behavior. The use-case will be featured next week at the HP Discover conference in Barcelona.

To learn more about how EWE is leveraging service virtualization technologies and techniques for composite applications, we recently sat down with Bernd Schindelasch, Leader for Quality Management and Testing at EWE TEL based in Oldenburg, Germany. The discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

Here are some excerpts:

Gardner: Tell us about EWE TEL, what it does, and what you do there.

Schindelasch

Schindelasch: EWE is a telecommunications company. We operate the network for EWE and we provide a large range of telecommunications services. So we invest a lot of money into infrastructure and we supply the region with high-speed Internet access. EWE TEL was founded in 1996, is a fully owned subsidiary of EWE, and has about 1,400 employees.

Gardner: Your software and IT systems are obviously so important. This is how you interact with your end-users. So these applications must be kept performing.

Schindelasch: Yes, indeed. Our IT systems are very important for us to fulfill our customers’ needs. We have about 40 applications, which are involved in the process of a customer, starting from customer self-service application, to the activation component, and the billing system. It’s a quite complex infrastructure and it’s all based on our IT systems.

We have a special situation here. Because the telecommunications business is very specialized, we need very customized IT solutions. Often, the effort to customize standard software is so high that we decided to develop a lot of our applications on our own.

Developed in house

Nearly half of our applications are developed in house, for example, the customer self service portal I just mentioned, or our customer care system or Activation Manager.

We had to find a way to test it. So we created a team to test all those systems we developed on our own. We recruited personnel from the operating departments and added IT staff, and we started to certify them all as testers. We created a whole new team with a common foundation, and that made it very easy for us to agree on roles, tasks, processes, and so on, concerning our tests.

Gardner: Tell me about the problem that led you to discover service virtualization as a solution.

Schindelasch: When we created this new team, we faced the problem of testing the systems end to end. When you have 40 applications and have to test an end-to-end process over all of those applications, all the contributing applications have to be available and have to have a certain level of quality to be useful.

What we encountered was that the order interface of another service provider was often unavailable and responses from that system were faulty. So we hadn’t been able to test our processes end to end.

We once tried to do a load test and, because of the bottleneck of that other interface, we experienced the failure of that other interface and weren’t able to test our own systems. That’s the reason we needed a solution to bypass this problem with the other interface. That was the initial initiative that we had.

Gardner: Why weren’t traditional testing or scripting technologies able to help you in this regard?

Schindelasch: We tried it. We developed diverse simulations based on traditional mockup scripts. These are very useful for developers to do unit testing, but they weren’t configurable for testers to be used to create the right situations for positive and negative tests.

Additionally, there was a big effort to create these mockups, and sometimes the effort to create the mockup would have been bigger than the real development effort. That was the problem we had.

Complex and costly

Gardner: So any simulations you were approaching were going to be very complex and very costly. It didn't really seem to make sense. So what did you do then?

Schindelasch: We constantly analyzed the market and searched for products that might be able to help us with our problem. In 2012, we found such solutions and finally made a proof of concept (POC) with HP Service Virtualization.

We found that it supported different protocols, all the protocols we needed, and with a rule set to predict the responses. During the POC we found that benefits were both for developers and testers. Even our architects found it to be a good solution. So in the end, we decided to purchase that software this year.

We implemented service virtualization in a pilot project and we virtualized even that order interface we talked about. We had to integrate service virtualization as a proxy between our customer care system and the order system. The actual steps you have to take vary by the used protocols, but you have to put it in between them and let the system work as a proxy. Then, you have the ability to let it learn.

It’s in the middle, between your systems, and records all messages and their responses. Afterward, you can just replay this message response or you can improve the rules manually. For example, you can add data tables so you can configure the system to work with the actual test data you are using for you test cases to be able to support positive and negative tests.

Gardner: For those folks that aren’t familiar with HP Service Virtualization for composite applications, how has this developed in terms of its speed and its cost? What are some of the attributes of it that appeal to you?

Schindelasch: Our main objective was to find a way to do our end-to-end testing to optimize it, but we were able to gain more benefits by using service virtualization. We’ve reduced the effort to create simulations by 80 percent, which is a huge amount, and have been able to virtualize services that were still under development.

So we have been able to uncouple the tests of the self service application from a new technical feasibility check. Therefore, we’ve been able to test earlier in our processes. That reduced our efforts and cost in development and testing and it’s the basis for further test automation at low testing cost.

In the end, we’ve improved quality. It’s even better for our customers, because we’re able to deliver fast and have a better time to market for new products.

Future attributes

Gardner: What would you like to see next?

Schindelasch: One important thing is that development is shifting to agile more and more. Therefore, the people using the software have changed. So we have to have better integration with development tools.

From a virtualization perspective, there will be new protocols, more complex rules to address every situation you can think of without complicated scripting or anything like that. I think that’s what’s coming in the future.

Gardner: And, Bernd, has the use of HP Service Virtualization allowed you to proceed toward more agile development and, as well, to start to benefit from DevOps, more tight association and integration between development and deployment and operations?

Schindelasch: We already put it together with our development, I think it’s very crucial to cooperate with development and testing, because there wouldn’t be a real benefit to virtualize the service after development already mocked up in an old-fashioned way.

We brought them together. We had the training for a lot of developers. They started to see the benefits and started to use service virtualization the way the testers already did.

We’re working together more closely and earlier in the process. What’s coming in the future is that the developers will start to use service virtualization for their continuous integration, because service virtualization has the potential to change the performance model, so you can let your application answer slower or faster.

If you put it into fast mode, then you use it in continuous integration. That’s a really big benefit for the developers, because their continuous integration will be faster and therefore they will be able to deploy faster. So for our development, it’s a real benefit.

Lessons learned

Gardner: Could you offer some insights to those who are considering the use of service virtualization with composite applications now that you have been doing it? Are there any lessons learned? Are there any suggestions that you would make for others as they begin to explore new service virtualization?

Schindelasch: One thing I’ve already mentioned is that it’s important to work together with development and testing. To gain maximum benefit from HP Service Virtualization, you have to design your future solutions. What service do you want to virtualize, which protocols will you use, and where are the best places to intercept? Do I want to replace real systems or create the whole environment as virtualized? In which way do I want to use performance model and so on?

It’s very important to really understand what your needs are before you start using the tools and just virtualize everything. It’s easy to virtualize, but there is no real benefit if you virtualize a lot of things you didn’t really want. As always, it’s important to think first, design your future solutions, and then start to do it.