…it’s not just databases they are connecting (like what Talend does with Hadoop), but actually the applications themselves.
Yeah, Mulesoft’s intention is that you can connect application functions together to build what you need without custom programming (or at least not a lot of it).
it’s not just datasets in tables but real-time information captured in-App.
I don’t think that’s the proper distinction to make. It’s not data in tables vs data in memory, it’s data versus functions/operations/services. APIs enable the calling of services to perform functions. API stands for Application Programming Interface, but that was coined back in the stone age and today it simply describes how one computer program tells some other computer program to do something. Those computer programs don’t have to exist in the same process, nor on the same CPU, nor on the same server box anymore.
The old way of looking at the problem was that you had something you wanted to do/calculate/whatever, but the source data for it had been gathered by different people and programs in different ways. So, to write your program you had to get all the data together in a format for your new program to access. That required ETL. Tough as that was/is to do right,at the end of the day, you’re still having to write programs to perform functionality. The whole dream of SOA back in the 1990s was that people would write small, modular, more general purpose services and then when something specific needed to be done, someone else would simply string a combination of pre-existing services together. This was supposed to be achieved by things like WSDL, SOAP, and UDDI - all based on Web Services. But, it didn’t really happen, because the real world is messy and new things come along all the time, whether it be virtualization or containers or whatever.
What I think is going on with MuleSoft (and other companies providing what Gartner calls IPaaS (Integration Platform as a Service which provides capabilities to enable subscribers (aka “tenants”) to implement data, application, API and process integration projects spanning cloud-resident and on-premises endpoints. Essentially, we’ve finally graduated from being primarily worried about moving and transforming data around (the ETL world) and are now thinking about better ways of stringing functions together to get something useful done. Note that MuleSoft is in Garner’s “Magic Quadrant” for IPaaS vendors.
This article (https://zato.io/docs/intro/esb-soa.html explains the situation pretty well once you know that ESB is once kind of IPaaS. Don’t worry if you can’t follow it all, just skip over what you don’t understand and keep going.
All COTS (Commercial Off The Shelf) cloud-based software you license today have APIs, intended for integration with other software. Nothing is completely self contained, that would be commercial suicide. But, there’s no unification of these APIs in terms of how they’re called, how the data needs to be handled, etc. That’s where Mulesoft is trying to add value. They even have a graphical drag-n-drop tool that you can use to string together some services - no programming required. I suspect that only works for a limited set of things, but that’s just the start.
Mulesoft is probably (I don’t know, I’m speculating here) at the stage where they need to get as many commercial software pieces connected as soon as possible. That would explain all the software hiring. They talk like they have a platform which they believe can handle whatever is needed, but if you’re a Workday shop and a Workday connector isn’t available, you won’t use MuleSoft (they have Workday connectors, of course, that’s just an example).
Now, everyone that makes software provides some level of connectivity for it. If my company uses Workday for our employee/HR stuff and we want to add Concur so employee can plan travel and submit expense reports, there probably are easy ways to connect those two systems, provided by either Workday and/or Concur. I’m salespeople for each are well versed in describing how easy that is.
But, there is still a lot of software that is less pervasive or less common, plus a company will probably have specific needs that are unique to it. Maybe thre’s even have some custom stuff done in SAP or Oracle today. All companies have company-specific data processing requirements. This is where I think MuleSoft comes in.
BTW, an apparently relatively untapped area for MuleSoft is the IoT (Internet of Things) world. Greg Schott from the earnings transcript: "Yeah. I mean, what has been really exciting there, is we are – we have been pulled into a number of IoT initiatives, and frankly, without really going full bore at IoT as a segment for – certainly not from a product standpoint. And the beauty of it is, is that every IoT initiative effectively becomes an integration challenge. You have all these – it’s just more endpoints and its more connectivity, and for us, that’s a good thing. So we are getting pulled into, I mean, one of our wins in the quarter was an automotive manufacturer, and not only are they thinking about us for the backend, for their customer relationships and what the customer sees in the dealership on their web site, but they are also bringing us into the whole digital experience in the car.
We have seen that on vending machines, we have seen that on machinery, and so we are getting pulled in these IoT initiatives. We will give that as a Use Case, a big Use Case that continues to grow. Over time, I can imagine us, building out more toward that direction and offering some specific IoT capabilities. But frankly, we are just finding that we are getting used without having to go in develop something that is a solution specifically for IoT. It’s just happening."
My feeling is that this stuff is sticky. Once you’ve integrated functionality into solutions the lock-in seems pretty absolute. Even if you change out one of the underlying software components you’ll probably find it easier to connect the new component into your MuleSoft framework to replace the old one than to write a complete integration solution from scratch. That said, I could see where sales cycles are long and customer worry about development costs to get going, and on going licensing fees.