Integration Infrastructure Approaches Must Adjust to New World of SaaS and Shared Services

Edited transcript of BriefingsDirect[TM] podcast with Cape Clear's Annrai O'Toole and analyst Phil Wainewright, recorded Sept. 13, 2007.

Listen to the podcast here. Sponsor: Cape Clear Software.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, a sponsored podcast discussion on integration infrastructure for modern software-as-a-service (SaaS), and on-demand applications providers.

The support and requirements for integration among these organizations, these hosters of many different types of services and applications, require a different integration approach. They're dealing with complexity, massive scale, and a cost structure that’s very lean. They have a business model that’s often based on ongoing subscriptions, and, therefore, they have a margin issue to maintain. They also have a wide variability of users and service-level agreements (SLA) to meet.

Reuse is becoming an important issue, as are patterns of automation. We're going to take a look at the market for integration in these modern service provider organizations. We’re going to look at the characteristics of the IT infrastructure support that meets these new requirements. And, we’re going to offer some solutions and approaches that satisfy these needs provided by Cape Clear Software.

Here to help us weed through this issue, we have Phil Wainewright. He's an independent consultant, director of Procullux Ventures, and also a fellow ZDNet blogger, primarily on this SaaS environment. We're also joined by Annrai O’Toole, CEO of Cape Clear Software. Welcome to you both.

Phil Wainewright: Thanks.

Annrai O'Toole: Great to be here.

Gardner: Phil, let’s start with you. It seems that SaaS and the new ecology of providers that are welling up around it require a different approach to integration, and this amounts to supporting the shared-services capability. Not only are these service providers going to require this capability, but also enterprises, as they become hosts themselves. Can you describe the different approaches to integration that we're now going to need in order for this business model to prosper?

Wainewright: Part of the issue that people face is that integration has crept up on them. In the early days of SaaS, it was very much about adopting point solutions. One of the reasons Salesforce.com has been so successful in the CRM space is that what Salesforce.com did with automation software didn’t have to affect the rest of the business, because they could just do it in isolation. IT wasn't really worried about it. So, they said, "Okay, we’ll just go to do that and it won’t affect the rest of the IT infrastructure" Now, we're getting more sophisticated about SaaS, because it's being taken on board in a whole range of areas within the enterprise, and people want to do integration.

There are two forms of integration coming to the fore. The first is where data needs to be exchanged with legacy applications within the enterprise. The second form of integration that we see -- not at the moment, but it’s increasingly going to be an issue -- is where people want to integrate between different services coming in from the cloud. It’s a topic that’s familiar when we talk about mashups, fairly simple integrations of services that are done at the browser level. In the enterprise space, people tend to talk about composite applications, and it seems to be more difficult when you are dealing with a range of data sources that have to be combined.

Gardner: It seems to me that now we are elevating to an integration of integration types. Does that make sense?

Wainewright: People have realized that if you're doing integration to each separate service that's out there, then you're creating the same point-to-point spaghetti that people were trying to get away from by moving to this new IT paradigm. People are starting to think that there's a better way of doing this. If there's a better way of delivering the software, then there ought to be a better way of integrating it together as well.

Therefore, they realize that if we share the integration, rather than building it from scratch each time, we can bring into the integration field some of the benefits that we see with the shared-services architecture or SaaS.

Gardner: How is this different from the way that application service providers (ASPs) of an earlier era went? It seems that they had a stack underneath each and every application. Now, we're hearing more about virtualization and the efficient use of infrastructure and platform elements. Help us compare and contrast the ASP model to where SaaS providers are headed now.

Wainewright: In the ASP model, you took existing conventional applications -- I like to call them unreconstructed applications -- and just hosted them in a datacenter. I've always said that it’s more than just a relocation exercise. You need to change the way the software is architected to take advantage of the fact that it's now in the Web and is in a shared-services environment.

In 1999 or 2000, one company came out with hosted webMethods integration as an offering. The problem was that it wasn't scalable. This is the problem with the ASP model. You were hosting a customized infrastructure for each individual customer.

Although there was some sharing of the infrastructure that you could do with virtualization -- and Oracle’s On-Demand is an example that’s done a lot of work with virtualization -- you still end up with every individual customer having an individual application tailored to his or her specific requirements. You get no economies of scale from doing that.

So, the new generation of SaaS providers, are really talking about a shared infrastructure, where the application is configured and tailored to the needs of individual customers. In a way, they’re segmented off from the way the infrastructure works underneath.

Gardner: Annrai, at Cape Clear Software, you’re targeting these providers and recognizing that they’re going to be moving to service-oriented architecture (SOA) relatively quickly, based on their requirements of their business and demands of complexity. How are you seeing these providers, as you are encountering them in the field, managing this discrepancy between commonality on the infrastructure, but high variability on the application and delivery to the end-users?

O'Toole: As Phil just said, taking unique integrations and hosting them isn’t very useful, because the person who is doing the work just ends up doing tons and tons of different customizations for every single customer. In the integration world, the solutions to these problems are reasonably well understood. The difficulty has always been about delivering them.

So, we’ve been working pretty closely with a number of prominent SaaS companies, most publicly Workday and some of our large enterprise customers, in figuring out how to solve integration problems for these on-demand and hosted providers.

What come out of it are two issues. First, Salesforce.com, really pioneered multi-tenanting as a concept to reduce the cost of hosting an application for lots of different users. We've got to do the same thing with integration, and we’ve been working with our customers and updating our enterprise service bus (ESB) to support multi-tenanting at the ESB level. You can have integration and have it segmented, so that it can be utilized by different customers at the same time.

In a large enterprise, this allows you have a shared-service model as well. You can build integrations in a datacenter and then segment them, so that different people can use them simultaneously.

There is also another aspect to the problem that needs to be solved. When you build an integration, you always end up having to customize it in some way for different customers. Customers will have different data formats. They’ll want to access it slightly differently. Some people will want to talk to it over SOAP. Some won't, and they’ll want to use something like REST. Or they might be going backwards and are only able to send it FTP drops, or something like that.

Multi-tenanting is one solution to the problem. The other is what we call multi-channel, which is the ability to have an integration, and make it available with different security policies, different transports, and different transformations going in and out.

A combination of multi-tenanting and multi-channeling allows you to build integrations once, make them accessible to different users, and make them accessible in different ways for each of those different customers. It gives you the scalability and reuse you need to make this model viable.

Gardner: Phil, it sounds as if we're really redefining integration and that we’re putting a higher abstraction, infrastructure-as-a-service, integration-as-a-service approach and model around it. Is this unprecedented, or is there anything in the past that we can look to, within even a closed environment, or a siloed environment, that relates to this. Or, are we into something entirely new when it comes to integration?

Wainewright: We're trying something that hasn’t really been tried with conviction in the past. In fairness, there’s still a lot of skepticism out there about whether we can really share integrations in the way that Annrai has just described. There’s a certain amount of agreement that we need to reuse integrations, but people haven’t necessarily brought into the whole shared services model.

People are particularly doubtful whether you can do all of the nuances of integration that you need to do in a purely declarative model, whereby you can simply have a description of the integrations that are required and have a need to work, and then that gets abstracted by the architecture into operation.

Annrai could probably elaborate on how it’s become possible to get the level of detail into this more loosely coupled architecture to enable people to share integrations, without giving up the individual requirements that they each have.

O'Toole: To pick up on that, I would be the first to share Phil’s skepticism and to offer that we may not have all the answers. However, one point worth bearing in mind here is that this problem is going to get solved, because the economic reality of it suggests that we must solve this. One, the payoff for getting it right is huge. Second, the whole model of SaaS won’t be successful, unless we skin the integration problem. We don’t want the world to be limited to just having Salesforce.com with its siloed application.

We want SaaS to be the generic solution for everybody. That’s the way the industry is going, and that can only happen by solving this problem. So, we’re having a good stab at it, and I'll just briefly address some of the things that I think enable us to do it now, as opposed to in the past.

First, there is a standardization that’s taken place. A set of standards has been created around SOA, giving us the interoperability platform that makes it possible in a way that was never possible before. Second is an acceptance of this shared-services, hosted model.

Years ago, people would have laughed at you and said, "I’m going to trust all my customer data to a provider in the cloud?" But, they’re doing it happily because of the economics of it. The whole trend towards trusting people with outsourced offerings means that the people will be more likely to trust integrations out there, because a lot of the technology to do this has been around for quite sometime.

Gardner: To Phil’s point, Annrai, how do you begin to accomplish this? Is this a matter of creating forms, templates, and models and then applying that to the ESB, where the ESB executes on that model and then they can be reused? If not, please explain? Then second, how much automation are we talking about? Are we going from 5 percent or 10 percent reuse, and then working up more -- or can we actually bite off more of a total integration as a pattern?

O'Toole: That’s a very good question. It's a movement to a more declarative style of integration. Certainly, what we’re doing is saying that a lot of the issues in integration are very common across different types of integration. For example, a lot of the issues currently in integration revolve around data transformation. Other issues revolve around the complexities of dealing with transports. For example, information can come in on email, but I need to be able to send it out to someone else on FTP.

The third set of issues is around handling errors in a meaningful way, so that when things go wrong, you’ve got a nice model of propagating errors back to people. The next set of things is security policies. Again, in integration you’re touching different things with different security models. With what we’ve done, you can visualize a whole bunch of pre-build security policies, transports, and transformations, and you’ve got this palette of things that you can then assemble together.

Someone still has to write the core business logic of the integration. That fact hasn’t changed. You still need that. Once I have the core business logic of the integration built, then all of the things around it I can put on in a visual and declarative manner around that integration, such as, "I want that integration to be accessed with this security policy, over this transport and with this transformation to get the data in and out of it."

I can take a single integration and create hundreds of different access routes into it, all with different security policies, different transformations, etc., and can segment them so that none of those things interferes with another during that multi-tenanted mode.

That technique allows people to reuse that integration for hundreds, if not thousands, of different customers and users in a totally segmented way. So, that’s at the core of what we are doing.

Gardner: What’s a ballpark figure for percentage of reuse, versus project-by-project or instance-by-instance customization?

O'Toole: There is no hard and fast data, so we rely on heuristics and rule of thumb. If we look at what our own consultants and systems engineers would do for customers, 70 or 80 percent of our time is spent around configuring different transports, and working at security. These are the things that are totally unglamorous, but really nasty gotchas in integration. For a long time, as people focused on making the core creation of the integration easier, they missed those other issues around this, and they’ve always been left to one side.

You might say, "It’s not hard to write a few lines of Java code to handle a different security policy." Well, it isn’t, but it is, if you've got to do a thousand different times for a thousand different people. It becomes tedious, and then you've got to manage all those things. So, it really is attacking some of the kind of nasty little gotchas on which people spend the vast majority of their time.

Gardner: Phil, you mentioned declarative, and Annrai mentioned graphical and visual approaches to this. Is it too farfetched to consider that non-programmers and non-technicians will be getting involved with this? Are we elevating an integration function to folks that are architects and/or business process analyst types?

Wainewright: A lot of the integration that people need to do is for business reason. Therefore, it should be in the hands of business people. For a long time, the answer back from the technologists has been, "Well, sorry guys, we can’t let you go there, because it’s too complicated." If a lot of the infrastructure can be automated and done in a way that, as Annrai says, takes care of the complexity, then it becomes easier to offer out certain aspects of the integration to business people, but I think the technology guys are still going to have to be there.

It’s a good idea for business people to be able to link up different business processes, or to say, "I want to aggregate this data with that data, so I can analyze it, as well as have a dashboard that tells me what’s actually going on in my business," but that has to operate within the constraints provided by the technology guys who actually make it all happen reliably.

I was listening to what Annrai was saying. He made a couple of very interesting statements, which are worth going back to, because a lot of people who approach integrations in terms of SaaS, are really talking about on-premises integration that links into the SaaS stuff in the cloud.

Annrai is talking about taking the integration off premises, putting it in the cloud as well, and then sharing a lot of the capability. In the SaaS market space, large amounts of integration reuse is happening at the moment. It's simply a matter of installing the same data connector in different customers, and perhaps reusing the expertise, but it’s not in any sense a shared service.

You're basically duplicating all of that infrastructure. If you can put the integration infrastructure in the cloud, then you start to get the benefits of shared services and you can get above the 50 percent level of sharing. But, if you’re going to do that, you’ve got to have the confidence that the architecture, can actually support all of that and isn’t going to fall over with certainly a thousand integrations happening all at once, and mustn’t conflict with each other. Cape Clear has actually managed to package that into a product that people can buy and install. I think that’s pretty impressive.

Gardner: Annrai, it still brings up these issues about integration on the hosting organization side, where they’re going to be integrating across resources, infrastructure components, application types, and data streams. They’re going to need to do that to manage the complexity and scale of their endeavor and their business, but is there a certain level of integration where there is more permeability between the enterprise, the on-premises, and what’s available through the cloud or the provider?

Are you talking about both, or either/or? Does one to have to come first, and how do you see this shaking out in terms of integration and these different directions?

O'Toole: The way I’d phrase this is that we’re seeing a little bit of both. We’re not wildly being drawn into one end of the spectrum or the other at this time. What we're seeing from companies like Workday is a requirement for them to more or less exclusively host integrations for all their customers, and all the various back ends that they talk to.

For example, they talk to things like ADP and benefits providers and so on, and they are hosting those integrations on their sites, because they don’t want to go to ADP -- well, they can’t go to ADP -- and make ADP to change and so on.

Gardner: And, ADP is a payroll service provider.

O'Toole: It's the largest payroll service provider in the world, I believe.

We’re seeing things like that, but in enterprises you’re seeing this big move to virtualization and shared services. They’re saying, "Why are we having development teams build integration in all these branch offices at all these locations around the world? It’s extremely wasteful. It's a lot of skill that we've got to push out, and there are a lot of things that go wrong with these. Can't we consolidate all of those into a centralized data center? We’ll host those integrations for those individual business units or those at departments, but we'll do it here. We’ve got all the expertise in one place."

Those guys are delighted, because at the individual local level they don’t maintain all the costs and all the complexity of dealing with all the issues. It’s hosted out in their internal cloud. We haven't seen enough data points on that, but this hosted integration model can work. We’ve got it working for pure entities in SaaS companies like Workday, and we’ve got it working for a number of large enterprises. There is enough evidence for us to believe that this is really going to be the way forward for everybody in the industry.

Gardner: At Cape Clear Software you're not just dealing with this as an abstraction. You have product ties. I understand that you’re going to be introducing a new iteration to the Cape Clear platform, Version 7.5, in late September. Can you tell us a little bit about how you’ve taken on the need in the market, what you foresee as possible and doable, and what you’re actually delivering?

O'Toole: The generic need we've seen in the market is what we like to call on-demand integration. Before the advent of all the things we’ve just talked about -- shared services and SaaS -- the only way people did integration was with big patches, what became known as enterprise application integration (EAI), and they were essentially hand customized, on-premises integrations that were different for every customer.

We think that the demand we’ve seen in the market is a move away from on-premises integration into on-demand integration, because, for the reasons we spoke of, people want to be able to integrate with SaaS. They want to run shared-services models in their own organizations.

We think there is a new movement from EAI into on-demand integration and we have been targeting several features in our ESB, specifically around this multi-tenanting and multi-channel stuff, and that’s all getting rolled up into a release called Cape Clear 7.5 that goes out on September 25. We're pretty pleased with this. All our guys worked hard, and I think it’s the best product we’ve ever done.

Gardner: Give us the short list of the new functionality?

O'Toole: Essentially I think it boils down into three major buckets. There’s a new graphical editor that we're calling the SOA Assembly Editor, and this is an Eclipse-based editor that allows you to graphically clip together the type of things I was describing: transports, security and so on. That’s a whole new editor that no one has ever seen in our product before, except the people who have been involved in our tech preview.

Gardner: Let me pause you there. Is this something that you foresee being useful and applicable to non-techies or at least folks that can cross the chasm between the business issues and the technologies? Who’s going to typical author with this tool?

O'Toole: It’s not an either/or. It’s certainly not something that the business users can use exclusively by themselves, but it's not a tool exclusively for developers. Our grand vision around this business/technical user thing is that you start to create sets of tools that can be shared across people. You can have high-level business folks describing business process and BPMN, and they can be imported into other sets of tools that the technologists use.

Then, there are some issues around how this thing is going to be accessed? Our business analysts do care about that, because they say, "These sets of customers must be able to access it this way." They might not know the details of the technology involved, but they do know how those people want to be able to use the service. So, as I say, it’s a little bit of both. Ultimately, people are really going to get value out of it, but, at the end of day, they’re going to be more on the technology side, because it’s really going to smooth up their job of automating what was an incredibly laborious process.

Gardner: Okay. That was bucket one.

O'Toole: The second bucket of the features is all around multi-tenanting. These are core additions into the ESB to allow segmentation of integrations, data, and reporting. You can set how you want to identify inbound customers, clients, or businesses and then segment use of those integrations on the reporting and management of those integrations, based on those identities.

The third bucket is all of the stuff we’ve seen customers need in terms of running and maintaining large enterprise class Business Process Execution Language (BPEL) deployments. Obviously a lot of our product has been built around the notion of BPEL, as a kind of core metaphor for how people build integrations and manage business possesses. So, we are totally committed to BPEL.

In working with our customers on that, in terms of very large-scale deployments, there's a whole set of issues around how people maintain and manage. So, as our products are evolving, they're evolving away from just being a kind of BPEL engine into a full BPEL management system, where we are giving people all the tools to monitor transactions, and repair transactions when they fail. This is largely for business reasons, because if something goes wrong in the business information, they've got to be able to rebuild that last business information and get that business transaction back on track.

Gardner: It occurred to me earlier, when you were talking, that we are really not only recasting integration, but we are moving beyond implementation of integration into management of integration, and then a step further beyond that into the management of change and integration. Does that sound fair?

O'Toole: One of the nice thing about BPEL is they are long running processes, but the challenge that presents is how do I manage the change in long running processes. I can’t go in and wipe the database and say, "I didn’t like that schema that I had underlying that business process." You need to be able to evolve that. So there's initial support for some of those concepts in this version as well.

Gardner: I like to bounce it off of Phil. Do you think that we're well into integration management and that the execution is important, but it’s the higher value to a shared services environment that's in this change-management capability?

Wainewright: Well, yes. This is part of a big movement that we are seeing in the way that we approach IT from a batch process of having a requirement, building to it, delivering it, and then bringing it into operation, to a much more iterative, ongoing, continuous process of delivering something that is constantly adjusting to the business needs of the organization.

So yes, IT is really catching up with reality. We’re now reaching the level of sophistication in IT infrastructure that actually allows us to manage change as a continuous succession of events, rather than having to wait for an upgrade to Windows or new version rolled out, or whatever it is, to actually move to the next stage in our business automation.

I think it should be welcomed and it’s inevitable. Perhaps it’s frustrating that it always seems to take so long to make it happen. The vision always seems to be several years ahead of the reality, but it's definitely the transformation that we are seeing.

Gardner: Great! I think we’ll leave it there. We’ve been discussing redefining integration as a reusable function for providers of services and hosted applications, and the notion of a shared services environment, which applies to both large enterprises as well as hosted.

We’ve also been discussing the marketplace and this movement towards management and agility in a SOA environment. We’ve talked about how Cape Clear Software is delivering Cape Clear 7.5 to help grease the skids towards this integration functionality. Phil Wainewright, an independent consultant, director of Procullux Ventures and ZDNet SaaS blogger, has joined us in this discussion. Thank you, Phil.

Wainewright: It’s been a pleasure.

Gardner: Also we have been joined by Annrai O'Toole, the CEO of Cape Clear Software. Thank you Annrai.

O'Toole: Thank you guys, it’s been very interesting.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect Podcast. Thanks for listening.

Listen to the podcast here. Sponsor: Cape Clear Software.

Transcript of BriefingsDirect Podcast on SaaS with Cape Clear's Annrai O'Toole and analyst Phil Wainewright. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

Apache Camel Addresses Need for Discrete Infrastructure for Services Mediation and Routing

Edited transcript of BriefingsDirect[tm/sm] podcast with Dana Gardner, recorded July 27, 2007.

Listen to the podcast here. Podcast sponsor: IONA Technologies.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion on a top level Apache Software Foundation project, known as Apache Camel.

It’s a way to help developers do better integration and mediation for routing in software-intense environments, and moving lots of objects and component services around, but also relying on rules and patterns to do so.

To help us understand more about Apache Camel, we’re joined today by James Strachan, technical director of engineering at IONA Technologies. Welcome, James.

James Strachan: Hi.

Gardner: Tell us a little bit about Apache Camel. It seems to be a subset of many other integration and infrastructure projects in the open-source community. Tell us a little bit about the history of how Apache Camel came to be.

Strachan: Earlier this year, Apache Camel grew organically from code and ideas from a bunch of other Apache projects, particularly Apache ActiveMQ and Apache ServiceMix. We found that people wanted to create and use patterns from the "Enterprise Integration Patterns" book in many different scenarios.

Some people wanted to use these patterns inside an Enterprise Service Bus (ESB), some people wanted to use these patterns inside a message broker, and other people wanted to use these patterns inside an application itself or to talk between messaging providers. Still other people wanted to use them inside a Web services framework or some other communication platform. So, rather than tie this routing code to a particular message broker or ESB, we tried to extract this code to be a standalone framework that can be used in any project.

Gardner: I assume that this is to simplify it and make it easier for developers? Is that right?

Strachan: Definitely. What we tried to do with Camel was give it the smallest footprint possible, so that it can be reused anywhere, whether in a servlet, in the Web services stack, inside a full ESB, or a messaging application.

Gardner: And, this is a plain old Java object (POJO), I believe, also built in Java. Is that correct?

Strachan: Absolutely.

Gardner: Tell us a bit about the team behind this and perhaps a little background for yourself?

Strachan: I'm an Apache committer. I’ve been in Apache for over five years now, and I am an Apache member for a few years too. I can’t remember how many. The Camel team is comprised mostly of people from the ActiveMQ team and also from ServiceMix and Apache CXF communities. Plus, a bunch of other people have joined since then.

Gardner: Tell us a little bit about your relationship with Apache. You’re involved with a number of activities there. Is that right?

Strachan: I've been around Apache for many years now, and I am involved in all kinds of different projects -- ActiveMQ, ServiceMix are the big ones -- but also on a bunch of others, like Jakarta Commons, Maven, and many others.

Gardner: There are a number of terms we’ve been bandying around. Let’s assume that not everyone listening is that deeply into technology. When we talk about mediation and patterns, let’s flesh some of these out. Mediation and routing, how is that different from what people might understand generally under enterprise integration?

Strachan: I definitely recommend people read Gregor Hohpe's book "Enterprise Integration Patterns." He offers a really good patterns catalog of how people should do mediation and integration. Rather like the original Gang of Four "Design Patterns" book, which describes low-level programming things, Gregor’s book describes very well how enterprise integration patterns (EIPs) can work and gives us a language for describing them.

Aggregate, re-sequencer, message filter, and message translator generally describe patterns people commonly want to do within an integration solution. One of the simplest patterns is "content-based router," where you want to route messages around your network, based on the content. It might be, for example, that for gold-level customers you want to use the big, shiny, fast machines in your data center, but for bronze-level customers you use the crappy, old, worn Linux box in the corner of the basement.

Gardner: You mentioned earlier ESB, enterprise service bus. Explain to me how this works in terms of other ESBs. This is ESB-agnostic. Is it something that people will use to complement ESBs or perhaps replace them in some instances? What’s the relationship between Camel and an ESB?

Strachan: That’s a good question. In some ways the term "ESB" is a little bit like the terms "object" and "component," in that ESB is used for many different things. It has kind of lost a lot of its meaning. We typically don’t tend to think of Camel as being an ESB. We think of it as a rules-based routing and mediation framework that you may deploy inside an ESB.

We work very closely with the ServiceMix community at Apache which has created a complete Java Business Integration (JBI)-compliant container of JBI components. Camel can be deployed within the ServiceMix ESB among JBI components, but some people don’t use JBI and they may just use Java Message Service (JMS) or they may just use Web services or they may just be JAX-WS clients or whatever. So, we try to make Camel agnostic to technologies. You can use it within patterns like Spring, or JBI or OSGi, or you can use it within any application.

Gardner: I’ve also heard you refer to this as a domain-specific language project. What do you mean by that?

Strachan: Programming languages are often very general purpose. They can be used to solve any kind of problem. Domain-specific languages have become popular lately, and they’re basically tied to typically a business domain, such as investment banking, telco, or whatever. In Camel’s case, we’ve made a domain-specific language that focuses purely on the EIPs.

The language itself describes how to do the various things you typically do in the patterns, such as wire tap, aggregator, content-based router. These are first-class concepts within the language itself. We’ve implemented this domain-specific language in both Java and XML, so you can stick to a Java IDE if you prefer, or, if you’d rather, you can use XML to describe this language and deploy it inside your Spring XML.

Gardner: So, we’ve had vertical industry domain-specific languages. This seems to be more of a functionally domain-specific language. Is that a correct statement?

Strachan: Yes. The EIP is the functional domain, or rather the business domain.

Gardner: And, this is all about getting more granularity, more specialization for integration that nonetheless can play across a more general or horizontal capability. Is that fair?

Strachan: Definitely. Across all of IT we’re seeing increased specialization in many different areas, where the specialization helps us solve a problem at a higher level. If you spend your life solving problems, with, say, JavaBeans everywhere, you have a lot of code to comprehend and understand, and things can get quite complicated. The higher level of abstraction helps us solve problems easily.

Gardner: And, because we’re doing it an open-source environment where there’s a community involved, the more likelihood that this will be applied across many other different types of platforms and technology?

Strachan: Exactly. The other benefit of being with Apache is that we have a very liberal license, so this can be embedded in any commercial product very easily. We've seen lots of partners using this technology.

Gardner: Right. A few moments ago, we talked about ESBs. There has been, as you say, some divergence in the term ESB. There are also a number of products and approaches in the field. How about for Camel as a rules-based routing and mediation engine? Are there many others of those? Who else is trying to solve the same problem, or can we safely say that the Camel is unique?

Strachan: It depends on how wide you cast that net. Camel is unique in a number of ways. What we’re doing with Camel is defining a high-level language to describe EIPs, which I don’t think anybody else has done before. The other thing that’s unique is that this language very closely maps to components that work inside Spring 2.

We use a lot Spring 2 features, such as declarative transactions, inversion of control configuration, and various utility classes for working, with such things as JMS and JDBC and Java Persistence API (JPA). What we’re doing is raising the abstraction level to make things very simple, reducing the amount of XML we have to write, but still exposing the wire-level access if you need to do the really hard stuff and roll your sleeves up and get down and dirty.

Gardner: Let’s move this a bit closer to the business side. I wonder what sort of a problem set it is that we’re facing here. Is this a new approach to older problems or a new approach to newer problems? What's the problem solution fit here in the market?

Strachan: The problem we’re trying to address is the routing and mediation problem, which lots of people have. They're taking data from various components and sources -- whether it’s files, databases, message queues, Web services, instant messaging, or other data systems, integrating them together, formatting them, and connecting them to the systems. From a higher level perspective, this could be for legacy integration of systems, for smart routing, performance, monitoring, or testing or monitoring transaction flows.

In general, integration is a very old problem. As soon as we relate to couple of different computer programs, we already have an integration problem and that just grows with time. The thing that’s new is the approach that’s used. We're increasing the abstraction level by making it very easy to work at the EIP layer.

People don’t have to worry about the low-level details of how to use JMS, how to use JBI, or how to wire together the Spring components correctly, and so forth. We're giving people a nice, simple, high-level abstraction, but yet we are exposing all the power of frameworks like Spring and still exposing the low-level details if you need them.

Gardner: Over the last couple of years, because of the popularity and use of Web services, the business side wants to expand the interactions across not only applications, but organizations, and perhaps in a supply chain setting. It sounds like this helps solve the issue of inclusiveness across domains and businesses, and then adds the opportunity to start moving toward event-driven computing. Does that sound fair?

Strachan: Definitely. And, as soon as people start moving toward distributed systems, service oriented architecture (SOA), event-driven architectures, and all these other terms, the one thing that keeps happening is that people need a pervasive technology they can apply anywhere. Camel is lightweight, and can be used anywhere, in a smart end point, in an ESB, or a message broker.

ActiveMQ5 is coming out in [August, 2007]. That's going to have EIPs integrated in the client and the broker by Camel. ServiceMix has integration with Camel and CXF, as a project at Apache, which implements the JAX-WS standard that’s got EIP integration via Camel. We’re seeing a large number of projects that have EIP integration via Camel. It’s already proven in the open-source world that it’s very easy to reuse this routing and mediation technology anywhere. Hopefully, we'll see this just grow and grow.

Gardner: It’s curious to me. It seems like yesterday, but I suppose we're going on 10 years now, that a lot of these functions -- singular, distributed, perhaps even proprietary -- were combined into what became conceptually the application server. Now, it seems like we’re decoupling things. That one large application server approach might not be the best fit, as we get more types of routing and messaging in these integration patterns.

Can you expand on that? What's been the larger trend, in terms of architecture?

Strachan: There’s been a definite move away from J2EE apps, the big application servers, and people are looking for small, lightweight solutions that solve only the problem they have and not problems they don’t have. A lot of software vendors suffered from the kitchen-sink syndrome, where they tried to have one of everything in a big box. That just led to lots of complexity and redundancy.

People really want small and simple-to-use components that solve the problems they have. I've seen that throughout all of our customers. People ask for very specific solutions. They don’t say, "Give me a SOA." They say, "I need a message router," "I need a message bus," "I need an ESB," or "I need a services framework." Often, people have very specific requirements and are very much cherry-picking the best-of-breed components from the open-source tool set.

Gardner: So, it’s the Swiss Army Knife approach.

Strachan: Exactly.

Gardner: That works well for developers. I wonder over time how Camel might find itself being used in terms of operators, specifiers, and architects on the operational side of things. Do you see this moving in that direction? What’s the short-, medium-, and long-term implementation roadmap that you foresee for Camel?

Strachan: Today it's very much developer-focused. The current Camel is aimed at developers who are savvy with Java, XML, or Spring. What we want then is to gradually raise the abstraction level, so the architects and operational people can monitor services, monitor business processes, perform operational behavior, plus be able to design and deploy EIPs in a simple way.

For example, building tools and making it easier to design EIPs, as well as to choose a monitoring tool, are important.

Gardner: How would the specifying roadmap shake out? Do you think this is something that would get bundled in or integrated? How would this be something easily rationalized in production environments for those people that are going to be looking at large data center implementations?

Is this something that would be part of another grouping of products, other Apache kind of projects? How would this combine to make a whole larger than the sum of the parts?

Strachan: What we’ve seen over the last few years is a huge diversity in how people actually deploy products. Maybe five years ago, people assumed the world was J2EE app servers and everything would deploy in a J2EE deployment unit. These days, we see people make their own deployment units. We're seeing a lot of people move towards OSGi bundles. So we see a huge difference in the ways in which people deploy software now.

One of the reasons we’ve taken extreme steps to split Camel up and make it a very simple and easy to use bundle is that we know that there is a huge range of deployment platforms. Some people want to use Camel within their own smart end points. Some people want to host it inside the message broker, in the ESB and so forth. So, we see it going into production in many guises and many different forms.

Gardner: In IONA’s case, how would this be used in the context of its offering? I'm assuming that, as with other IONA offerings, it will be the commercial open-source support approach.

Strachan: Yes. Camel’s pretty much the core foundation for smart routing and mediation within an entire product suite. We have a product called FUSE, an open-source SOA backplane that provides a services framework, a message broker, an ESB, and a mediation and routing engine. The mediation and routing engine is based very heavily on Apache Camel, and we're using Apache Camel throughout other projects as well.

Gardner: Are there forums or community sites? How are some of the dialog and collaboration around this taking place?

Strachan: If you go to http://open.iona.com, there is a whole raft of documentation online forums, a wiki, and so forth.

Gardner: I know this is fairly early, but maybe this will be a good time to lay out some of the milestones. Are we expecting some significant developments and/or visions within the overall Camel project? Can you give us a bit of a timeline?

Strachan: It’s still fairly early for the timeline, but the next version of Camel 1.2 should be out fairly soon, and it's going to offer improved monitoring and management tools and particularly improved visualization and tooling.

Toward the end of the year, we’re hoping to improve various other capabilities we’ve added recently for extract, transform and load (ETL). It’s a way of loading data into systems and load testing systems with data. Plus, another area we’ve been developing what we call business activity monitoring (BAM), which helps monitor transaction flows across different systems.

For example, you might want to track that a purchase order in a system maps through to an invoice that comes out of another system. You might be processing a 100,000 of those a day, but there is one that goes along every few hours, and you want to find out which one that is within a small time window. That’s another area where we are extending the reach of Camel to do very complex and powerful monitoring.

Gardner: That's interesting, because this provides the actual routing mechanisms that provide a window into what's good, and also what's not good about how those processes are being built and used.

Strachan: Definitely. We’ve found that as soon as you have this very flexible and reusable integration patterns, it’s very easy to build on that, to build higher level abstractions, whether this is powerful testing frameworks, stimulation frameworks, ETL or BAM. We’re seeing the levels of abstraction increase to remove layers and layers of complexity.

Gardner: Is this something that could be applied to the ongoing -- and I imagine increasingly arduous -- task of dealing with semantic issues in terms of data across applications? That is to say, helping to define a mediation and a rules-based approach, such as this help in how companies can deal with that diversity and then come up with more common approaches to data and content that can then be injected into a business process.

Strachan: Definitely. This is a very large and complex topic. There are just a few bullet points on the top, and we’ve already got a range of transformation and validation capabilities in Camel, but we’re looking to improve this in various ways.

IONA recently acquired a company, called C24, which has a whole range of technologies for doing semantic mapping and transformation of different data formats. For example, they've got models for pretty much all the standard financial formats, like SWIFT, FpML, FIX, and all these other things. And, they've got other models for telcos. We’re looking to open source some of that and integrate that into Camel for doing lots of data service type integration.

Another area that’s kind of similar, but slightly different, is in the business activity monitoring ground, where you sometimes want to just check the effect of systems. So, it’s a little bit like I am doing real time reconciliation systems, and you’re doing all this transformation between systems, but you want to make sure of the end results, like that final purchase order or that final settlement instruction does contain the values that you expect. For example, we might want to check that the purchase order amount matches the invoice amount, or whatever.

Gardner: As you say, it’s early in the evaluation of Camel, but are there instances where we can see how it's being used or how developers have identified this as a productivity benefit, or are there metrics of productivity? How is it helping in terms of getting a better job done?

Strachan: We’ve got a bunch of different customers using Camel in different ways. We seem to have a few different kinds of customers finding Camel for the first time. Some come from an ActiveMQ background. They're doing lots of messaging, and they want something a bit more powerful to do more complex routing within the message broker itself.

Some come from the ServiceMix background. They are very ESB focused. They love JBI. They like the idea of standards-based ESB. They’ve got a bunch of standards-based integration components, but they’re working together, and they just want a slightly more powerful routing engine to work with.

Some of our customers have been using Mule. They found Camel a little bit easier, and they’ve migrated across. Finally, there are people who’ve just found Camel, that's all they know, and they just dive straight into it.

One of the things we’re seeing from customers is that using APIs, like JMS and JBI in particular, and to a lesser extent JAX-WS, could often become complicated, but people find that wiring things together with Camel is almost trivial. People get things going really quickly without having to read pages and pages of specifications for things like JMS or JBI, or dealing with the lower-level details of Spring.

We see quite a rapid productivity gain, and it means that people can then use lots of different technologies, whether it’s JMS or JBI without having to spend a long time figuring out things in the Spring manuals.

Gardner: Among these early users are there any vertical industries popping out, where it seems to be making sense first, perhaps financial services?

Strachan: Yes, finance and telcos definitely are big markets, but we’re also fairly strong in the e-tailers. Those areas will be our big three markets right now.

Gardner: Can you explain the business problems that they're using it for?

Strachan: Pretty much all of our customers have similar kinds of problems. They have lots of silos in applications. There are lots of messages being exchanged between systems, whether those are messages via flat files, email, JMS, legacy message brokers, or web services. They generally want to do one or more of the patterns, whether counter-based routing, or message transformations. We see more people starting to investigate a business activity monitoring feature of Camel, and that’s something I'm quite excited about.

Lots of companies, once they realize they can tie together messages to business processes, start running rules off the back of that. That has been extremely useful for people. One thing about SOA that’s quite difficult is knowing what’s really happening in your system.

Today, people have often done such things as monitor message queues or use a JMX-based management console to look at numbers and statistics. Being able to tie together all the different things flowing through your SOA to actual business processes is extremely useful and valuable for customers.

Gardner: There seems to be some murkiness in how feedback will occur, when you have events-driven architectures, and how to create common approaches to runtime and design time with this BAM emphasis that we are seeing associated with Camel. Do you expect that Camel could fill some of that role in terms of a balancing act between what takes place in operations and what needs to be brought into a service level agreement of some kind?

Strachan: Definitely. I have worked with quite a few customers on various BAM-related problems, and it does seem that BAM solves those problems. It’s quite hard to have an off-the-shelf tool to do everything people need. Almost as soon as people start doing any kind of BAM, they find that they want to put their own code in there. You might be in financing, and maybe there is a trade in U.S. dollars. You want to take that trade to the settlement instruction, but you want to do a foreign exchange conversion in there.

Almost as soon as you start doing the “hello world,” BAM-type scenarios, you tend to want to roll your sleeves up and actually do some coding of some kind, to do custom reconciliation, custom calculations, custom visualizations. BAM is very much a framework-driven thing, rather then a black-box tool. Certainly, we see people take on the Camel framework itself and then expand and extend it to do more powerful things.

Gardner: I suppose that’s part and parcel of open source, community-driven projects. They tend to be pushed out in a variety of directions. Do you have any sense of what other functional parts or functional capabilities we might see brought into Camel?

Strachan: A big area is visualization. It’s incredibly hard for people to follow what’s happening in general. Once you can create a wire tap into any system, it’s very easy to glean information from it and find out what’s happening, what its throughput is, what it is actually doing. You can then do things like trace messages around the system, correlate messages to business processes, reverse engineer whole business flows from legacy systems.

That whole area is a visualization and tooling problem. I see that as a very large area of research with the Camel project. We hope to be to be rolling out in Q4 the first batch of visualization tools. It's very much a work in progress in the next few years to get even better, more powerful operational controls and visualization engines.

Gardner: By getting more visual, it seems like we can bring more people into the process, and that maybe elevates us beyond BAM into business intelligence. Is that fair?

Strachan: Definitely. Absolutely.

Gardner: I think a lot of business people would like to get more of a real-time sense of what’s going on among these processes to provide more confidence, as they move processes from manual and older message into this new SOA approach.

Strachan: Definitely. Plus people want early warning notice of any kind of failure. One of the nice things is that you can be alerted that maybe something's going on that hasn't been found yet. Maybe it's running a bit slow today, or maybe it’s just a heavy trading day. But, it might not be, and maybe something is really wrong. So, rather than waiting for some extreme failure that results in a fine or extra interest being paid, you can respond more rapidly than that.

Gardner: Let’s just circle back quickly. Developers seem to be the core short- to medium-term audience for this. What sort of developers specifically should be more aware of what Camel’s capable of?

Strachan: I’d say anyone who’s doing any kind of SOA or distributed programming. They should at least take a good look. Definitely, anybody who ever read the EIP book. If you read that book, you’d probably just see Camel and you’ll immediately just figure out exactly what it’s doing. It’s very simple.

If you're doing Web services, you might need mediation. If you're doing any kind of messaging using multiple databases, if you have any kind of integration problems, and certainly if you’re using any kind of ESB, then definitely take Camel for a ride.

Gardner: Now, when we look toward getting more information on this, we have the resources at Apache Foundation, and also, as you mentioned, http://open.iona.com?

Strachan: Yes.

Gardner: Any other resources? You mentioned the book. Are there any other resources on this that people should be aware of?

Strachan: Those are the big three. There’s also my blog: http://macstrac.blogspot.com/.

Gardner: Very good. Well, we’ve been discussing a budding Apache Foundation project known as Apache Camel. It’s a rules-based routing and mediation engine for POJO-based implementation of EIPs.

Discussing this with us today, we had James Strachan, technical director of engineering at IONA Technologies.

I'm your host and moderator Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and learning more about Apache Camel.

Listen to the podcast here. Podcast sponsor: IONA Technologies.

Transcript of Dana Gardner’s BriefingsDirect podcast on Apache Camel. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

Transcript of BriefingsDirect Podcast on the Emergence of 'Integration-as-a-Service' for SOA

Edited transcript of BriefingsDirect[tm/sm] podcast with Dana Gardner, recorded June 20, 2007.

Listen to the podcast here. Podcast sponsor: Cape Clear Software.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to a sponsored BriefingsDirect podcast. Today’s discussion is about an intriguing concept, that of hosted Services Oriented Architecture (SOA), looking at integration as functionality and process that can be accessed on demand, moved off of your enterprise infrastructure, and onto someone else’s. This, I suppose, looks at services and compositing-as-a-service as well.

Here to explain these concepts and how they’re being used practically today -- and the implications for the future -- is Annrai O'Toole, CEO of Cape Clear Software. Welcome back to the show, Annrai.

Annrai O'Toole: Thanks, Dana.

Gardner: The notions of integration and hosting have been bounced around for a while. I recall a company named Grand Central that got quite a bit of funding and had a 1,001 different ways of mixing together services, components, and objects. Maybe it was a little ahead of its time. Why you think that the time is right for something like hosted integration?

O'Toole: You’re right. It is a somewhat back-to-the-future position, and clearly a lot of the ideas we’re talking about are things that Grand Central spoke about -- it must be six years ago. A couple of factors are driving this. First, it’s the whole technology maturity thing. Six or seven years ago, the standards around Web services were in their infancy, and people didn’t have a lot of experience with them. Because they were young, unproven, untested, and lacking in key bits of functionality, people didn’t really want to go there. Technology is one element of it, but there are a few more important elements driving it as well.

One is a secular trend toward simplicity and flexibility. At some levels, this has been driven by teams through virtualization. Storage and processing power are being very quickly virtualized. Applications are being virtualized, with software-as-a-service on demand. There is a long-term shift by customers, who are saying, “We don’t want to own complex infrastructure anymore. We’ve been there, and done that. We want something else.”

Gardner: So, you’re saying that enterprises have gotten a whiff of the notion that they can have complexity removed? They can have consolidation and cost reduction at the same time, and they kind of like that?

O'Toole: They do like that, and they’re willing to pay for it. They’re paying on a subscription basis, but we see many people not wanting to own, or get involved in, large initiatives, rolling out complexity. Before I got on this call, I did a quick refresh of some of the Websites. If you look at the SOA offerings from Oracle, IBM and BEA, they range from a minimum of 13 products to the top of the range, with IBM at 31 products. These are 31 simple products with easy to remember names like “IBM Tivoli Composite Application Manager for WebSphere.” People don’t want to own this stuff anymore.

I’ll give you another data point on the complexity that’s involved here. Recently, we looked at some RFPs. We had an RFP come in – and this isn’t all that unusual – from someone looking to do a big SOA initiative. It was – and I’m not joking -- a 111-page RFP.

Gardner: RFP is a request for proposal. That’s how companies go out and say, “We would like to start a bidding process around that acquisition of a large IT capability of some kind.”

O'Toole: Customers look at the choices available to them, and say, “Do we want to do all this big SOA integration on our own by buying these complex things, or are we prepared to look at alternatives? And, do those alternatives have any reality?” They do, and many companies are shying away from these big, complex initiatives.

Gardner: We’re certainly seeing that. Companies readily grok the notion that SOA is designed to make heterogeneity an asset rather than a liability. If that’s the case, then they certainly seem less interested in going to a single large stack, single portfolio, or even platform approach to that. So, that’s clearly in the market. On the other hand, they want this stuff to work, and they don’t want to be caught with their pants down in six months or a year, due to reliability or performance issues. Perhaps you could help take us to the notion of hosted integration from the perspective of “Does it work?”

O'Toole: This is a critical point. You can sit in a room with a bunch of executives, both from the business and IT segments and, say, “Hosted integration is a good idea,” and they’ll know that. We’ve got some proof points around it. Most notably, one of our marquee customers in the software-as-a-service base is Workday. The PeopleSoft founders got together to rebuild an ERP application, but this time on a hosted basis.

Gardner: Dave Duffield was the founder. Right?

O'Toole: Yes. Today they’re doing hosted integration, and, if you go to the Workday site, you can navigate into what they call the Web services networks. You can see the type of services that they are hosting on behalf of their customers. The whole idea is that they’re taking the integration burden off the customers, so that the customers can integrate their applications with Workday, without having to do any work on the customer end of the connection.

This is a huge portion of the unfolding software-as-a-service story. All application trends, be they 10 years ago when it was big ERP or now with software-as-a-service, have to address the integration problem, because none of these large applications live in isolation.

Workday has taken a novel approach to that around a hosted integration solution, and that works. They have large customers today. They’re handling integrations for their customers and hosting integration into things like ADP. Workday handles the integration between the customer’s data and ADP, which is actually doing the payroll and running checks, making sure that check runs get done at the end of the month and that people get paid. So, that’s a pretty important integration service to be hosting, because if it doesn’t work, and if it’s not reliable, then people don’t get paid.

Gardner: That tends to be top-of-mind for many people.

O'Toole: These aren’t trivial integrations. So, hosting is a big thing.

Gardner: If I could just pause you for a moment. As I understand it, Workday wanted to create some on-demand business applications, but in order for them to create a subscription business model around business applications, they had to conquer this integration issue in order for their application to be accepted. Is that correct?

O'Toole: That’s correct. If you think about it, the work they’re doing is all around handling human resources, the human resources (HR) application. That’s somewhat different from the type of application that SalesForce offers. SalesForce is a stand-alone box. You can use Salesforce.com to do customer relationship management, and it’s not essential that it integrate with other aspects of your business.

HR is very different. It must be integrated with your existing payroll systems, and must be integrated with third parties, such as people who manage benefits or people like ADP, which actually does payroll processing. So, it’s not possible to roll out an HR solution with Workday, unless you’ve got the integration problem solved.

Gardner: Sure, companies use an ecology of providers to help them support their employees in a variety of ways, whether it’s benefits, insurance, or future earnings and stock trading, and a whole bevy of different services.

O'Toole: Exactly. It’s a very complex ecosystem, and integration is one of the things that’s a sine qua non. They don’t have a business, unless they have the integration problem licked. So, it’s very different from CRM. And, as Salesforce.com expands its footprint, it too is running into this integration problem. They have now realized that they’ve got to offer better integration solutions for their customers as well, and they are working their way through those issues too.

As we wind the clock forward, we’re going to see more customers wanting to use on-demand style applications, and wanting integration to be solved in an on-demand way. They don’t want to build all these integrations again. You can also take this one step further. We’ve seen a lot of our enterprise customers, as they think about rolling out big SOA initiatives, are saying, “Maybe, we should really model ourselves as a mini software-as-a-service to our own internal organizations.”

Large enterprise IT departments are essentially rolling out hosted solutions and integrations. We’ve got many examples. We cite JP Morgan pretty frequently as a large enterprise customer that is hosting integrations centrally inside JP Morgan, so that it’s easy for different divisions and some external customers to access application functionality. The point we would make about our vision of how this hosted integration goes forward is that it’s not just for software-as-a-service companies like Workday or SalesForce. This is actually a model that’s good for internal IT as well.

Gardner: So, if we are an internal IT department moving towards SOA, and we access various services, assets and resources -- some internal, some external, some to partnerships -- we’re going to find ourselves in the role of doing integrations as a service anyway. That’s their point. If that’s going to be the case, then why not look for various other organizations that can follow that same beat of logic, and therefore you’ll have a federation approach toward integration as a service.

O'Toole: Another way to think about it is that if we are going to virtualize storage and processing power, we want to virtualize integration. It’s not something that is being rebuilt again and again and again by different companies or different departments within different companies. Let’s really start to move to a hosted model for us, and, as you say, these can be federated in a very coherent way. What’s new now is that the underlying technologies and standards can actually support that model. So, while this model might have been a pipe dream five or six years ago, today it’s reality, and the technologies and capabilities are there to do it.

Gardner: It seems to me that you are offering these enterprises the opportunity to get out of being in the middleware business, or to at least reduce the role that middleware plays for them as a provider and a host themselves. They can offload more of the function that middleware plays.

O'Toole: One of the things that we discovered in our interaction with Workday was that there is a neat concept that we can borrow from the software-as-a-service companies, and that’s a notion of multi-tenanting. You’ll hear us talk about more multi-tenanted integration, where I can take standard integrations -- such as to Workday, ADP, SAP, or SalesForce – and host those core integrations in a central spot. Once I’ve got that core integration built, I can make small changes to make it unique for all the different people who want it.

Everybody will have exactly the same data formats, but I take that core thing and then allow many slight variations that co-exist, and you get this notion of multi-tenanted integration. As I said, you’ll hear us talk about it more, and this is another piece of the puzzle that starts to make this a better, different way for companies to get out of the middleware business, or at least radically reduce and centralize all that’s happening in one virtual spot, and not scattered everywhere.

Gardner: Just to step back a moment. We’re not just talking about loosely coupled interoperability here, right? We’re talking about integration across a variety of different needs that organizations would have, depending on their unique legacy, applications, and platform environments. So, when we talk about integration and hosting, we are going to give them a quite a long check list. Is this is going to be the binary, object, and component level, or we are just talking loosely coupled XML and mashup types of activities, or all of the above? How do we make this into a list that could be managed from the provider perspective as well as from the customer’s perspective?

O'Toole: We’ve seen two fundamental preferences here, and there are two options for what you want to host. The first option we would broadly categorize as very loosely coupled data transformation. A lot of the things that people need to solve in terms of integration problems are really data transformation. How do I take payroll information from one provider, transform it, and send it down to another provider? Most people can deal with that. Most people can wrap their head around how that can be done in a hosted manner. What’s involved there is that it’s loosely coupled and it’s data. It’s ultimately some kind of XML or it gets converted into XML somewhere along the line.

The next thing is a step up from that. Now that I can get information between these things, do I want to have some orchestrations or some kind of inter-company business processes? It’s not just getting data from A to B, but it’s, “I want to get data from A to B, and then I want to call C, and when C has completed its job, then I want to call D, and when that’s complete, the whole thing is done.”

That’s next level of complexity, and it involves a more sophisticated approach. But, both of them are possible and both are in operation today. As far as what customers are going to go for, I think they’ll be happy to do data transformation initially, and when that’s really working for them, they might be prepared to take the next step and host business processes in the cloud.

Gardner: I suppose another trend in the field these days, Annrai, is that the very notion of an application is up for grabs. We used to have applications as packaged applications of functionality, and they had logic, data, and presentation, but we are moving away from that.

It’s coming down more to who understands vertical business issues and can assemble components and assets and services to create advantage, efficiency, and productivity benefit by combining human knowledge, understanding, and relationships. That’s different than just plopping down an application and then rallying everyone around it to work within its requirements and definitions of productivity. It seems to me that what you are doing, even if it’s on the loosely coupled basis alone, is allowing for that redefinition of business applications and processes to accelerate as a catalyst to that. Do you agree?

O'Toole: Absolutely. We’re already well past the definition of applications as monolithic, stand-alone entities, and we are already into a more federated, loosely coupled environment. Look at the things that SalesForce is trying to do, for example, with AppExchange, and their desire to host more and different applications, but all in the same SalesForce portal.

You’re going to see that model applied in a very generic way across a whole range of different applications, and it’s really going to break down the barriers between applications. In some sense, it’s taking mashups to the next logical conclusion. That process has already started. We’ve already seen the first inklings that it’s coming to every large enterprise on the planet over the next several years. The alternatives to it just don’t make economic sense anymore.

Gardner: It could happen to these enterprises, whether they want it to or not. The line-of-business people and those who are aggressive about seeking out productivity on their own are going to do that.

O'Toole: A good analogy is what really drove client-server or the Internet as big computing waves. The line-of-business people could sit at a desktop and see something in action. You had color, and it wasn’t a green-screen mainframe application, and you could get them tailored really quickly. Business people got that very readily.

Gardner: They really increased the universe of participants in computing.

O'Toole: Correct. With the Internet, you could show people a browser and they got it really quickly. For the longest time, a lot of concepts around SOA have been inexplicable. You can’t explain them to a business person. You think you might get there, but then you start talking about governance and you are just down the weeds. You can’t sit them at a laptop and show them SOA, but you can sit down and show them mashups. You can show them hosted applications. I believe that you can even show them hosted integrations.

We can show our customers ADP runs, on which they’d have to do nothing in terms of getting them to work. You can show those to business people, and they get it. That’s what’s changing the definition of what an application is, because business people can actually see these mashups and all the stuff running for themselves, and they say, “This is really interesting. Now, I know what this stuff is all about.”

Gardner: You’ve mentioned SalesForce several times, and you’ve mentioned Workday. Is there going to be an opportunity for other types of organizations? I’m thinking about Amazon, Google, and Microsoft recognizing that there’s an opportunity for them to come in and provide more subscription-based services, these loosely coupled integration points and mashup points.

Is that how you see this evolving, that there will be a handful of large generic players? Or, will this be something that needs to be done on a more specific basis closer to the individual organizations, closer to individual departments, or perhaps both. Will we have a grassroots ecology of small providers as well as some large mega providers?

O'Toole: Yeah, that’s a very interesting question. I don’t have the answer, but there are a few trends that you can see. Undeniably, a lot of the bigger players are actively trying to muscle into this space already, Amazon, in particular, with their accessories stuff. They’re great. So, you’re going to see more of that. However, the other people who are going to make a huge contribution are the whole open-source community.

Over the next several years we’re going see a different set of development tools emerge around wikis. I was looking at some of this QEDWiki stuff from IBM and some from Oracle, and I think you are going to start to see a different way for people to build enterprise applications along enterprise mashup sever concepts. That hasn’t really begun yet.

There are leaves blowing in the wind, but there’s nothing concrete there just yet. If we conquer that one, then that’s going to put really flexible composite application construction into the hand of every size organization. That means we wouldn’t end up with this thing owned by just the big players, such as, “You are just going to get what Amazon wants to give you and nothing else.” It will create a new world for organizations of different shapes and sizes to have easy-to-use tools to build their own stuff.

Gardner: So, perhaps it will be a very fertile period, in which the number of people that can participate in development – who have a role in how to exploit information technology for their business purposes – expands. They don’t have to go through a keyhole, pushing requirements in and waiting for something come back through the door six months later. We will increase the number of people that can directly participate in shaping how IT helps them.

At the same time, we’re also compressing the time it takes for them to recognize some value from this. That is to say, if they can start doing mashups, if they can relate their knowledge of business issues and problems directly into a hosted environment or mashup interface of some kind, then we increase the number of people, but we compress the time before those people can enjoy the benefits of their labor.

That sounds like a very powerful combination that will -- perhaps even more than what we saw in client-server and Web browsing -- accelerate adoption and drive people to want to have a role in this. This goes especially for the younger people today who are used to driving their own destiny online.

O'Toole: As the Web 2.0 generation gets into the enterprise, they’re going to have a very different view of how things should be done. They want it done the way that they have experienced this medium as teenagers. They’ll say, “What do you mean you can’t do it the way I want to do it?” I certainly hope that that’s the way it turns out, because we are just about due for another major innovation in the app development life-cycle.

Gardner: For some of these interesting possibilities to occur, we also have to get back to the pragmatic notion that it needs to make business sense. For an organization like Workday, SalesForce, or Amazon, given the resources that they are going to need to pull this off, there’s going to be a lot of translation and semantic traffic, as you get close to the orchestration that you described. A series of events has to happen in a certain of pattern and be published and subscribed.

A complexity comes up about different requirements being fired off before the other set can be attempted. They’re going to have to have quite a bit of infrastructure and resources. Is there a business model that makes sense for them be able to fund their needs, provide the reliability and speed that people are accustomed to, and still make a profit? How does this work in dollars and cents terms?

O'Toole: There are two aspects to this. As we practice this multi-tenanted integration, what that’s going to enable us to do is dramatically driving down the cost of integration. If I am a customer in a large enterprise, on Amazon, or whatever, and I go and build an integration, I’ve got to build it uniquely for every single app and version of the app that it touches. So, I’ve got to kit out this huge infrastructure and code this unique piece of integration. That’s really expensive.

If we can move away from that to a different infrastructure, even though it’s still a pretty complex infrastructure, what it supports is the notion of building the integration once, and then making minor modifications to customize it for lots of different users. That can amortize that infrastructure cost over many different customers. If I can move to that model, that changes the economics for the provider. It enables them to offer more flexible pricing models to their customers.

The obvious ones are in the subscription-based models for the integrations that they host for you. That’s how I see the economics of it working. I really believe that because of the innovations that have been taking place in both the standards and in the underlying infrastructure for SOA around the ESBs, this multi-tenanted integration is here and is going to be a big driver in the current equation.

Gardner: So, at a basic level, we’re talking the 80-20 rule again, where 80 percent of the functionality is recurring and common. Its reuse can be paid for over a period of time, and then the 20 percent is dealt with case by case, and that can be managed as a cost, because of the efficiencies of the other 80 percent.

O'Toole: Correct.

Gardner: What is it about the technologies today that’s going to make that possible? Obviously, infrastructure, virtualization, and the storage prices have come down significantly. I suppose there’s another issue we haven’t talked about, and that’s the ability to get the highly specialized people to do these things. Each company, if they try to hire them individually to build this, might find, despite their great intentions and ability to invest, that they just can’t find the people.

Therefore, they might be forced to recognize that, given the scarcity of resources, there has to be a more cooperative approach. Let’s let those skilled people who are fundamentally ready to attempt these things do it, but more in a more centralized way. Then, we can all enjoy that common 80 percent benefit. Two questions. One, does it make sense, given the human resources issues, that we centralize? And is that another factor in the cost equation?

O'Toole: One business that’s there waiting to be created is a universal hosting business for integration, pretty much along the lines of what Grand Central had in mind.

Gardner: And what Google has done when it comes to search. No one can touch them, because of their expertise in that.

O'Toole: It’s absolutely possible for someone to own the data centers, and the expertise to offer this virtualized integration. Someone – in fact several people -- are going to try to own that over time. For a lot of small- to medium-sized businesses, that’s going to be hugely attractive. I can well imagine this small- to medium-sized business coming along and seeing a palette of available hosted integration – from SalesForce to all the different desktop CRM applications and SAP integration -- sitting out there, ready for them. If it doesn’t exactly support what they need, there’s a simple model, where they can send in the data format, state the business processes they need to support, and they’ll get a quote back saying, “This is what it’s going to cost you on a monthly basis.” I see that as a very viable option.

Gardner: Okay. If I’m an enterprise, and I’m intrigued by some of these notions and believe that this is the future, although I can’t readily predict at what pace and where things will happen, how do I get started? How should I rationalize this to my CFO? Is there a formula in terms of, “We can reduce our capital expenditures by blank percent, but we’re going to have to increase our subscription payments or recurring predictable expenditures by another?” How do we help companies understand how to get started, and then how to explain why this would make sense financially? Are they going to be paying by transaction, by user, by application, by service? It’s pretty hard to put a meter on this. Where do you attach the meter on how to build for these things?

O'Toole: They’re all good questions, so let me break them off one by one. For a lot of our enterprise customers, what we say to get them started is that as they think about their SOA initiatives and building internal SOA applications, they should be planning, building, and hosting the integration to those services at the same time. What we say to them is, “Okay, this great hosted integration vision doesn’t quite exist today, but you can create a mini version of it for yourself inside your own organization. So, when you build a service that you’re going to offer to either internal customers or to external ones, don’t only build up service, but find out who’s going to need to use that service, and build the integrations for them.

That gets them going down a path, where they’re at least containing all their own internal integrations in one spot. Maybe some time in the future, they’ll be able to hand that off to someone else, but that’s another day’s work. So we say to them, “That’s a good starting point.”

Alternatively, if they’re a smaller businesses, and they’re not interested in doing SOA things, we then encourage them to look at companies like SalesForce and Workday and see how they are approaching these integration problems.

Gardner: Go at it through the software-as-a-service applications approach.

O'Toole: Exactly. Go down that road. So, there are two starting paths, depending on whether you’re going to build stuff yourself or you don’t want to be in the development business at all.

In terms of cost justification and how you price for this, right now I don’t think you can charge on a per transaction basis. Our thinking is that you’re still going to charge for this just in terms of the overall volume that you need for CPU-based pricing, because we don’t think that pricing them on an individual transaction basis or an individual integration point basis make sense. People don’t really want to go there yet. We just say, “Okay, the services you’re going to need to create are going to need two or four CPUs, so that bounds your price and you can either pay on a subscription base or you can do it a one-off payment.”

Gardner: Does the per-employee model work in this respect?

O'Toole: No. Certainly, we haven’t seen them working well, because for most organizations, they start off doing something pretty simple that isn’t critical to the business. So, you can’t turn around and say, “You are JP Morgan. You’ve got 150,000 employees, so this simple thing is going to cost you ... blah.” This is still an evolving area, but I think the point that we’d make is: this is being done now, so whether you’re doing it on an internal basis or you’re someone like Workday and you are doing this on a pure hosted basis, this is the model.

People are already going with this model now, and they’re increasingly not going with the model of buying complex SOA suites and three years worth consulting. They’re adopting approaches that are much more on-demand and hosted from the get go. So, the future is now. This stuff is happening at the moment as we speak.

Gardner: It’s very exciting. As people process the notion of SOA and recognize the benefits, particularly the small- and medium-sized businesses, these light bulbs start to go off, and things fall into place.

I’m glad we’ve had a chance to explore this a little more deeply. It’s a very interesting adjunct to the SOA discussion, as well as that discussion around how applications, by definition, are changing. We might soon have some examples of how the cost benefits are real and compelling.

So, thank you, Annrai, for joining us in this discussion about hosted SOA, hosted integration and interoperability, and eventually getting to the notion of services compositing as a service.

This is Dana Gardner, principal analyst at Interarbor Solutions. We’ve been joined by Annrai O'Toole, CEO of Cape Clear Software. Any parting thoughts, Annrai?

O'Toole: No, I think I’ve said all that I needed to say on this one. So, as usual, it’s a pleasure, thanks for having me on the show.

Gardner: Sure. I think it’s a subject we should probably revisit every six months or so, because it’s bound to have some twists and turns in the journey, no doubt. Thanks for listening.

Listen to the podcast here. Podcast sponsor: Cape Clear Software.

Transcript of Dana Gardner’s BriefingsDirect podcast on the emergence of integration as a service for SOA. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.