Increasing Your Team's Efficiency with RTI Professional Services

In Episode 47 of The Connext Podcast: 

• [0:27] What’s the role of Services here at RTI?
• [2:31] Why is it important for RTI to have a Services team?
• [4:03] What does a typical Services visit with a customer look like?
• [7:23] What are some of your favorite Services use cases?
• [14:17] What’s the top takeaway you want to leave our listeners with?

Related Content: 

• RTI Professional Services [Webpage]
• Customer Success Stories
• RTI Educational Services
• RTI Support 

Podcast Transcription: 

Steven Onzo: Hello everybody, and welcome to another episode of The Connext Podcast. Today, I'm joined by Fran Porcel. He's a senior applications engineer here at RTI. Fran, welcome to the podcast.

Fran Porcel: Thank you, Steven.

Steven Onzo: So, today we're here to talk about RTI's Professional Services, and I want to start by mentioning that not every software company has a services team. And if they do, the term services doesn't always mean the same thing. What's the role of services here at RTI?

[0:27] What’s the role of Services here at RTI?

Fran Porcel: Here at RTI, the role of services is to ensure that our customers are successful in using our technology. The Professional Services group is a team of people who are very experienced on DDS. Our main goal is to make customers minimize the risk of using DDS.

Steven Onzo: What are the different kinds of engagements that the Services team can provide to our customers?

Fran Porcel: Well, we can provide different types of engagements, but mainly we provide three different ones. The main one, the first way, is Quick Start training. This typically happens after the first licensing with us, and it is a three-day training where we help them get the most out of the technology. Then typically some months, even a year, after they have engaged us with a Quick Start training, they can request a Connext Support Package, or CSP as we call it. These can be very customized. It can go from a very balanced training on DDS, or it can be that they have been having a problem using the product, and they may want us to debug what's going on and they may require further advice on how to solve it in the future.

The third different kind of engagement that we have is the Architecture Studies. With Architecture Studies, we go to our customer for a couple of days and we ask a lot of questions about their project. We have very long and engaging conversations where we try and discover what they have been trying to achieve. And then we come back to the office and we spend several weeks with the whole team involved here trying to build a solution for what they're looking for. We end up providing to them a report on site, explaining what we have found out and what is the best solution for what they're trying to achieve.

[2:31] Why is it important for RTI to have a Services team?

Steven Onzo: So I mentioned before, some software companies don't have a services team. How come it's really important for RTI to have one? 

Fran Porcel: RTI is a product company - it's not a services company at all. Our goal in Services is to help our customers get the most out of our product, right? It is important to note that our product is used in many different industries. Therefore, it has a lot of different features and capabilities. The product is very powerful, but you really need to know the way it works to get the most out of it. So what we do, our work at Services, is to let the customer realize the most value from our product.

The product is great, but it is very sophisticated. It is very simple to start using it to have a couple of applications communicating with each other, but as soon as you start adding more and more applications, things may not work the way you expect. So that is why we sometimes find ourselves with our customers doing some fine tuning so that the applications work the way they need to work. When we engage with our customers, we will help them understand if DDS is necessary for the use case and maybe sometimes DDS may not be the right choice for what they're looking for. So we are also experienced in advising them on that.

[4:03] What does a typical Services visit with a customer look like?

Steven Onzo: I think some people hear the word “services” and think it's like when you call a handyman to repair something at your house. They're like, the problem is in that room, do your thing and let me know when it's done. But that can't be further from the truth at RTI - it seems like we're very hands-on and interactive with our customers. That being said, can you walk me through what a typical Services visit with a customer looks like?

Fran Porcel: Right. It's not really far from us being the handyman, repairing what's wrong, but our goal is also not just to help them repair it, not maybe repair it ourselves, but to help them repair it. And teaching them how to repair it in the future, if the problem arises again. It's a dual job, not just helping repair, but also teaching how to repair. We have different steps involved there. The first thing typically is preparation, if we require it. We are very experienced people on the technology, but still every visit needs some preparation remotely before we go on site. Then we typically have the traveling day, the day before the visit starts. It can also happen on the weekends, so sometimes you may need to take the car if you're lucky if the customer is really close to you, or you may have to take the plane typically to go across countries. 

Then there's the on-site visit. The first day is typically where we learn about their system. That can be the whole day depending on how complex the system is, because it is very important to know what's in place right now in order to provide suggestions and try and solve the customer's problem. After that first day where we have had a long conversation and several conversations on what the system currently is, we go to the hotel, we each typically have our brain 100% working on trying to find what the problem can be, trying to think of possible scenarios. And then the day after, we go to the customer and we see with them what we can improve. We provide little changes here and there. We work with them on these changes just to see how the system is behaving and we're basically applying our knowledge on their system.

After the first couple of days we do typically see that the problems start disappearing, the system starts behaving better and of course we let the customer know while we have been doing the little changes what we have been applying So that in the future, they may not even need us to put those changes in place again. After the visit we travel back home, and the project is not done at all. We work on closing the project, we write our own internal reports and feedback to our product management team and engineering, because we want the product to keep on improving and evolving for the future. That is my view on how we see the Services visits. 

[7:23] What are some of your favorite Services use cases? 

Steven Onzo: So after visiting many customers and having seen many different scenarios, what are some of your favorite services use cases?

Fran Porcel: Yeah, I always mentioned these three. The first one, probably the most important one, is that the customer hasn't designed their system properly.

What do I mean by properly? Well, what I mean is that they start with some applications, everything works okay. They start adding more and more, the number starts becoming a big number in terms of hundreds of applications in the system. They see that things are not working okay. That is typically because they are not using one of our key products, which is Routing Service. Routing Service will help them implement what we call the layered database, and that is how the system scales in the future. If their system hasn't been scaling well with their current number of applications, they may have intermittent loss of data, they're having instability. When we go to the customer to try and solve this kind of problem, we will design a new typology for them. Typically including Routing Service. The ones that need to be connected across these groups, we’ll use Routing Service for them.

Steven Onzo: This is more common in applications like legacy systems that are in different domains, and that they want to maybe connect all of these.

Fran Porcel: Exactly. They may want to connect all these - not just legacy systems but also different local area networks, for example, can be connected using Routing Service. Routing Service can also be used as a gateway between shared memory, so that different applications in the same device can connect to the outside world to a local area network, for example. But yeah, you're right. It can also be to connect legacy systems or legacy technologies that they may have. It can be useful to transform different kinds of data to DDS and from DDS. So during those visits, which are very common, the system does run smoothly. Tests that were failing before start to pass and scenarios that couldn't even be tested are even passing now. So the customer after that typically always sounds like, "I've never seen this system working so well." So that is the first visit, or important scenario that we'll always find in our customers. That is one of my favorites.

Two - we have this customer, he was running  a very complex GUI that was running very slow after our visit. We spent the first day talking about their system. They gave us a presentation on their system. We were listening to this presentation. We, after that, reviewed their QoS policies. We had long conversations. After the visit, there were no more deadlocks of course and their testing time went down by 75%. which is in the end saving a lot of time and a lot of work for them. Their GUI was working very fast. Again, the customer had never seen it working so smoothly.

Then just to wrap up this question, the discovery time, right? When you start working with DDS, your applications can take a couple of seconds to discover. That may be okay, but when you add more and more applications, discovery time can typically go to several minutes. Customers do think that this is something that's normal, but once we go there and we let them know that that is not common at all, we can go from several minutes to seconds with a proper tuning in their QoS policies.

Steven Onzo: So based on your experience, what's the biggest difference you see in customers who use Services opposed to customers who don't or have not yet?

Fran Porcel: Customers who are at the beginning of their project, customers that use Services typically know everything that they can do with our product. If they have received the quick start training, we have helped them reduce their consumption gap.

We have let them know, hey this is all that DDS can do for you. Now they know that they can use all of that, and can use all of our features that can potentially apply to their system in the future. They know the resources we have. Customers who don't engage with us, just start, they read the user's manual here and there and they don't realize all that DDS can help them do. After they have engaged with us the first time, in the future these kinds of customers that have been with us, they tend to learn things properly by themselves and they know how to properly use the product. Which is very important. They may not even need us in the future. The best way to put down a fire in the end is to prevent it from happening rather than trying to put it out after it's been happening. We're masters at that.

Steven Onzo: So being on the Services team requires you to visit different customers in different countries. From a personal perspective, what's life like on the road?

Fran Porcel: Yeah. I'm in the EMEA services team. That is, we cover Europe, APAC and the rest of the world. So being located in Spain means that you're away from everything. We typically have to take a flight from Granada to Madrid and from Madrid to any city in Europe. Then we typically do that the day before the visit happens. Then after that we go to a hotel, we sleep the night off and the second day is the first day of the visit. We go to the customer and we typically spend eight hours or more with them depending on the kind of visit and depending on how challenging the visit is being in terms of realizing what they're doing, trying to find the correct solutions for them.

Then we are like that for the number of days that the visit is happening. We spend some eight hours with them, we come back to the hotel, after that we travel back home. It is very tiring, a week of work with a customer because there's no sleeping in your bed. You have your mind totally focused on the customer problem. But in the end it is very rewarding. What I like about my job is that it is very satisfying to see the customers succeeding and their happy faces.

[14:17] What’s the top takeaway you want to leave our listeners with? 

Steven Onzo: I have one last question before we end and that's what the top takeaway you want to leave our listeners with.

Fran Porcel: What I would like our listeners to listen to at the end of this interview is that for us in the Services department, we have seen a lot of different projects. We know what to do and even more important, we know what they don't have to do. We have seen many things failing. We know how to prevent them from failing. We minimize the risk at the end of the day, that is what my department does. So in the end, we highly recommend that our customers involve us as soon as possible in their project because if they involve us at the beginning of the project, they can have a very smooth and straight forward project from the very start.

Steven Onzo: Excellent. I think that's a really good place to end. I want to thank you again for coming onto the podcast and shedding some light on RTI Services. It's always good to get some more content on RTI Services, so people just like you said, could optimize their system and make sure they don't go too far in the wrong direction before we can get in there and help them. So thank you.

Fran Porcel: Thank you very much, Steven, for having me.