Major trends around cloud, mobile and Software as a Service (SaaS) are dramatically changing the requirements and benefits of application integration.
In many respects, the emphasis now on building hybrid business processes from a variety of far-flung sources forces a rethinking of integration and middleware. Integration capabilities themselves often need to be services in order to support a growing universe of internal and external constituent business process component services.
And increasingly, integration needs to be ingrained in applications services, with the costs and complexity hidden. This means that more people can exploit and leverage integration, without being integration technology experts. It means that the applications providers are also the integration providers. It also means the stand-alone integration technology supplier business — and those that buy from it — are facing a new reality.
Here to explore the new era of Integration as a Service and what it means for the future is David Clarke, director of integration at SaaS ERP provider Workday. He is interviewed by Dana Gardner, principal analyst at Interarbor Solutions.
Listen to the podcast (36:28 minutes).
Here are some excerpts:
David Clarke: I remember when we originally became part of Workday several years ago, we were doing some sort of product planning and strategic thinking about how we were going to integrate the product lines and position them going forward. One of the things we had in our roadmap at the time was this idea of an [integration] appliance. So we said, “Look, we can envision the future, where all the integration is done in the cloud, but we frankly think it’s like a long way off. We think that it’s some years off.” …
We thought the world wasn’t going to be ready soon enough to put the integration technology and stack in the cloud as well.
Happily that turned out to have been incorrect. Over the course of the ensuing 12 months, it just became clearer and clearer to us that there was an appetite and a willingness in our customer and prospect base to use this technology in the cloud.
We never really went ahead with that appliance concept, it didn’t get productized. We never used it. We don’t need to use it. And now, as I have conversations with customers and with prospects, it just is not an issue.
In terms of it being any kind of philosophical or in principle difficulty or challenge, it has just gone away. It totally surprised me, because I expected it to happen, but thought it would take a lot longer to get to where it has got to already.
Dana Gardner: We see that a “consumerization” of IT is taking place, where the end-users want IT in the enterprise to work as well and in the same manner as it does for their personal lives. How does that shift the thinking of an enterprise architect?
Clarke: Superficially, enterprise architects are under a lot of pressure to present technologies in ways that are more familiar to customers from their personal lives. The most specific example of that is the embrace of mobile technologies. This isn’t a huge surprise. It’s been a pretty consistent pattern over a number of years that workforce mobility is a major influence on product requirements.
We’ve seen that very significant proportions of access to our system is via mobile devices. That informs our planning and our system architecture. We’re invested heavily in mobile technologies — iPad, Android, BlackBerry and other clients. In my experience, that’s something that’s new, with the customer enterprise architects. This is something they have to articulate, defend, and embrace.
Historically, they would have been more concerned with the core issues of scalability, reliability, and availability. Now, they’ve got more time to think about these things, because we as SaaS vendors have taken a lot of things that they used to do off of their plates.
Historically, a lot of time was spent by enterprise architects worrying about the scalability and reliability of the enterprise application deployments that they had, and now that’s gone away. They get a much higher service level agreement (SLA) than they ever managed to operate by themselves when they run their own systems.
So, while they have different and new things to think about because of the cloud and mobility, they also have more head space or latitude to do that, because we have taken some of the pain that they used to have away.
Gardner: I suppose that as implications pan out around these issues, there will be a shift in economics as well, whereby you would pay separately and perhaps on a capital and then operating basis for integration.
If integration by companies like Workday becomes part-and-parcel of the application services — and you pay for it on an operating basis only — how do traditional business models and economics around middleware and integration survive?
Clarke: I’d certainly hate to be out there trying to sell middleware offerings stand-alone right now, and clearly there have been visible consolidations in this space. I mentioned BEA earlier as being the standard bearer of the enterprise Java generation of middleware that’s been acquired by Oracle.
They are essentially part of the application stack, and I’m sure they still sell and license stand-alone middleware. Obviously, the Oracle solutions are all on-premise, so they’re still doing on-premise stuff at that level. But I would imagine that the economics of the BEA offering is folded very much into the economics of the Oracle application offering.
In the Web services generation of middleware and integration, which essentially came after the enterprise Java tier, and then before the SOA tier, there was a pretty rapid commoditization. So, this phenomenon was already starting to happen, even before the cloud economics were fully in play.
Then, there was essentially an increased dependence or relevance of open source technologies — Spring, JackBe, free stacks — that enabled integration to happen. That commoditization was already starting to happen.
So even before the advent of the cloud and the clear economic pressure that put on stand-alone integration, there was already a separate pressure that was originating from open source. Those two things together have, in my view, made it pretty difficult to sustain or to conceive a sustainable integration model.
A lot of the investment dollars that have gone into something like integration market are now going elsewhere in infrastructure. They’re going into storage. They’re going into availability. They’re going certainly to cloud platforms. It would need to be a brave venture capitalist now who would write a check to a company coming in with a bright idea for a new on-premise middleware stack. So that business is gone. …
Workday is an applications company. We’re an on-demand apps company and we build and serve human capital management (HCM), financials, and enterprise resource planning (ERP) application suites.
Cape Clear, which was my former company, was acquired by Workday about three years ago. We were partners, but as Workday’s business expanded significantly, they saw that providing a compelling and a differentiated integration experience in the context of this new cloud architecture was going to be something that was very important to them. So they acquired Cape Clear and we became part of the overall Workday organization.
Gardner: So there seem to be two fundamental things going on here. One, is taking integration to the on-demand or SaaS domain, but second, there is also this embedding integration functionality into the application.
How does someone like yourself who is crafting the middleware integration capabilities need to shift their thinking in order to go “to the cloud,” but also become part-and-parcel with the application?
Clarke: One of the perpetual holy grails of the middleware industry, when it was a stand-alone undertaking, was to find a way to express and expose middleware and integration concepts in a way that they could be used by mere mortals, by business analysts, by people who weren’t necessarily very deep technologists with deep technology expertise.
In my experience, the middleware industry never achieved that. So, they didn’t really ever find a metaphor or a use model that enabled less skilled, but nonetheless technically savvy, people to use their products.
As you observe in the applications game, you absolutely have to get there, because fundamentally what you’re doing here is you are enabling companies and individuals to solve business problems and application problems. The integration arises as a necessity of that or as a consequence of that. In and of itself, it isn’t useful.
The most specific thing that we’ve seen is how we build, manipulate, and use extremely sophisticated integration technology. We spend a lot of our time thinking about how to design that into the application, so that it can be experienced and consumed by users of the application who don’t know anything about XML, Java, web protocols, or anything like that. …
Business analysts can very easily and visually define what they are getting and putting it in terms of the business concepts and the business objects they understand. They can define very simple transformations, for example, going from a payroll input to a check, or going from a report of absences by departments to a payroll input.
They’re consuming and using integration technologies in a very natural way in the context of their day-to-day working in the web layer in these systems. They’re not programmers. They’re not developers. They’re not thinking about it that way.
It’s quite empowering for the teams that we have had working on this technology to see if it’s usable in that way by the business analysts here. It’s the closest I’ve seen people get to capturing this unicorn of enabling integration technology to be actually used by business people.
Gardner: Do you think in 10 years, or maybe 5, we won’t even be thinking about integration? It will really be a service, a cloud service, and perhaps it will evolve to be a community approach.
Clarke: I’ll make two main observations in this area.
First, there is an important difference between a general-purpose platform or integration platform and then a more specific one, which is centered around a particular application domain. Workday is about the latter.
We’re building a very powerful set of cloud technologies, including an integration cloud or an integration platform in the cloud, but it’s very focused on connecting essentially to and from Workday, and making that very easy from a variety of places and to a variety of places.
What we’re not trying to create is a general-purpose platform, an associated marketplace, in the way that maybe somebody like Salesforce.com is doing with AppExchange or Google with App Engine for app development. In a sense, our scope is narrower in that way, and that’s just how we’re choosing to prosecute the opportunity, because it’s harder to establish a very horizontal platform and it’s just difficult to do.
I referred earlier to the problem that middleware companies traditionally have of doing everything and nothing. When you have a purely horizontal platform that can offer any integration or any application, it’s difficult to see exactly which ones are going to be the ones that get it going.
The way we’re doing this is therefore more specific. We have a similar set of technologies and so on, but we’re really basing it very much around the use case that we see for Workday. It’s very grounded in benefits integrations, payroll integrations, financial integrations, payment integrations. And every one of our deployments has tens, dozens, hundreds of these integrations. We’re constantly building very significant volume, very significant usage, and very significant experience.
Loading ...
