MuleSoft Takes Full-Service Integration to the Cloud with iON Platform, iApps Marketplace

Transcript of a sponsored podcast on MuleSoft's new iON cloud integration offering that provides new hosted integration abilities for enterprises, SaaS providers and system integrators.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Join the iON beta program. Sponsor: MuleSoft.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect.

Welcome to a sponsored podcast discussion on how enterprise application integration (EAI) as a function is moving out of the enterprise and into the cloud. So called integration platform as a service (iPaaS) has popped up on the edge of the enterprise. But true cloud integration as a neutral, full service, and entirely cloud-based offering has been mostly only a vision.

Yet, if businesses need to change rapidly, as the cloud era unfolds, to gain and use new partners and new services, then new and flexible integration capabilities across and between extended applications and services are essential.

The older point-to-point methods of IT integration, even for internal business processes, are slow, brittle, costly, complex and hard to manage. Into this opportunity for a new breed of cloud integration services steps MuleSoft, a market leading, open-source enterprise service bus (ESB) provider, which aims to create a true cloud integration platform called Mule iON.

MuleSoft proposes nothing short of an iPaaS service that spans software as a service (SaaS) to legacy, SaaS to SaaS, and cloud to cloud integration. In other words, all of the above, when it comes to integrations outside of the enterprise.

We'll learn here today about MuleSoft iON, how it works and its pending general availability in the summer of 2011. We'll also delve into the potential for an iON marketplace that will provide integration patterns as shared cloud applications, with the likelihood of spawning constellations of associated business to business ecosystems.

Here to define the vision for a full-service cloud-based integration platform solution are two executives from MuleSoft. Please join me now in welcoming Ross Mason, Chief Technology Officer and Founder, MuleSoft. Welcome, Ross.

Ross Mason: Hi, Dana.

Gardner: We're also here with Ali Sadat, the Vice President of Mule iON at MuleSoft. Welcome, Ali.

Ali Sadat: Hi, Dana.

Gardner: Ross, tell me a little bit why have things changed so much that a fundamentally new approach to integration is required?

Mason: There are a number of drivers in the marketplace pushing us toward integration as a service and particularly iPaaS. First of all, if we look back 15 years, integration became a focal point for enterprises, because applications were siloing their data in their own databases and for business to be more effective, they have to get that data out of those silos and into a more operational context, where they could do extended business processes, etc.

What we're seeing with cloud, and in particular the new wave of SaaS applications, is that we're doing a lot of the same mistakes for the same behaviors that we did 10 years ago in the enterprise. Every new SaaS application becomes a new data silo in the cloud and it’s creating an integration challenge for anyone that has the data across multiple SaaS providers.

New computing models

And it's not just SaaS. The adoption of SaaS is one key thing, but also the adoption of cloud and hybrid computing models means that our data also no longer lives behind the firewall. Couple that with the drivers around mobile computing that are enabling our workforce and consumers, when they are on the go, again, outside of the firewall.

Add the next social media networks and you have a wealth of new information about your employees, customers, and consumers, available through things like LinkedIn and Facebook. You've also got the big data explosion. The rise of things like Hadoop for managing unstructured data has meant that we end up pushing more data outside of our firewalls to third party services that help us understand our data better.

There are four key drivers: the adoption of SaaS applications; the movements by using more cloud and hybrid models; mobile is driving a need to have data outside of the enterprise; and then social media and also big data together are redefining where we find and how we read our information.

Gardner: So, it seems to me Ross that the older ways of doing this were plausible when we had the majority of integration points inside the firewall and maybe just a handful or a couple of external points. But what’s happening is the shift, as you are describing about these trends, is making it increasingly more points outside than inside.

It strikes me that we're moving the fulcrum or the balancing point of the number of integrations that need to be supported further and further toward the edge -- and then ultimately outside the organization. So do you agree with that? Is this for your average enterprise that we’re going to start to see this avalanche of outside integration points?

Like it or not, any company of any size has some if not most of its data now outside of the firewall.

Mason: Absolutely. We describe it internally as the center of the enterprise gravity is shifting. The web is the most powerful computing resource we’ve had in the information age, and it’s starting to drag the data away from the enterprise outside into the platform itself. What this means for enterprises is, like it or not, any company of any size has some if not most of its data now outside of the firewall.

I'm not talking about the Fortune 2000. They still have 95 percent of their data behind the firewall, but they’re also changing. But, for all of the enterprises and for forward-thinking CIOs, this is a very big and important difference in the way that you run your IT infrastructure and data management and security and everything else.

It turns a lot of things on its head. The firewall is constructed to keep everything within. What’s happening is the rest of the world is innovating at a faster speed and we need to take advantage of that inside enterprises in order to compete and win in our respective businesses.

Gardner: It also appears that there will be a reinforcing effect here. The more that enterprises use cloud services, the more they’ll need to integrate. The more they integrate, the more capable and powerful the cloud services, and so on and so on. I guess we could anticipate a fairly rapid uptake in the need for these external integrations.

Mason: Absolutely. We’ve been blown away at MuleSoft at the demand for iON already. We think we might be a bit early in carving out the iPaaS market, but the response we're hearing, even from our largest organizers, is that most have lots of needs around cloud integration, even if it's just to help homogenize departmental applications. [Join the iON beta program.]

New enterprises

But, we're talking to a lot of other CIOs who are looking at the cloud as the way they're going to go in the next three years, and they look at everything as being cloud-based versus on-premise if possible. We see this a lot in the new enterprises that have grown up in the last five years as well.

Gardner: And, MuleSoft has been a leader with an open-source model. How do you see the open-source values and benefits aligning with some of these cloud effects, as we’ve been describing?

Having a platform that’s open and freely available and that they can migrate off or on to and manage themselves is extremely important.

Mason: The open-source model is absolutely critical, and the reason is that one of the biggest concerns for anyone adopting technology is who am I getting into bed with? If I buy from Amazon, ultimately, I'm getting into there with Amazon and their whole computing model, and it’s not an easy thing to get out.

With integration, it’s even more of a concern for people. We’ve looked through the vendor lock-in of the 1990s and 2000s, and people are a little bit gun-shy from the experiences they had with the product vendors like Atria and IBM and Oracle.

So, when they start thinking about IaaS or the cloud, then having a platform that’s open and freely available and that they can migrate off or on to and manage themselves is extremely important. Open source, and particularly MuleSoft and the Mule ESB, provides that platform.

Gardner: Ali, let’s move to you. If you don’t mind, let’s talk a little bit about the problem set. Certainly, the vision is there, the market drivers are there, and the opportunity executing on this then becomes the issue. So how do you see process enablement happening? How can different types of integrations now come into this neutral cloud domain, and what sort of integrations are we talking about?

Sadat: It’s a pretty interesting problem that comes up. The patterns and the integrations that you need to do now are getting, in a sense, much more complex, and it’s definitely a challenge for a lot of folks to deal with it.

We’re talking not only to cloud-to-cloud or enterprise-to-enterprise, but now extending it beyond the enterprise to the various cloud and the direction of data can flow either from the enterprise to the cloud or from the cloud to the enterprise. The problems are getting a little more challenging to solve.

The other thing that we’re seeing out there is that a lot of different application programming interfaces (APIs) are popping up -- more and more every day. There are all kinds of different technologies either being exposed to traditional web services or REST-based web services.

We’re seeing quite a few APIs. By some accounts, we're in the thousands or tens of thousands right now. In terms of APIs, they're going to be exposed out there for folks who are trying to figure out and how to integrate. [Join the iON beta program.]

Gardner: Given that there is this variety of integrations and more types of integrations across different types of organization, where do we give the capability for managing this? It’s one thing to put the integration execution functionality in the cloud, but what about the driving tools, the ability to define and create the integrations and to manage them? What do you propose for that?

Hybrid world

Sadat: It’s something a hybrid world, and I think the answer to that is a hybrid model, but it needs to be very seamless from the IT perspective. The difference between integration running on premise or in the cloud shouldn't matter as much, and the tooling should be the same. So, it should be able to support both a cloud-based management, and also be able to manage and drive us in the enterprise, and set up on-premise tools.

Gardner: I see. So, we’re looking at open but familiar, agnostic in terms of the hosting environment or perhaps multiple environments, and then the secure and compliant mission-critical characteristics that most organizations are now familiar with and have created the means to support.

Tell me how this works with iON. What’s changing? What would I, as an engineer in an enterprise IT department, see differently about this?

Sadat: One of the things you’ll see about iON is a lot of familiar components. If you have been a Mule user or Mule ESB user, you will see that at the heart of iON itself. What we're providing now is the ability to be able to deploy your solutions, your integration applications to a cloud and be able to manage it there, but we also are going to give you the capability to be able to integrate back into the enterprise.

There will be some very similar aspects of Mule that you’ll see as part of iON and also some very new components. The pieces that we're going to take away are the infrastructure. Trying to manage, download, and install all of those things naturally just goes away by the nature of that being cloud.

What we're providing now is the ability to be able to deploy your solutions, your integration applications to a cloud and be able to manage it there.

Gardner: Here's the question I get a lot from folks. If the tooling is similar and if the underlying technology being an open-source stack is similar, why can’t I just use my existing enterprise point-to-point, EAI functionality for this extended enterprise cloud activity? What’s the answer to that?

Sadat: The answer to that is a great analogy. If you look at their current applications why can’t I just take my Oracle and SAP application, stick it into Amazon Web Services (AWS), and call that a cloud.

Let me walk you through a quick example here. A lot folks have been deploying Salesforce as an application. It has definitely been very popular, probably number one out there. Now, they want to integrate this back into their SAP applications.

If I want to do a real-time integration between Salesforce and an SAP, how do I enable that? If I poke holes from my firewall that’s going to definitely expose all kinds of security breaches that my network security folks are not going to like that. So how do I enable that? This is where iON comes into play.

We’re going to sit there in a cloud, open up a secure public channel where Salesforce can post events to iON, and then via a secured connection back to the enterprise, we can deliver that directly to SAP. We can do on the reverse side too. This is something that the traditional TIBCOs and WedMethods of of the world weren’t designed to solve and they weren’t even thinking about this problem when they designed and developed that application. [Join the iON beta program.]

Across boundaries

Gardner: Okay, so businesses are going to need to find ways of integrating across these boundaries, taking advantage of more services that become available but managing the data across them. What needs to be completely different about your vision of a neutral cloud based capability or platform?

Suppose we could ask, why not just use what Salesforce provides you and let that be the integration point? Why would you separate integration cloud capability?

Sadat: Integration, as a whole, is much better served by neutral party than just going by any one of the application vendors. You can certainly write custom code to do it, and then people have been doing it, but they've seen over and over that that doesn’t necessarily work.

Having a neutral platform that speaks to APIs on both sides is very important. You’re not going to find Salesforce, for example, adopting SAP APIs, and vice versa. So, having that neutral platform is very important. Then, having that platform and being able to carry out all the kinds of different integration patterns that you need is also important.

We do understand the on-premise side of it. We understand the cloud side of the problem. We're in a unique position to bring those two together.

Having that platform and being able to carry out all the kinds of different integration patterns that you need is also important.

Gardner: Let’s go back to you, Ross. Please define for me what you consider the top requirements for this unique new neutral standalone. I guess you could call it the Switzerland, the ESB of ESBs, the integration of integration points. What do you think are important characteristics for this to have that maybe you can’t do for your SaaS provider and you can’t do on-premises?

Mason: I'll start with the must-haves on the PaaS itself. In my mind the whole point of working with a PaaS is not just to do integration, but it’s for a provider, such as MuleSoft, to take all the headache and hard work out of the architecture as well.

For me, a true PaaS would allow a customer to buy a service level agreement (SLA) for the integration applications. That means we are not thinking about CPUs, about architecture, or I/O or memory usage, and just defining the kind of characteristics they want from their application. That would be my Holy Grail of why a PaaS is so much better?

For integration, you need that, plus you need deep expertise in that integration itself. Ali just mentioned that people do a lot of their own point to points and SaaS providers do their own point integrations as well.

We spend a lot of money in the enterprise to integrate applications. You do want a specialist there, and you want someone who is independent and will adopt any API that makes sense for the enterprise in a neutral way.

We’re never going to be pushing our own customer relationship management (CRM) application. We're not going to be pushing our own enterprise resource planning (ERP). So, we’re a very good choice for being able to pull data from whichever application you're using. Neutrality is very important.

Hugely important

Finally, going back to the open-source thing again, open source is hugely important, because I want to know that if I build an integration on a Switzerland platform, I can still take that away and run it behind my firewall and still get support. Or, I just want to take it away and run it and manage it myself.

With iON, that’s the promise. You’ll be able to take these integration apps and the integration flows that you build, and run them anywhere. We're trying to be very transparent on how you can use the platform and how you can migrate on as well as off. That’s very important. [Join the iON beta program.]

Gardner: Before we get into the details of your recent news, help me understand what you just mentioned about these patterns and these applications. If they're portable, as you are describing, then it seems to me that you’re creating an ecosystem, almost an opportunity in the market, for a new type of independent software vendor (ISV) or services vendor.

Describe for me how you'd expect a community-based approach or market-place based approach to happen with these integration patterns. What will motivate people to want to get in there and do the hard work creating them in the first place?

Sadat: The marketplace approach works because of the domain expertise you need for all these various applications. It’s hard for a neutral player to have enough deep expertise in every application that’s out there and every business process to build it out. You have seen number of vendors have tried, and even the ones who owned the applications have tried and failed.

It’s hard for a neutral player to have enough deep expertise in every application that’s out there and every business process to build it out.

If you look at the Oracle AIA and the PIP approach, they tried to build it all themselves and it just doesn’t work. Having a marketplace where people with their own intellectual property and their own expertise come out and build these solutions and offer it out to customer is a much more viable approach.

Gardner: Do you see this as a way for organizations to share this on an open-source community basis, where one hand washes the other or is there a business model, where creating integrations and being in a systems integrator role is a business and encourages more participation?

Sadat: I think you’ll see both. That’s one of the great things about the cloud and the Internet today. You can probably do a Google search and find pretty much any piece of code that you want and use it. But, at the same time, there’s an opportunity here for folks to be able to build and package some of these intellectual properties that they have as a series of integrations between applications and offer that as a service that they can charge for.

We’ve seen a lot of system integrators (SIs) who are throwing out their own custom solutions and sourcing it on AWS or somewhere else. We see those folks coming to us, and since we’re going to be providing this platform, they can run it, manage it, and monitor it all from our solution. We also give them the capability to monetize that on the same platform.

Gardner: Now that we’ve got a sense of the general problem and vision for what’s needed and a sense of what your requirements are, let’s look at the timing. You’ve come out on May 23 with the announcement about iON and describing what you intend.

Furthermore, you’re going to be coming out a little later with the general availability of iON as a platform in July. And then you’re going to be delivering some of the first iON applications shortly thereafter. So help me understand, Ali, why you’re doing it in this fashion? This is, I suppose, the basic crawl, walk, run approach. Is that it?

Public beta

Sadat: That’s correct. We started with our private beta, which is coming to an end. As you mentioned, we’re releasing a public beta. Pretty much anybody can come in, sign up, and get going in a true cloud fashion. [Join the iON beta program.]

We're allowing ourselves a couple months before the general availability to take in feedback during the beta release. We’re going to be actively working with the beta community members to use the product and tell us what they think and what they'd like changed.

One of the other things we’re doing soon after the general availability is releasing a series of iON applications that we'll be building and releasing. These will be both things that we’ll offer as ways to monetize certain integrations, but also as reference applications for partners and developers to look at, be able to mimic, and then be able to build their own applications on top of it.

Gardner: Okay. What does iON consist of? What are we talking about in terms of what you’re going to be offering for those people that go into a beta or look towards a general availability? What is it they are going to get?

Sadat: At the core of it, they get Mule. That’s pretty essential, and there’s a whole lot of reasons why they do that. They get a whole series of connectors and various transports they can use. One of the things that they do get with iON is the whole concept of this virtual execution environment sitting in the cloud. They don’t have to worry about downloading and installing Mule ESB. It’s automatically provided. We'll scale it out, monitor it, and provide all that capability in the cloud for them.

Once they’re ready, they push it out to iON, and they execute it. They can then manage and monitor all the various flows that are going through the process.

They just need to focus on their application, the integration problems that they want to solve, and use our newly released Mule Studio to orchestrate these integrations in a graphical environment. Once they’re ready, they push it out to iON, and they execute it. They can then manage and monitor all the various flows that are going through the process.

Gardner: Are there multiple tiers of integration or are you going to be a full-service integration provider at the start. Is there a crawl, walk, run approach to the depth and breadth of the integrations as well?

Sadat: Well, you know one thing about the cloud is that folks want to go out and buy all kinds of different applications that represent probably best of breed for each. You go buy CRM for Salesforce and perhaps go to SAP for ERP or maybe one of the Oracle applications. But, when it comes to integration, you don’t want to go the best-of-breed approach and then try to integrate all those different integration solutions. It just doesn’t make sense.

So, it’s important for iON to support all the different tiers of integrations. There are just three data-level integrations, synchronization at the process-level, and also the UI level. We're not necessarily going to compete with every vendor that makes their bread and butter in any one of those tiers and compete on every minute functionality that perhaps is going to be used maybe once or twice. But, we are going to provide probably 80-90 percent of what you need out of the gate with iON.

Gardner: You mentioned that what you get with this is Mule. Maybe this is a good time, Ross, for you to give us a brief history of Mule and MuleSoft and why you've become a leader. What's the amount of penetration you've got globally for those folks who might not be that familiar with your open-source legacy.

Wider integration

Mason: MuleSoft started originally as an open-source project that I started back in 2003. I'd been working as an architect in various banks in the UK, and we'd seen a need for a much better and wider integration than we were doing at a time, which was more of and enterprise information integration (EII)-based integration.

The project started in 2003. We went to version 1.0 in 2005 and we got massive pick up pretty much across all verticals and our customer roster echoes back to that as well.

The interesting thing about MuleSoft, the reason why we've done so well in the space, is that we stayed very true to a couple of key principles. One was simplicity. Just being able to integrate something well and easily and simply is hugely important.

There is a statistic that says we spend probably $1 on applications and we spend $7 on integration in the enterprise. We aimed to reduce that cost by providing much cleaner, simpler, and easy to use tools to developers without too much knowledge.

We stuck with that philosophy of simplicity all the way through, and it helped carry us through lots of other phases and now with the cloud. It’s a very nice fit, because if you're integrating with many more applications, you've got to make it super simple for people to do so. MuleSoft has made great strides to do that, coupled with the fact we've always been promoting a non point-to-point integration approach.

We stuck with that philosophy of simplicity all the way through, and it helped carry us through lots of other phases and now with the cloud.

Our software does all the heavy-lifting for you. It will decouple your data and application logic from your runtime. It scales very well, and we have some of the biggest companies in the world running Mule with mission-critical applications. In fact, we have about 3,000 production deployments that we track right now, so it’s probably one of the largest ESB deployment bases that is out there on open source.

We've got very good penetration and we continue to try and innovate and push the envelope forward of what you should expect from a new integration provider. That’s why we're going down this iPaaS route, because we believe we are the best vendors to do the job. [Join the iON beta program.]

Gardner: Ali, we’ve mentioned that moving into the cloud is an opportunity with your being neutral and discussed why that’s important. It seems to me, however, that there is also a channel opportunity that not just enterprises will be looking to this. There is a whole ecosystem of different hosting providers, managed-service providers (MSPs), SaaS providers, colocation providers, all of whom have a vested interest in allowing companies to move their applications and data to be portable to explore and experiment with these different hybrid computing models.

Do you expect that iON in the cloud is going to be something that not only would be appealing to enterprises but also to these other players in the ecosystem, and how will that work?

Sadat: We see that as a huge opportunity for iON. Today, they don’t have a whole lot of choices in terms of being able to build and embed OEM services in a cloud fashion into various applications or technologies that they are building. So, iON is going to provide that platform for them.

Embeddable platform

One of the key things of the platform itself is that it is very embeddable. Everything is going to be exposed as a series of APIs. SIs and SaaS providers can easily embed that in their own application and even put their own UI on top of it, so that underneath it it says iON, but on top, it’s their own look and feel, seamlessly integrated into their own applications and solutions. This is going to be a huge part of iON.

Gardner: Well, it's one thing to describe something, but what can you tell us about folks that have been in your program, that have explored integration as a service from a cloud provider perspective or source? Are there any examples that you can provide for us? What they have done with it and what it's done for them?

Sadat: Sure, we can talk about one of the partners that it’s looking to probably be on iON as one of the first adopters from a SaaS provider and this is PeopleMatter. If you're not familiar with them, they are a very fast growing SaaS provider. They provide an HR solution for the service industry. This is for restaurants, hotels, small organizations that provide service and there is a lot of churn in terms of employees coming and leaving.

So, they simplify that model. As you can imagine, the clientele that they are working with is not going to be as sophisticated. Probably it might be a restaurant chain that owns 10 restaurants, but has a very simple IT infrastructure if any.

So, iON is going to be able to provide a quick integration. It will be something that will be embedded in their application that they can offer to their customers as a very seamless piece of their solution. Their customers are not going to be exposed to integration complexity, and it’s going to be something that you just pick and choose and integrate directly with their applications without having any issues.

It will be something that will be embedded in their application that they can offer to their customers as a very seamless piece of their solution.

Gardner: How do you charge for something like that? Who is involved? With your open-source approach you charge around support, maintenance, and professional services. When you move to a cloud environment and offer a pure neutral integration hub or PaaS integration hub in the sky, who gets charged and on what basis? Is it per transaction? How does that work?

Sadat: That will depend. The platform itself will have a pretty simple pricing model. It’s going to be composed of couple of different dimensions. As you need to scale out your application, you can run more of these units of work. You'll be able to handle the volume and throughout that you need, but we are also going to be tracking events. So this is, in Mule terminology, equivalent to a transaction. Platform users will be able to buy those in select quantities and then be able to get charged for any overage that they have.

In terms of how they expose that to their customers, it will be totally up to them. They can choose to embed that into their application cost or they can charge it as a different service. One thing we've done with iON is make it very easy to consume and grow with the application provider.

It’s not going to be a huge upfront cost and a lot of unknowns in the different models of pricing for things like connectors, and connections, and those kind of things. We've made it very simple to consume the integration and also be able to charge it back to your customers, if you need to.

Gardner: It sounds like that’s very flexible. So, it could accommodate a variety of different models. I'm sure there is going to be almost as many business models as there are integration patterns, when it comes to cloud. This is all fairly uncharted territory.

Easy to consume

Sadat: Absolutely, and this is going to be one of our differentiators out there. We're trying to make it very easy to consume and be able to come into the iON community to use our services without having to worry about the huge cost of integration that currently you are going to be charged with the various venders out there.

Gardner: Looking at the future to try and understand why IaaS will become more important, I wonder about the rapid uptake in mobile, where the enterprise itself is almost redefined. People can use different devices to access different applications, regardless of the location, using mobile networks and data networks. How does that influence this? I'll ask this to Ross first. How does the mobile trend in particular affect the need for the neutral third-party integration capability?

Mason: Mobile consumers are consuming data, basically. The mobile application model has changed, because now you get data from the server and you render on the device itself. That’s pretty different from the way we’ve been building applications up till fairly recently.

What that means is that you need to have that data available as a service somewhere for those applications to pick it up. An iPaaS is a perfect way of doing that, because it becomes the focal point where it can bring data in, combine it in different ways, publish it, scrub it, and push it out to any type of consumer. It's not just mobile, but it’s also point-of-sale devices, the browser, and other applications consuming that data.

Mobile is one piece, because it must have an API to grab the data from, but it’s not the only piece. There are lots of other embedded devices in cars, medical equipment, and everything else.

The enterprise needs to be able to share its data with integration outside of its own firewall in order to create these applications.

Gardner: That’s an interesting point. The web of devices -- the Internet of sensors,. It seems as if it’s almost a requirement that all that data has to go to the cloud first, before it goes directly back to an enterprise. So having an integration point for and by the cloud would start to make more sense. Now, we’re not going to go down this path of caching and data lifecycle quite yet, but at least the integration capabilities of linking and managing the flow of the data becomes crucial.

Mason: Absolutely. If you think about that web, it needs to talk to a centralized location ,which is no one enterprise. The enterprise needs to be able to share its data with integration outside of its own firewall in order to create these applications.

Gardner: Now you’re going to be hosting this, I believe, on Amazon's Elastic Compute Cloud (EC2) at first, but you have plans to be more ecumenical in terms of where you host. Is that correct? How is that going to work?

Mason: Yes, we are. We started with Amazon EC2 because, it’s still the most ensured cloud platform doing real elastic compute, even though they had a recent outage a couple of weeks ago. People weren't architecting correctly versus Amazon. It wasn’t really Amazon’s fault. They have availability zones to help us manage data across different data centers, and everyone was using it.

If you look at Rackspace, they don’t have that capability in their cloud offering. They have it in their managed hosting. We’re interested in Rackspace, and we’re talking with them. They seem to be a bit behind the curve still on all requirements, but we’ll be reassessing again in the next three to six months, and we’ll probably be joining the OpenStack initiative as well. [Join the iON beta program.]

Gardner: Ali, back to you, how do you get started? If I've been listening to this podcast, reading about it on a blog, and I want to know more about one iPaaS generally and more specifically about iON, what would you recommend for resources?

Sadat: Today, you could definitely go through our website, start reading about iON itself, and get yourself acquainted with MuleSoft. Using the same website, you’ll be able to click on a single button and easily get your own tenants within iON and start working and playing with it. Over the months, we’ll release more documentation, more features, and by general availability, we should have our pricing model also out there.

It's definitely an easy way to get on it. Just go to the link. If you any questions, we’ll have contact information, where you can send us some direct feedback. There’s a huge community around Mule itself, and now we’re going to build one around iON that they can also leverage. There are about a 100,000 developers who already use Mule in one way or another or have knowledge about it. So, there’s a huge community. You can start leveraging by building your own applications on top of iON.

Gardner: I'm afraid we are about out of time. You’ve been listening to a sponsored BriefingsDirect podcast discussion on how enterprise application integration as a function is moving out of the enterprise and into the cloud.

I’d like to thank our guests. We've been here today with Ross Mason, the CTO and Founder of MuleSoft. Thanks so much, Ross.

Mason: Thanks, Dana.

Gardner: We’ve also been here with Ali Sadat, Vice President of iON at MuleSoft. Thank you, Ali.

Sadat: Thank you, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. Thanks for listening and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Join the iON beta program. Sponsor: MuleSoft.

Transcript of a sponsored podcast on MuleSoft's new iON cloud integration offering that provides new hosted integration abilities for enterprises, SaaS providers and system integrators. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• MuleSource Takes Aim at SOA Governance, Launches Subscription-Based ESB
• MuleSource Fires up MuleForge Collaboration Site: Apache Tuscany Team Announces 0.99 SCA Release
• Don't Use an ESB Unless You Absolutely, Positively Need One

iTKO's John Michelsen Explains Roles and Methods for SOA Validation Across Complex Integration Lifecycles

Transcript of BriefingsDirect podcast with iTKO's John Michelsen on SOA testing and virtualization market trends.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: iTKO.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion about integration, validation, and testing for services-oriented architecture (SOA) and middleware -- particularly for business process management and to extend business processes more efficiently.

We’re going to be looking at how integration nowadays is really across multiple dimensions. We are talking about integrating technology, about various formats, and for extending frameworks, vendors, application sets, and specific application suites. There are also now enterprise service buses (ESBs) that are creating multiple types of integration across services -- from different hosting locations and from different technologies.

Not only that, we’re also dealing with traditional enterprise application integration (EAI) issues and middleware. And, of course, there’s more talk about cloud computing and software as a service (SaaS).

The whole notion of integration in the enterprise has exploded in terms of complexity -- but that puts more onus and importance on validation, testing and understanding what’s actually going on within these integration activities.

To help us understand more about integration, middleware and SOA validation and testing, we’re joined by John Michelsen, chief architect and founder of iTKO. Welcome to the show, John.

John Michelsen: Thanks, Dana, good to be here.

Gardner: We’ve talked several times in the past about the integration in SOA, and what’s been going on. How do you look at integration now among business applications and middleware? Is it, in fact, more onerous and complex than ever, and how would you characterize the current state of the market?

Michelsen: It really is, and it’s for a number of reasons. Most of us can surmise that, as soon as we look at it. We tend not to turn anything off. Existing systems don’t go away, and yet we bring in additional [IT] systems and new things all the time. We’re changing technologies, because we're always looking for the faster, cheaper, more effective way. That's great, and yet today, IT becomes legacy faster than before. In fact, you and I had a conversation a few weeks ago about that.

So, it gets more complex over time. And yet, to get real value out of IT you’ve got to think not from the perspective of these systems, but from the business’s processes, as they need to function. We have to do what you can, considering unreasonable gyrations in the systems, in order to make it reflect the way the business operates.

So there is a real mismatch here, and in order for us to accomplish value for the business, we’ve got to solve for it.

Gardner: Of course, at the same time, IT organizations are under pressure to reduce their complexity, reduce their maintenance and total cost of ownership (TCO). They’re dealing with long-term activities such as datacenter consolidation and application modernization. What is it that brings testing and validation into this mixture, in terms of end-to-end visibility?

Michelsen: Let’s say three or four systems are already interoperating in some way, and now you’ve become a part of a larger organization. You’ve merged into a large organization, or you’ve taken into your organization something you've acquired. You add another three or four end points, and now you’ve got this explosion of additional permutations. The interactions are so many that without good testing and validation, there’s just almost no hope of getting real visibility, and predictability out of these systems.

When things do fail, which unfortunately happens, you’ll have an extremely long recovery time without this test and validation capability, because knowing that something broke somewhere is the best you can do.

Gardner: I suppose we’re also looking now more at the lifecycle of these applications based on what’s going on at design time. Folks who are using agile development principles and faster iterations of development are throwing services up fairly quickly -- and then changing them on a fairly regular basis. That also throws a monkey wrench into how that impacts the rest of the services that are being integrated.

Michelsen: That’s right, and we’re doing that on purpose. We like the fact that we’re changing systems more frequently. We’re not doing that because we want chaos. We’re doing it because it’s helping the businesses get to market faster, achieving regulatory compliance faster, and all of those good things. We like the fact that we’re changing, and that we have more tightly componentized the architecture. We’re not changing huge applications, but we’re just changing pieces of applications -- all good things.

Yet, if my application is dependent upon your application, Dana, and you change it out from under me, your lifecycle impacts mine, and we have a “testable event,” even though I’m not in a test mode at the moment. What are we going to do about this? We've got to rethink the way that we do services lifecycles, we've got to rethink the way we do integration and deployment.

Gardner: There is, of course, a very high penalty if you don’t do this properly. If you don’t have that visibility, you lose agility, and the business outcomes suffer.

Michelsen: That’s right. And too often, we see customers where they’re in this dynamic of these highly interconnected systems. That frequency of change and the amount of failure that’s occurring because of those changes are actually having such a negative effect that they’re artificially reducing their pace of change -- which is, of course, not the goal for the business -- in order to try to accomplish some level of stability.

This means that we’ve gone through all this effort to provide this highly adaptable and agile platform and we’re doing all this work to get agile and integrated, but we have to then undo the benefit in order to accomplish stability.

Gardner: One of the basic principles of SOA is that you get benefit as a result of the “whole being greater than the sum of the parts,” but many of the parts come from specific vendors and/or open-source projects. They have management capabilities and insights built into them specifically. Yet when you rise up a bit more holistically, that’s where the issue comes in of how to get visibility across multiple systems.

Explain to us how you got started on this journey, and where your background and history comes in terms of addressing that higher abstraction of visibility.

Michelsen: Right, that’s a good point, because if the world were as simple as we wanted it to be, we could have one vendor produce that system that is completely self-contained, self-managed, very visible or very "monitorable," if you will. That’s great, but that becomes one box of the dozens on the white board. The challenge is that not every box comes from that same vendor.

So we end up in this challenge where we’ve got to get that same kind of visibility and monitoring management across all of the boxes. Yet that’s not something that you just buy and that you get out of the box.

This is exactly what pushed me into this phase throughout the 1990s. I had a company prior to founding this one that built mission-critical applications for lots of large companies, including some airlines and financial service companies; logistics, even database engines, and things like this.

The great thing was that I was able to put my little team together to build really cool stuff and deploy it really fast into an organization. They loved it. The challenge was that I was doing this in a very disruptive way to the rest of the IT organization. I'd come, bring in this new capability, and integrate it into the rest of the applications.

Well, in doing so, I’m actually causing this very same dynamic that we’re talking about now -- where all of a sudden my new thing, my new technology, integrated into a bunch of legacy, is causing disruption across all kinds of systems. We just didn’t have a sense for how to do this.

So I had to learn how to do this, how to transform these organizations into integration-based thinking, and put in test-and-validation best practices. That’s what caused us to end up building what we now call LISA.

Gardner: Unfortunately, a lot of organizations, when they face that disruption, their first instinct is probably just to put up a wall and say, “Okay, let’s sequester or isolate this set of issues.” But that, of course, aborts this business process level of innovation and value.

Michelsen: Exactly, and here's a classic example. A number of the types of systems that we built in the late 1990s were the e-commerce applications that were customer facing. The companies said, “I just don’t want to hear that this system can’t talk to that system. I want a Web-based presence that’s brain-dead simple, and that does things the way a customer wants to be able to do them. You’re going to interconnect all those back ends in order to get that to work. … You just do it for me. And if you won’t do it, I’m going to go find a vendor outside that will.”

The challenge is, no matter how it ends up there, now we've got to reckon with it. Frankly, even though those are sometimes difficult conversations the business is having with IT, the business needs those things, because the company that does it gains market share and increases the scope of their growth cycle. That obviously is something that every IT organization wants, because that leads to a bigger budget and a better company, and the success that we want to see.

Gardner: Now, we've certainly established that there is a problem, and that’s been evident for some time. We’ve underscored the fact that we want to get visibility, and offer new elements into an integrated environment, to take advantage of the technologies that are coming online, but not be in disruptive mode, or we certainly want to reduce the risk.

So we know there’s a problem, we know what we want to do. Now, how do you approach this technically, when you’re dealing with so many different vendors, so many variables?

Michelsen: Well, I’m the founder of a product company, and yet you don’t start by going and buying some software, installing it, and thinking you’re done. Let’s start with thinking around a new set of best practices for what this needs to look like. We frequently leverage a framework we call "the 3Cs" in order to accomplish this -- Complete, Collaborative and Continuous.

In a nutshell, we’ve got to be able to touch, from the testing point of view, all these different technologies. We have to be able to create some collaboration across all these teams, and then we have to do continuous validation of these business processes over time, even when we are not in lifecycles.

It’s a very high, broad-stroked approach to our solutions, but essentially, drilling down to the detail with the customer, we can show them how these 3 Cs establish that predictable, highly efficient, lots-of-visibility way to do these kinds of applications.

Gardner: There must be secret sauce? There must be technology in addition to the vision and methodological approach?

Michelsen: Right. In order to get that testability across all these technologies and collaboration among all the teams and, of course, continuous validation takes tooling and technology. Of course, we provide that, which is great. I personally like it, just as, from a professional point of view, I like the fact that the way we message to the market is: "These are the ways you’ve got to go about doing it." Once you see that that is an appropriate approach for you -- then you become a great candidate for using our products.

But let’s talk about making sure that this is right for you. Then we’ll talk about our product being useful, because that really is the way the things should work. I can’t tell you how many times I’ve seen a customer who has said, “Well, we've run out and bought this ESB and now we’re trying to figure out how to use it.” I've said, “Whoa! You first should have figured out you needed it, and in what ways you would use it that would cause you to then buy it.”

It’s the other way around sometimes. That’s why we’ll start with the best practices, even though we’re not a large services firm. Then, we’ll come in with product, as we see the approach get defined.

Gardner: Are there any specific types of enterprise companies -- whether in a particular maturity around IT or suffering from certain ills or ailments -- that pique your interest to say, “Well, this is a perfect candidate for our solution and product set?” What are some of the indicators that a company is ready for this level of validation and testing?

Michelsen: There are a couple. First, the large-scale, top-down SOA initiatives clearly need this, because this is the perfect example of … interconnecting things, wrapping legacy systems in modernization, creating business-process modeling environments, increasing the pace of change, and distributed development across many different teams. SOA does all of those things for you, and certainly scratches every one of those itches that we’ve been talking about.

The other is when you go into a large integration initiative. There are a lot of partner solutions -- from companies like TIBCO, WebMethods, Oracle Fusion and SAP NetWeaver, and forgive me for not naming all of our friends. When you’re going down this kind of path, you’re going down a path to interconnect your systems in this same kind of ways. Call it service orientation or call it a large integration effort, either way, the outcome from a system’s point of view is the same.

Then, traditionally, by the time a business has been large for many years, they just have this enormous amount of technology. A classic example is a large financial institution that does fixed-asset trades. In order for one trade to place, it takes Web services and EJBs, from Java Swing-based application into CORBA, into messaging, into C code, into two different databases, and out the other end of a Web application.

All of that technology, integrated together, is what the business thinks of the app. Of course, that takes hundreds of people across many different teams – U.S., Europe and Asia -- from an IT point of view. But, all of that technology together is the app. So that’s your reality. That’s where we really can sit and where these best practices really get to work.

Gardner: So when you went to enter into these organizations where there’s a pretty powerful need, what is it that they’re getting in terms of value and impact? How do they use these tools? Then, we’ll try to ask a little bit about validation examples of what the outcomes have been.

Michelsen: What they’re doing is adopting these best practices on a team level so that each of these individual components is getting their own tests and validation. That helps them establish some visibility and predictability. It’s just good, old-fashioned automated test coverage at the component level.

As these components start to orchestrate with each other in order to accomplish this higher-level objective -- where this component becomes a part of a larger solution -- then there’s a validation aspect to it. The application that is causing this component-to-component orchestration has a validation challenge to make sure that things continue to work over time, even in the face of change.

As these components come together, there’s a validation layer that’s put in place. At iTKO, we even have a virtualization capability that allows you to do these kinds of things in a very agile way and without some of the constraints that you typically have. At the very end of the process, we are near the glass, if you will, of the user screen. Then you’ve got business-process level validation or testing across the whole thing. So think of it as, “Here’s a business process model that I’ve modeled in a business process modeling (BPM) tool of choice."

The complement of that are one or more tests or validations of that particular business process, where I invoke the process and verify my technical outcomes. So that if placing an order means to do this, this, and this in these systems, you do that with a BPM tool. To validate the business process function as expected, you’ll invoke that business process with our product LISA and then make sure all of those expected outcomes occurred.

For example, the customer database is going to have an update in it, the order management systems is going to be creating a new order. The account activity system -- which might be completely independent -- the inventory system, or the shipping system, all of these things are going to have to have their expected outcomes verified in order for us to know that this system works as expected.

Gardner: This really sounds like a metaview of the integration, paths, occurrences, and requirements. It almost sounds as if you’re moving to what we used to refer to, and still do, as application lifecycle management (ALM). But, it sounds like you’re really approaching this additionally as “integration lifecycle management.”

Michelsen: That’s a great point. In fact, we’ve heard people say, “Wow, it sounds a little bit like also business activity monitoring (BAM), where you’re basically chasing all these transactions through the production system and making sure they are doing their thing.” Certainly, it's a valid point. But let’s be really clear. We must be capable of doing this as a part of our development cycles.

We can’t build stuff, throw it over the wall into the production system to see if it works, and then have a BAM-type tool tell us -- once it gets into the statistics -- "By the way, they’re not actually catching orders. You’re not actually updating inventory or your account. Your customer accounts aren’t actually seeing an increase in their credit balance when orders are being placed."

That’s not when you find out it doesn’t work, right? And the challenge is that’s what we do today. We largely complete these applications. We go into some user-acceptance test mode, where we have a people see if they can find any problems with this enormous amount of software, millions of lines of code. We give them a few weeks to see if they can find any bugs, and then we go to production.

We really can’t let that happen any more. These apps are too big, their connections are too many and the numbers of possible testable items are way too great. And, of course, tomorrow we invalidate all the work we just did in that human labor, when something changes somewhere.

So this is why, as a part of lifecycles, we have to do this kind of activity. In doing so, we drive into value, we get something for having done our work.

Gardner: Clearly from my observations, there’s a struggle now under way in the market to find better ways of relating, finding the relationship and dependencies between the design time activities and the run time activities -- and then creating more of a virtual feedback set of loops that allow for this to continue without that handing off; or waiting for the red light/green light value. Tell me how you think LISA provides a bridge, or maybe a catalyst, to increased feedback values between design time and run time, particularly in an SOA environment.

Michelsen: Great question, and I’m glad that you’re seeing that as well, Dana, because we think that it's an indication that things are maturing. When we see our customers asking us, “How do I essentially do that second C of yours, collaboration? How do I better collaborate?”… we know that they’re finally seeing the pain between a siloed-based lifecycle, and testing and operations being a disjointed activity. Development and test don’t talk to each other, or with project management. And the business analysts don’t really even know each other.

We know that when we’re hearing questions around collaboration, people are becoming aware that they really needed to accomplish it. This is great. Some specifics of how our products can help is by first being a test capability that every one of the teams I just mentioned can use to do their own part of the testing effort. Developers have a test responsibility. Certainly, quality assurance (QA) has one. Operations even has one, from a functional monitoring point of view.

The business analysts have this whole "validate the business process" activity they need to accomplish. Everyone has their part to play, and if we can provide a tool that helps all of them do their part with the same product, there’s an enormous amount of efficiency. More important, there’s a much more highly automated back channel through this lifecycle.

If a business process is not functioning as expected, that failing test case is consumable all the way back to that individual developer who can see the context in which my component is being exercised. [And that comes from seeing] the input and output, seeing the expected outcome, and seeing the unexpected actual outcome. Then I get a really good awareness of what my component is supposed to do in the context of the business process.

When we have this common tooling across the board -- instead of one way of doing it for development, one way of doing it for QA, one way for the business analyst and for operations and everything -- we get much greater collaboration.

One other important point here is that we also have an opportunity to introduce this continuous validation framework, where once we start these integration labs, those components are being delivered into that integration lab, and then into pre-production, performance labs and production. We need an infrastructure for all of this continuous validation that properly notifies whoever should be notified when failures occur.

So our application has lots of good technology for being able to do this as well.

Gardner: Well, of course, the proof of the pudding is in the eating. Can you give us some examples of organizations that have employed these methods, and then some of these tools? Start to think in terms of the 3 Cs that you’ve outlined. What sorts of results or paybacks are there in terms of return on investment (ROI) and TCO? What validates this?

Michelsen: A great example of this would be Lenovo, the ThinkPad guys, where they went through a major next generation of all of their customers and partner-facing order management systems. This is www.lenovo.com, and a number of the systems behind it. They went with a new vendor to bring in a new application and interconnected into all the existing back-end and legacy systems. It's a classic example, as I said a few minutes ago, of when this kind of activity becomes important.

Lenovo realized from their past experiences that they wanted to get better at doing this kind of activity because they didn’t want what happened to them sometime in the past, where application failures underneath the screens would be causing customer experience to degrade -- but you couldn’t even tell at the website.

They were not capturing the order, even though an order number was showing up on the Web page, and things like this. They realized this challenge was too great for them, and they brought our solution in, in order to validate all these individual components and then validate at the user’s business-process level.

They wanted to validate what it means to configure ThinkPads, to price them, to do all of the bundling, to make sure that I can place orders, check orders, verify shipping, and do all these different things. That takes a pretty significant amount of visibility. Of course, our product has some capability to give you that visibility, because you’re going to need it.

So you have this kind of capability, and Lenovo was able to move away from, "I hope this thing continues to run." What was very possible in the past was that the customer update occurred, but the order placement didn’t -- a partial commit.

Instead of having that reality, they now have a reality on a literally continuous basis. From seven different places all over the world, we’re continuously validating the performance and functional integrity of the entire system -- both for the component level, and at what I call this orchestration level.

In doing so, they have a whole lot more confidence that the thing actually performs the way they expect it to.

Gardner: There’s no question, John, that the organizations that are advancing, that are deeply into integration issues, are looking for this business process management value, at the orchestration level.

They've moved an abstraction up in terms of the approaches, and the accomplishments of what their IT departments and systems can deliver. But, of course, any time we move up an abstraction technologically into the functions of IT, that requires the company go up a level in validation testing and quality.

It makes sense now that you’re going to see a growing market. Is there any sense that you can give us from your business as to how these things are growing now? Are people really getting to that level where they want to bring together a lifecycle approach?

Michelsen: Well, hopefully the Lenovo example means, yes. By the way, a company partner of ours named i2 -- they see this. We all know there’s an amazing amount of effort to do a large-scale implementations of either a packaged applications or large-scale custom applications. I think we’ve done this long enough to realize that this has to be part of the way to do it.

I’m seeing that more and more. As a consequence, we are able to provide value to many customers. It’s just been thrilling. We brought our product to market in early 2003 with a single customer or two. If our growth rate is an indication -- as an IT discipline – the market has finally realized that we have to get this right, which is terrific. If you think about it, the evangelist in all of us wants to get this right, or wants to do the right thing. I’m seeing it more and more, and that’s certainly terrific.

Gardner: Great. Well, we've been discussing the issues around integration, middleware, and SOA, as well as the need to abstract value up to the integrations and into the business processes. We have talked about how these elements relate to one another, and, of course, explain the need for greater visibility, validation and testing in these environments.

We’ve been talking about LISA and iTKO with John Michelsen, the chief architect and founder of iTKO. I appreciate your input, and we look forward to learning more about how this market evolves. It is an exciting time.

Michelsen: Thanks a lot, Dana. I appreciate the time.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: iTKO.

Transcript of BriefingsDirect podcast with iTKO's John Michelsen on validation and testing in application integrations. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.