Jason Mondanaro is the Director of Product Management at MetraTech, the leading provider of agreements-based billing, commerce and compensation solutions. As the leader of their SaaS billing product line Metanga, Jason works very closely with customers and engineering to develop best of breed billing applications for their diverse and growing customer base.
Last week we sat down with Jason to discuss the challenges the Metanga team encountered around SaaS integration, and the benefits they’ve seen to date working with MuleSoft as a strategic SaaS partner. As you’ll discover from our conversation below, many times the product or engineering leaders within enterprise software companies choose to build a ‘whole’ product themselves. Learn why Jason has a different opinion, and the strategic thinking that lead Metanga down the SaaS partnership route.
Q: What challenges did Metanga face around SaaS integration?
A: Sure, just like our customers are looking to specialize their business and provide value by focusing on their own product or service, as a billing software company we’re trying to do the same thing by putting less focus on integration. We want our engineers and sales resources to focus on the billing problem. We know customers need an overall solution so anything that we can do, in addition to building our core application, to reduce time to market and the cost of implementation is very critical.
Q: What are the benefits of having integration as a part your service?
A: The nice thing about it is that we don’t have to worry about the third party application or endpoint to a degree. Because the MuleSoft integration app model is highly modular, we have one Metanga connector that runs on the CloudHub platform, and pre-built integration flow that’s defined. We just have to connect to the third party application the customer wants – which, you have a large number of the application connectors already built and ready to use in your marketplace.
The other thing that is nice about that is that we really only integrate through a single connector. By having our connector set up in a CloudHub integration app, we can have multiple integrations running simultaneously off of the same SaaS instance. For example, we have five different financial systems integrations (NetSuite, Intacct, MS Dynamics, QuickBooks Online and Desktop). Our sales engineers can demo Metanga working with 5 third party applications at one time. The customer can see an invoice created in Metanga, and the same information reflected in five different accounting systems at one time. This kind of demo allows the customer to pick and choose which financial system they want to buy in addition to Metanga. It’s very powerful and allows us to show a total solution.
Q: Do integration apps impact your top line SaaS business metrics?
A: Yes. The integration apps are a key requirement of closing a sale. Customers are looking for an accelerated time to market and ease of adoption. Any time a customer is looking for an integration it needs to be scoped and has some sort of project timeline, which slows down the sales process. If it slows down the sales process, then it slows down their willingness to even consider the product as an option.
The fact that we have these integration pre-written and ready to go, and have already a scope and timeline in terms of what exactly it takes to turn on one an integration app, it alleviates a lot of concern and uncertainty in the sale – helping us to drive sales to completion much more quickly.
Q: What impact do integration apps have on your product management team?
A: From the product perspective, we like it because once the integration apps are written they’re very stable and fixed. We do schedule enhancements to them over time based on customer feedback but the idea is that the integrations are very standardized. Once we get them done they’re pretty much complete.
Also in terms of deployment, even though its part of our solution from our customer’s perspective, we’ve essentially outsourced it. For our internal staff, everything’s running on CloudHub, which is a service being provided to us. Therefore it doesn’t require any attention from our staff, it’s just a service that provides an SLA that we are happy with. It removes stress, something that I don’t have to worry about, which I can appreciate.
Q: Had you heard of an integration platform as a service (iPaaS)?
A: iPaaS didn’t start as a requirement but proved to be a big factor in our decision making process. Some of the ETL vendors wanted to sell us licensed software that we would then have to host and run in our data center. Which, while giving us a lot of control, does have an operational expense in terms of FTEs that would have to manage it, and also know how to run and troubleshoot the solution. That really added to the cost of those tools. An integration platform as a service is something that by de facto fell into the top because it really reduced the total cost of ownership of such a solution. It became a big factor.
Q: Are the integrations part of the core application or is it more of a one off?
A: I think it’s very discrete. One of the things we try to focus on as a SaaS application is having very comprehensive and well defined APIs. Therefore, from our perspective architecturally, CloudHub is a perfect fit. We have very robust APIs and the connector that runs on the CloudHub platform as a part of the integration apps uses our APIs. Although we sell integration as an add-on product, it is not actually built into the product. And I think that’s the architecturally correct way of doing it for modern SaaS applications.
Q: Why is an iPaaS using your API is the right technology approach?
A: I wanted to make sure that I have the ability for any customer or any partner to be able to access and interact with my platform. I want to avoid cheating in any scenario by allowing people to have direct access to the layers or the core code of our system, and I want to focus on making a well-defined API. A well-defined API that is scalable and robust is really the hallmark of a good SaaS application.
I’ll give you a good example of this from another industry. One of the other things I’m working on right now is evaluating BI and analytics platform to integrate with. Unfortunately all those guys want to have deep and tight integrations directly into your database – which I’m just not willing to do. I’m not willing to build into my code base a selected vendor because it doesn’t provide me any flexibility or leverage in the future with that vendor. Also, it gives me a lot of headaches. So unless they have an industry standard API interface, it’s really a non-starter with me to think about working with any of those vendors.
Q: What guidance would you give other SaaS providers?
A: I think the key thing is hiring talent for your core product. A lot of people want to have control and to build everything themselves and you have to be very ruthless defining your company’s core competency and focusing your engineers on those tasks. Wherever you can, find partners to cover all your bases. For us, integration is not our core competency. Even though we have a lot of experience doing integration from years of implementing enterprise software, it’s not our core competency, or what we’re truly here to do. We don’t want to spend time, resources, development or release cycles on that type of work. Be very ruthless in terms of what are you going to focus on. Even though you may deep in your heart want to have control over everything, you have to let go and you have to trust partners to solve problems also, especially if you’re looking to grow your business.
Q: What excites you most about your partnership with MuleSoft?
A: What I find most exciting is that the Metanga integration apps are really incredibly easy to deploy and adopt. I think a lot of people are going to be surprised because they are so used to professional services based integrations, even when they are so called ‘productized.’ Once you show customers just how easy and quick they can connect two systems, I think that will translate into a lot of interest.
No related posts.