Interoperability: A Dream or Reality?

2 Mar 2016
0

In this Industry Buzz podcast, UCStrategies tackles the topic of interoperability with guests from tekVizion: Chakra DeValla, CEO, and Tracy Venters, Evangelist. Blair Pleasant moderates the conversation, which also includes UCStrategies Experts Phil Edholm, Steve Leaden, Michael Finneran, Kevin Kieller, Marty Parker, Don Van Doren, Simon Dudley, and Dr. Joseph Williams.

As the UC industry's go-to lab for interoperability certification, tekVizion shares many insights on where interoperability falls apart and how to fix it. For more information visit www.tekvizion.com/.

Unified Communications Strategies Logo Sm

Also on UCStrategies.com on this topic:

Blair Pleasant: Hi, this is Blair Pleasant and I'm joined today by the UCStrategies experts. Today we have two special guests. We have Tracy Venters and Chakra DeValla from tekVizion. tekVizion helps solve the interoperability challenges facing many UC vendors and customers. Today we are going to talk mostly about interoperability. We will talk about its importance and some of the challenges that companies face especially in multi vendor environments. We will also talk a bit about certification and verification of interoperability between products, as that is something that tekVizion does.

First, welcome Tracy and Chakra, and talk a little bit about tekVizion and what it is that you do.

Chakra DeValla: Thank you, Blair. tekVizion is an independent test lab which has been helping for the last 12 years many of the vendors in this space along with service providers solving interoperability and developing solutions that can be deployed which work end to end especially when there is a multi vendor deployment that is out there in the field. As you can imagine, when this technology started out, interoperability first started as a basic SIP into working on a protocol level interworking challenges. When first interoperability was addressed it was more about, "will the protocol work between these two vendors?" and so on and so forth. We all know SIP is a standard protocol, but it has evolved. What we are seeing is it is not only at the protocol level although there are still some challenges. We all know that the protocols are standard, but it gives a lot of flexibility to enterprise and each vendor enterprise is differently to make their product more competitive in the market.

When those disparate vendor products are put together to come up with a solution the complete solution may have a challenge and that is what we here at tekVizion do. We validate the solution end to end, develop configuration guides, so whether it is service providers at enterprises or even vendors can take this and deploy it with confidence so that way they can have the trust and the guaranty that the solution will work.

Tracy Venters: Definitely, tekVizion has been in this business it was the first interoperability lab of its kind focusing on VOIP. The company started back in 2002, very much focused on voice and UC. So we have quite a specialty. The company also has among our customers and partners all the leading vendors out there that you would find any way you would call them a leader, whether it would be by some analyst report or market share. Many of them have outsourced their certification testing program to tekVizion. They have done that for a couple of reasons. One is just to offload it. As you can imagine, people like Cisco and Microsoft and all the leaders out there have a lot of different ISPs and applications that come to them and need to have that validation in the marketplace, either just to be able to sell their system as a requirement, or because they want that third party validation. So that's what we have been in business for for a long time. That third party independent validation really equals a trust factor in the market. One of the things that we are just recently announced is our tekVizion verified guaranty. What that means is that we are actually standing behind the results that we do. And we found this to be impressive in the marketplace and let me just very briefly explain what this means.

What this means is that we have a tekVizion verified solution that we have tested and if it is deployed out in the market and obviously in the same manner in which we have tested it - the same version and configuration - and there is found to be an interoperability issue once it is in the field then we will stand behind those and actually provide support either through the vendor or through the service provider or to the enterprise customer directly. We call it the good housekeeping seal of approval for interoperability.

Blair: Okay, thank you. Now I'd like to hear a little bit from some of the UC experts, what you are seeing or hearing when it comes to interoperability. Phil, let's start with you. Can you give us an idea bout the big picture out there?

Phil Edholm: Clearly interoperability has been something we have struggled with in our industry for many years. Certain areas we've done a good job of doing interoperability - basic PRI circuits, for example. But other things we haven't done well on and SIP is a great example of that. I mean the SIP standard was defined in such a way that there are choices that you can make in your SIP implementation that basically can render that implementation not interoperable with other implementations. It ranges from signaling protocol choices to how you choose the codecs that are used, how you actually activate the codecs that are used. We see innumerable problems in organizations that have challenges with this where they set things up one way, it works well with one vendor between one set of premise equipment and a carrier and alternatively.

I think it's a combination of two things. One is an unwillingness as an industry to drive to a single standard. And two, a desire for people to keep things for lack of a better word, isolated and controlled. It has introduced a huge challenge for us. I think the analogy would be if you think about Wi-Fi, if every Wi-Fi vendor of a Wi-Fi product had to test their product with every access point that was built, Wi-Fi wouldn't work at all.

I think while testing is a great concept I think as an industry we need to begin to demand more standards, more adherence to standards and general and standards that are well-defined. But it is an area that generates huge issues and we will talk a bit later about some of the steps that the industry has taken to try to mitigate those issues. Absolutely, this is a huge pain point for many customers, many users in the industry. Back to you, Blair.

Blair: Okay. Thanks, Phil. Tracy and Chakra, do you have a response to that?

Chakra: We absolutely agree with Phil's comments. Today, in spite of all of these multiple releases, if you look at any of these vendor products they have had multiple releases, but as Phil was saying in sort of converging it continues to diverge, right? They keep adding more features, but I can see the vendors' point of view on this that they want to have the feature distinctions to be competitive. For example, if you take the protocol itself it gives you so much flexibility of adding your own proprietary headers, which don't work across the vendors. So when it comes to interoperability it is a huge challenge. We agree with it, yes. In an ideal world it will be nice to have a standard protocol - while it will not eliminate testing, it will at least streamline the whole roll out of these services much faster. We definitely agree with what Phil is saying.

Tracy: Yeah, to Chakra's point definitely what we are seeing especially about the vendors trying to be competitive because if everything was implemented exactly the same then there is no competition in the market. We see the problem as being exponential for a couple of reasons - one is that there is more and more integrations today. Definitely every solution out there has to work with multiple CRMs. They have to work with multiple call reportings, multiple social media integrations. These things just keep popping up every day. The two things - one is that there are more versions today because so many companies have now adopted agile development processes so they are putting out more releases. And at the same time they are in a race to see how many integrations they have. It really has just become an exponential problem that will continue to grow.

Chakra: Absolutely.

Blair: Steve, what are you seeing out there when you work with your customers?

Steve Leaden: Yeah, Blair you know this interoperability piece is huge especially in the SIP trunking market. We happen to be involved in several very large enterprise SIP trunking reviews, designs, procurements and deployments and the first topic is always it is not easy. It starts there. As a technology itself it actually simplifies the process. We have one customers that has in excess of 100 PRIs and we are going to be consolidating that to two primary SIP trunks with plenty of sessions to handle the volume, but we have developed over a period manual test procedures over time as a firm and you know, unless you follow some best practices around deployment, in fact I'll quote from the SIP school from a 2015 survey here over 80% of current SIP trunking deployments exhibited problems and it was primarily due to the testing and proper configuration documentation that were cited as the main reasons for success. So there is a couple of things going on then I would like to pass the baton over to Chakra and to Tracy here. But one is session board controllers are always a part of the deployment and we as an independent consulting firm and subject matter expert believe that enterprise SBCs which parallels Gartner opinion about the industry at large, too, needs to be part of a SIP trunking deployment.

Of course the first question is why SIP trunking? So it kind of starts there. The basic reason is amongst other things, it's an industry trend, PRIs are about to get retired, in certain areas of the country they already announced as discontinued. The savings can be significant. I mean we are talking about annual savings anywhere from we have seen it and we have recorded it from 20% up to 60% annually and then it goes into another level where it doesn't start just with voice, it starts with voice I should say. Then we can add mobility traffic, we can add conferencing traffic and we have even challenged the carrier community to begin to look at voice - not voice I apologize video traffic over those same SIP trunks which they are already in the labs talking about those kind of discussion items. So it starts with the savings and then we consistently hear from the carrier community back to the enterprise UC vendor that the interoperability is a huge problem and effectively the session board of controller helps with that interoperability. Obviously, that is one of the functions. But it is also there to do a couple of things also to create some level of security between the carrier and the enterprise amongst other things as well as identify traffic types.

Let me pass the thought back to you Chakra and Tracy around this discussion about SIP trunking. It's been around for a while. It has been talked about for a while. I think it's gaining mainstream attention now, finally for where it's at and I think it is being driven by a lot of ROI. But yeah, there is a lot of issues that go with this if it is not given the right pay attention factors. Maybe you can share some thoughts around that.

Chakra: Yes, absolutely. Thanks, Steve. You bring up a couple of great points that we are seeing, too. One of the biggest segments that has been growing for us is the service providers that we are working with not only in North America, but Europe and globally, where they are more and more active and much more aggressive in trying to roll out the SIP trunking service. So you probably already heard of some of these major announcements from large tier one carriers here that want to end their PRI or TDM networks by 2020; similarly, we hear the same things from Europe, right? So like you said the acceleration or maybe the momentum is picking up now from the SIP trunk. We definitely are seeing that in our business. We are getting more and more requests, larger carriers, smaller carriers and across the board.

Let me bring up a couple of things when it comes to interoperability. The first one is the challenge with the service providers that they are facing today that we are seeing is from a traditional PRI world they were comfortable, they were only responsible up to the boundary of where the PRI terminated, right? They could do a loop back that the trunk was up after they are done. The enterprise telecom team or IT team whichever was responsible for that. But now with SIP being in layer seven protocol and the voice quality having an impact end to end based on whether anything happens on the LAN side. And that is where the challenge starts for these service providers in offering these SIP trunks. What they are seeing is once the problem moves from their core network from where they are very comfortable, if it moves to the LAN and they are not - that is where they are kind of challenged and that is the area we are helping them. Starting with interoperability first thing we help them test the trunk end to end and then develop a configuration guide so they can give it to their enterprise customers to provision the trunks on the PBX or the SBCs like you mentioned. So that way the interoperability they know what they are going into when they go deploy those.

And when we test we see a lot of challenges. I mean we see interoperability issues, because there are still some services that the carrier would like to offer which are not on the network. The network based features are a little bit of an overlap. All of these things will have to work together, Fax is a big issue from an interoperability perspective, right? And you bring up another point where you said best practices, right? I will give you an example. This one major operator here in North America, they rolled out a trunk with - so what is happening is when the service providers deploy SIP trunk they always - most of them - prefer to put their own edge SBC at the network edge of the enterprise. In some cases the enterprise may have their own SBC. They have a contact center. In this one example that I am quoting they had the Lync for conferencing but the regular PBX or regular voice right when it - when the customer went to turn this up this was before they start they were working with us. So they were trying this and they had to try activating that trunk seven times. And imagine having seven bad calls with this customer where the customer experience is. It is going to be really bad, the customer is not happy and they think it is SIP trunks which is the problem. In fact, I don't think that is the case. What is needed a proper testing and - after the seventh time they reached out to us and we kind of helped them and fixed their problem. That just gives you an example of the challenges.

You are spot on saying that the best practices coming out with a proper configuration document - how to configure these trunks so that way the customer experience the first time is really good and then the adoption will go up. I think that is probably one of the reasons that adoption has been a little slow until now but I think the fact that the carriers want to crack down on the TDM networks is forcing that they have to adopt some of these best practices.

Steve: And you know, Chakra, to footnote your point these networks actually on the carrier space have been IP for quite a while now and there fore the idea of using a gateway to deliver on a PRI really, why do you have another point of failure when you are designing the network when you can deliver on SIP directly to the enterprise. Let me ask you another question then - on these turn-up services that you provide to the carriers, do you do that for mid to large enterprises as well or have you thought about that?

Chakra: Actually, most of those services we are working through the carrier. We are definitely providing for large carriers and we are providing it to the mid size carriers too. Most of them offering enterprise class SIP trunk services, but what happens is a carrier would maybe activate a service. To begin with if I can step back - the carrier will come to us saying, "ok, this is a customer, and this is what environment the customer has. We want to validate this." So we will set up that environment as close to replicating as possible of the enterprise network. We test that trunk. We develop a configuration guide. So going into this activation we know exactly what works and what doesn't. And at that point we work with the carrier ops teams to help activate that trunk to the enterprise customers. So now the enterprise customers experience in this whole thing is much more satisfactory going into the trunk. And then at that point it's slowly migrating the rest of the like you said consolidating that example that you were giving, consolidating other PRIs into this trunk and so on.

Tracy: It may be also worth mentioning, Steve, that traditionally tekVizion had a lot of vendors and service providers as their main customers. We have had enterprise customers for a long time. But some of the things we are seeing are in particular verticals. For example, finance is a vertical. That's a type of enterprise that is mission critical that cannot afford for something not to work. So we have been brought into more and more of those situations where they have said hey, you know, our vendor told us that Cisco and Lync integration is going to work and we want to do an upgrade but we are not going to do an upgrade until somebody else comes in and tests all of our end points for us. So we are getting called more and more from that enterprise to say, "give me another level of trust here."

Steve: And we are seeing a lot in healthcare as well. These are very large enterprises - thousands if not tens of thousands of end points that they need to be managing and they are in the 24/7 life critical arena. These kinds of SIP trunking services as they are getting deployed have to work from day one - absolutely.

Well, I can talk all day about this so I am going to hand the mic back to Blair so we don't take up too much of the podcast time. Thanks.

Blair: Okay. Michael, I see you virtually or I virtually see you squirming in your seat. You have something to add about Wi-Fi interrupt?

Michael Finneran: Yeah - Wi-Fi typically the wifi alliance is often held up as the as a model for how this interoperability can be brought about. I always cringe at the analogy for a couple of reasons. One is well the two big ones are complexity and business need. From the complexity standpoint, as mentioned, we are talking about layer 7 compatibility. Wi-Fi is layer 1 and layer 2. Everything gets more difficult the higher you go up the stack. The other big thing is really the business need. In Wi-Fi, all the vendors going in know they have a complex protocol on the 802.11 standard, but unless they all got together and made it work the same way all, of their businesses were in jeopardy. So there was an innate need and desire among the vendors not to compete with one another directly but at least to agree on the technical standards. It appears when you don't have things like SIP, while it's no longer an existential business requirement for anyone which is why as Tracy mentioned is why we are now seeing the push for interoperability really being driven by the customers rather than by the industry itself. Back to you.

Chakra: That's very true, Michael. I completely agree with that. I think it is being driven a lot now by the industry because there is one other element to this, right? The problem is because of the multi vendor solution, it becomes who owns the problem. It's turning out that the customer who is deploying this is owning the problem. And they're owning the responsibility saying, okay you know what it is supposed to work but now I have to put all of these things together and I have to kind of juggle to these vendors kind of saying okay where is this problem, right?

I will give you an example. It may not be specific vendor's problem. This is with a large bank in London. They have many turrets, the trading floor platform and as you all know, right, recording and compliance is such a big deal especially on the trading floors. So one of the key configurations for the platform was a specific parameter if it is set to zero then the recording has to happen. And the media has to be sent to a recording platform, which then takes that and records it. And the recording platform had this parameter, which if it is set to zero implies that it records it but it doesn't have to archive it.

This bank had a problem that these recordings were recorded but they were not archived for long enough. When the bank came back to realize six, seven, eight months down the road that they didn't have six months worth of recorded messages or voices from these trading floors it was a huge problem. It is a compliance thing. Now the bank has to own that problem instead of these two different vendors. One is a recording platform, one is a turret platform. And both of them are interpreting the parameter zero correctly in their own product configuration, but who is supposed to be owning that, right?

This is where I think a lot of the enterprise customers are directly coming to us and saying hey guys, we want you guys to test this solution end to end for us so that it will meet our requirements. So that way they can, with confidence, go deploy. I completely agree what you were saying about where the problem has shifted.

Blair: Okay. Kevin, I'd like to ask you a question. As one of our Microsoft mavens, are you hearing from customers about asking for certification or verification for interoperability with Microsoft?

Kevin Kieller: Well, thanks, Blair. Myself and the enable UC team really spend our time looking for patterns that help organizations be more successful. And then we provide the technical and leadership coaching, most often with Lync or Skype for business, but often with other leading UC solutions. And you know, when it comes to interoperability in the perfect world there would be no interoperability required. You choose a vendor and that vendor would provide everything soup to nuts. In the real world where we operate, often with enterprise organizations that measure their users in the 10s of thousands, it is very clear that certified solutions with and this is where I think Chakra has emphasized this having both the certified solution and the configuration guide that is really key to making your life easier because UC is tough and it is already tough enough. Having a certified solution, having the configuration guide, especially with UC because with Microsoft, because it's easier for the end users to try out all the different features, to drag and drop somebody into a conference, to escalate from IM to voice to video Microsoft UC, more than anything, exercises all of the SIP permutations and combinations. And so having a certified, tested solution is going to radically improve your chance of success. And we work with many Microsoft Lync and Skype for Business deployments where the SIP provider has said, well nobody has pointed out that particular problem before because it wasn't a certified solution, but it was a solution that the vendor - as vendors always do - claimed that it worked would work fine but it is only once it was deployed then the problems started bubbling up.

I think Chakra said it well. The vendor might promise to own the problem, but truthfully for these large organizations at the end of the day it is always the customer who ends up owning the problem. So two key lessons that we certainly emphasize: where possible, minimize the number of vendors but it is never going to get down to one so there is always going to be interoperability. And then wherever possible choose the certified tested components because quite frankly it will make your life easier and that is certainly what we all want. Back to you, Blair.

Blair: Okay. Thanks, Kevin. Marty, can you build on this on what Kevin said?

Marty Parker: Sure, Blair. Thanks and thanks, Kevin. I think it's important not to generalize this problem and not to make it broader than it needs to be. We find that when we actually get down to the specifics of usage profiles the number of features needed for any particular usage profile is far less than the vendor offers. And by turning off features and getting down to a minimum or an optimum set you are able to find - to live - at a simpler level of interoperability. So our first advice is minimize the footprint of interoperation. The second thing we find is that clients have about three categories of interoperability that they really wish would work perfectly and the vendors seem disinclined to do that. Number one is they would like to have presence fully shared between vendors and it just isn't happening and the vendors point fingers at each other. My latest example of this is Cisco clearly can tell you whether their phones are on hook or off hook but they won't share that information with Microsoft. So they try to say you have to use the Jabber client in order to see on hook or off hook. Of course our answer is sorry, on hook, off hook doesn't matter. We are going to use a search algorithm to find the person you need anyways, so forget it.

So the vendor ends up losing the battle for the wrong reason. We want to have a consistent level of the basic functionality and we need to include like I say presence as an example basic functionality just like dial tone. The second category that we see customers wanting is click to call, and they don't want to have to do it from a webpage with a web add in. They'd like to have an easy interoperability for click to call say if I deployed Lync clients and I want to call through my Cisco infrastructure, I deployed Jabber client and I still have Avaya infrastructure in my enterprise I want to be able to click from that client and make calls through whatever infrastructure happens to be necessary, whether to reach other extensions or to reach the PSTN based on specific configurations and geographies.

There is some simple, basic stuff. Video is the third category but there is plenty of - there are many options available for video and it is a more complex world. Very simple by the way which I am delighted to see but and that is as video moves to the endpoint world rather than the fancy room system world. So we are seeing simplification, which is good, but the customer doesn't want to be on the hook. I understand what has been said here and so maybe what I'll do is turn to Tracy and ask, what, if a customer decides they want to buy insurance which is how I see your service if they want to buy insurance how much does the insurance cost them as a percentage of their product payment or as a percentage of their annual service bill? How much do they expect to pay for the insurance of coming to you for validation and a two-year guaranty?

Chakra: Yeah, thanks for the question, Marty. So when you call as an insurance the insurance is the first thing that we are seeing is let us - like you said define the feature set that you want to deploy or go with, and deploy it, and we will validate that the entire solution works. We will put it together, we will validate it and if it works then we will publish those results and at that point you are just testing for the validation part, right? Or rather you are engaging our services for the validation. And once we validate and you deploy exactly what we validated, then we will stand behind those results and support them.

Marty: So instead of the insurance analogy what does it cost me for the home inspection? I'm going to pay you something up front, what's the charge?

Chakra: The cost typically depends on the scope of what we are trying to do. I will give you an example. One of the common problems or challenges that we are seeing in the market today is when the cloud UCaaS providers are putting the phones out on the customer prem, the phones will have to download the configuration of what features to enable and blah, blah, blah. So for that, the phones have to be tested in a specific configuration. Certain features like you said limited feature set those are not expensive. But if you pick a set up like there is this one bank that we worked in New York they wanted to roll out kiosks where a customer can come in basically interact through the kiosk on a video call and based on the type of request that the customer is inputting, the call can be skilled-based routing, and all of that stuff through the correct agent or correct loan offer or whoever it is. And in that bank case there were multiple video servers, there is media servers, multiple end points that are like three or four different video end points. So that is a much more complex set up.

 

Marty: Right. I got it. So let me ask the question just one more time - just one more time - could you give us one specific example of a what you have tested and how much it cost the customer? Just give us one example.

Chakra: So for example we could test your phone it could cost anywhere from $5, $6,000 to $10,000, $15,000. If it is a video phone it will cost a little bit more. But if it is a basic phone then it could cost less.

Marty: If a customer said, "Great. I want to buy my own SIP phones and I want you to validate that is going to work with my IP PBX." Perhaps in the range of $10,000 you can validate that for them unless it was a very fancy videophone?

Chakra: Absolutely. That is exactly what it is.

Marty: Great. Thank you very much.

Blair: Simon, Marty brought up the topic of video. What are you seeing in the video world when it comes to interop?

Simon Dudley: I am kind of interested to know about the video conferencing space. The video conferencing space has since time in memorial been actively uninterested in interoperability above the most basic level. So all the manufacturers built solutions that really weren't wildly or even remotely compatible with each other. That is probably continuing into a cloud space. So in most of your world I am guessing you live in an environment where the manufacturers you are working with or service providers are interested in at least in some level in interoperability. In the video conferencing world I would argue it is probably a strong argument, they are actively uninterested in interoperability. I am kind of intrigued just to how you guys operate in a world where people you are working with don't really want to work with you.

Chakra: It's a great point and it's a great observation, Simon. You're right. There are a couple of things. Number one, the video interoperability is a bigger challenge, no question, compared to what we are seeing in the audio call and the audio world, right? Your observation I would in general concur with it that there is a lot more interest outside of the video world to some level of interoperability because there is a lot of deployments out there. This is our take why we think that there is not so much interest. Number one, the video equipment and video services are much more expensive. The vendors, we have not seen that much of interest with vendors working with other vendors, products or video mixing servers or media servers any of that. So you are right. But we do keep getting requests from the enterprise customers. One of the examples there is this one enterprise their past CTO - they already had Microsoft Lync and a new person came in and they bought a lot of the Cisco equipment. The IT team there was trying to figure out how do we make them work. We already have all of this deployed. So we kind of get those requests and they are not easy challenges like you said. In principal we agree with you there needs to be a lot more interoperability driven in the video world.

Blair: Don, let's change a little bit and talk about contact center. What are you seeing in terms of contact center?

Don Van Doren: Thanks, Blair. Well, both Tracy and Chakra have mentioned some of the kinds of issues we are seeing in contact centers in particular call recording was brought up by both of them. I think this is one of the examples of where we have had specialized companies that have developed specialized services, workforce management, workforce optimization, and now the business about really getting much more involved in customer engagement and therefore integrating into CRM solutions. The other challenge that we see is that there are so many new things coming along, social media, mobility solutions, etc. that what's happening in many contact centers is they are just adding windows on an already crowded desktop. I think what would be really helpful is if we can get to a situation where we had dashboards that would enable these kinds of new functionalities embedded into the primary application whether it is Finesse or whether it is SalesForce.com or any number of the other vendors where the contact center agent is spending most of their time. I guess I would be curious as to whether Tracy and Chakra see that kind of testing going on as well in terms of how people are doing some of that kind of embedding work.

Chakra: We are seeing a lot of like you said in a contact center especially like for example recently we just got on request where a major vendor with the service provider they were working on this insurance company and integrating a single sign on with computer associates I think it is Site Minder or something like that. We get those requests from integrating all of these other applications and services. But like you said, where the desktop is getting crowded, and kind of coming up with a more simplified dashboard for customer information and things like that I have not come across it myself, but not to say I have seen every test that comes to our lab. You are right. There is a lot more that has been getting crowded onto the desktop. I personally have not seen it but it is possible our team must have seen it.

Tracy: Well, okay, thank you. That is kind of where I would like to do a little plug. We have just unleashed a brand new website. It is tekVizionVerified.com. If you go there, it's a very powerful search engine. You could type in contact center. You can type in call recording. You can type in Cisco, type in Comcast. Either a vendor name or service provider name or a type of application such as that. And it will bring up over the years I mean tekVizion does hundreds and hundreds of tests each year. We have very many in place. This is an easy way for anyone to go and see what has been independently verified by us.

Blair: Okay. Time for one more question. Joseph, I believe you have a quick question.

Joseph Williams: I do. Somebody brought up Agile earlier and my sense as a software reliability guy is that systems are getting less reliable. If that is true, what role does your company play in that agile development cycle to help produce better solutions over all?

Chakra: Yeah. So you know, one thing we have - what we have done is we actually started working to become more efficient internally being a test lab. We developed what is called onTap. It is a platform where we can optimize and become more efficient from a testing perspective. How to maximize the utilization of our resources and after that we can save and come back to our work at some point later in time. One thing we realized was this is very helpful and useful especially in the agile environment where there is a continuous testing has to be the kind of paradigm, which aligns with the continuous development cycles of the Agile. That is when we started commercializing it and we launched what is called onTap for Devcast. We started getting very good response. People are starting to utilize it very well, but what is interesting is it kind of led into new avenues. Our customers started realizing that, hey I can use this for this other idea, where for example we can put this in a production environment and give this access to our sales team and they can do sales demos when they go to a customer site so they don't have to kind of drag their engineering team constantly to set up a demo for the customer visit or whatever.

Other scenarios like that that we have come across. But to go back to your question of Agile we have this platform called onTap. If you log into our website you should be able to see it. It is as simple as a couple of clicks you can reserve the lab. Then once you click your system you can reconfigure it to continue the testing. As new loads are released you will upload the load and it will continue to keep testing. That is the idea. We agree that the testing has to be configured to align with the agile development methodology.

Tracy: Just a final point on that. onTAP can be rented for a day. It can be rented for a week. It is totally in the cloud. Why we say it is as easy as ordering a pizza, it really is to log in and say I need a complete Skype for business environment with SBCs and 6 DIDs etc. or I need a Cisco environment, I need Avaya, or something like that. And this is where I think it really helps with Agile. With the Agile environment where we see that development cycles are very short, what can negate that would be if someone then had to say, "what I need is to test this in the environment" - and the procurement time, to get that system, to get it up and running can negate that cycle. With onTAP, just log into it. Use it a day. Use it a week. Use it a month whatever you need it.

Chakra: Only pay when you use it.

Blair: This is clearly an important topic that people are very interested in. I would like to thank Chakra and Tracy for spending the time with us and for helping us to understand not only the issues that they see but also for providing information about tekVizion and how it helps provide ways of overcoming the interoperability challenge. And thanks to all the UC experts who provided their insights today and we will see you all next time.

 

Comments

There are currently no comments on this article.

You must be a registered user to make comments

Related Vendors