Showing posts with label middleware. Show all posts
Showing posts with label middleware. Show all posts

Wednesday, January 12, 2011

Move to Cloud Increasingly Requires Adoption of Modern Middleware to Support PaaS and Dynamic Workloads

Transcript of a sponsored BriefingsDirect podcast on how to modernize infrastructure to enable IT to become better "business service factories."

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Learn more about WSO2 and cloud management
Download "Effective Cloud Management with WSO2 Strategies"
More information on WSO2 Stratos
Attend a WSO2 SOA Workshop to Energize your Business with SOA and Cloud

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

Today, we present a sponsored podcast discussion on the role and importance of private cloud infrastructure models as a stepping stone to much needed new operational models for IT.

A lot of the interest in cloud computing generally has been as much about a wish to escape the complex and wasteful ways of the old as an embrace of something well understood and new. [Disclosure: WSO2 is a sponsor of BriefingsDirect podcasts.]

So, how do large enterprises remake themselves into business service factories? How do they modernize IT and Internet-enabled ecosystem processes in the same ways that industrial engineering, lean manufacturing, efficiency measurement, just-in-time inventory, and various maturity models revolutionized bricks and mortar businesses a generation ago?

This larger question of how to attain IT transformation is what cloud computing purports to answer. But, the question itself may be more important than any yet defined answer. If public cloud computing is an end goal that provides a catalyst to such needed general transformation, all ends well and good.

Meanwhile, what of the practical steps that can help an organization now? How can enterprises learn to adopt new services sourcing models as well as to attain the means for better consumption of services, regardless of their origins?

Today, we’ll examine how enterprises can appreciate the transformative role of private cloud, and begin to focus on dynamic workloads and agile middleware as essential enablers along the way to even larger process-level business benefit -- and then ultimately to a more fully cloud-based IT models.

To discuss how workload assembly in the private cloud domain provides a big step in the right direction for IT’s future, we're joined by Paul Fremantle, the UK-based Chief Technology Officer and co-founder of WSO2. Welcome, Paul.

Paul Fremantle: Hi, Dana. How are you doing?

Gardner: I'm well, thank you. We are also here today with Paul O’Connor, Chief Technology Officer at ANATAS International in Sydney, Australia. Welcome to you as well, Paul.

Thanks, Dana.

Gardner: Paul O’Connor, tell me a little bit about why a transformative new approach to IT is necessary. It seems as if incremental improvement is just not good enough.

Past failures

O'Connor: It’s unfortunate, but it’s fair to say that all of the past initiatives that we tried in
large, complex enterprises have been a failure. In some cases, we’ve actually made things worse.

Large enterprises, at the same time, still have to focus on efficiency, agility, and delivery to their end users, so as to achieve market competitiveness. We still have that maniacal focus on delivery and efficiency, and now some new thinking has come in.

Specifically, we have cloud or the everything-as-a-service operating model coupled with a series of other trends in the industry that are being bolted together for a final assault on meaningful efficiency. You hit the nail on the head when you mentioned industrial engineering, because industrial engineering is the organizing principle for weaving all of these facets together.

When we focus on industrial engineering, we already have an established pattern. The techniques are now lean manufacturing, process improvement and measurement of efficiency, just-in-time inventory, maturity models. Ultimately, large enterprises are now approaching the problem effectively including cloud, including moving to new operating models. They're really focusing on building out that factory. I'm sure we’ll be able to tease out some of those specifics at a slightly lower level of detail as the podcast goes on.

IT itself is transformative and you have to be pushing the boundaries in order to compete in the modern world.



Gardner: Well, great. Maybe you could also tell us a little bit more about ANATAS International; what sort of organization is that and what do you do there?

O'Connor: I'm CTO. We serve the Asia-Pacific region and have focused for a number of years on next-gen architecture -- technical architecture, enterprise architecture and service oriented architecture (SOA). In the last couple of years, we’ve been focusing as well on cloud, and on how these things come together to give us a shot at being more efficient in large complex enterprises.

Gardner: Paul Fremantle, why do you think that the idea of cloud computing has really caught on, whether it’s private cloud, public cloud, platform as a service (PaaS), or infrastructure as a service (IaaS)?

We're adding more "as services" all the time, but this really seems to have just caught in people’s attention in the last two or three years, and seems to be gaining. It doesn’t seem to be waning. Is it this need for a transformative approach that has made cloud somewhat of a silver bullet? Why is this so important to people?

Fremantle: It’s a fairly straightforward story. We've discovered that you cannot just build an IT
system or an IT infrastructure, put your feet up, sit back, and say, "Well, that will do the business," because the business has learned that IT itself is transformative and you have to be pushing the boundaries in order to compete in the modern world.

Effectively, it’s no longer good enough to just put in a new system in every 5 or 10 years and sit back and run it. People are constantly pushing to create new value to build new processes, to find better ways of using what they have, linking it together, composing it, and doing new things.

So the speed of delivery and the agility of organizations have become absolutely key to their competitiveness and fundamentally to their stock price. A huge move in agility came first with web, with portals, and with SOA. People discovered that, rather than writing things from scratch, they could reuse, they could reconfigure, and they could attach things together in new ways to build function. As they did that, the speed of development and the speed of creating these new processes has skyrocketed.

Unfortunately, the speed and agility of the infrastructure and of the ability to take these things and host them has not kept up. What cloud has done is that it has suddenly energized the infrastructure, energized the platform, and has given people a way of not just building things quickly but hosting them, deploying them, and managing them in an agile way. Fundamentally, what’s driving the cloud revolution is speed of delivery.

Gardner: I’ll go back to Paul O’Connor with his comments about architecture. As we do what Paul Fremantle has suggested, we seem to also hit up against scale. Automation needs to kick in, and that can perhaps only be best attained through an architecture built for scale. How do the modern platforms and systems that Paul Fremantle is discussing provide a catalyst, or at least a cohort, to this need for better architecture, Paul O’Connor?

Better architecture

O'Connor: When we say better architecture, I think what we are talking about is the facets of
architecture that are about process, that are about that how you actually design and build and deliver. At the end of the day, architecture is about change, and it must be agile. I can architect a fantastic Sydney Opera House, but if I can't organize the construction materials to show up in a structured way, then I can’t construct it. Effectively, we’ve embraced that concept now in large enterprises.

Specifically in IT, we find coming into play around this concept a lot of the same capabilities that we’ve already developed, some of which Paul alluded to, plus things like policy-based, model-driven configuration and governance, management and monitoring and asset metadata, asset lifecycle management types of things relative to services and the underlying assets that are needed to actually provision and manage them.

We're seeing those brought to bear against the difficult problems of how might I create a very agile architecture that requires an order of magnitude less people to deliver and manage.

It helps with problems like this: How can I keep configured a thousand end-points in my enterprise, some of which might be everything from existing servers and web farms all the way up to instances of lean middleware like WSO2 that I might spin up in the cloud to process large workloads and all of the data associated with it?

Gardner: I suppose also, Paul Fremantle, that a secondary or additional motivator at this time is the need for pervasive security, for baking security and governance in across the board, not as a bolt-on, not as an afterthought, not as some sort a requirement of that is separate and distinct from the entire IT lifecycle.

There's an opportunity to turn that from a negative into a positive by fundamentally building secure systems from day one, rather than just relying on them being secure from where they are located, which is kind of the current model.



So, is there also a bit of a catalyst when it comes to making security pervasive that's also driving folks to better architecture and more agile middleware that will perhaps ultimately move toward a cloud-based model?

Fremantle: Absolutely. The biggest concern in everyone's mind around cloud is security. I think there's an opportunity to turn that from a negative into a positive by fundamentally building secure systems from day one, rather than just relying on them being secure from where they are located, which is kind of the current model.

I'm a firm believer that the real success in cloud is going to come from designing systems that are inherently built to run in the cloud, whether that's about scale, elasticity, security, or things like multi-tenancy and self-service.

Those concepts of building things that run in the cloud and making the software inherently cloud aware, comes back to what Paul O'Connor was talking about with regard to having the right architecture for the future and for the cloud.

Gardner: So, when we look at security as a positive, rather than a negative, as we transform and transition with cloud models, is there more than one layer or level of security? How do we approach this? How do we get our hands around it, so that it can be something that's implemented, rather than almost just at the division or abstract level?

Federated security

F
remantle: The first and most important thing is to use middleware and models that are designed around federated security. This is just a simple thing. If you look back at middleware, for example message queuing products from 10 years ago, there was no inherent security in them.

If you look at the SOA stack and the SOAP models or even REST models, there are inherent security models such as WS-Trust, WS-SecureConversation, or in the REST model things like SAML2, OAuth and OpenID. These models allow you to build highly secure systems.

But, however much I think it's possible to build secure cloud systems, the reality is that today 90 percent of my customers are not willing or interested in hosting things in a public cloud. It’s driving a huge demand for private cloud. That’s going to change, as people gain confidence and as they start to protect and rebuild their systems with federated security in mind from day one, but that's going to take some time.

Gardner: Paul O’Connor, do you share Paul Fremantle's concept that good architecture and building for cloud models has an inherent security benefit to it? Are you at ANATAS also architecting for both security and a services factory model?

O'Connor: Absolutely. You're not allowed to do anything in large enterprises architecturally without getting past security. When I say get past security, I'm talking about the people who have magnifying glasses on your architectural content documents. It's important enough to say again what Paul brought out about location not being the way to secure your customer data anymore.

The reality is that today 90 percent of my customers are not willing or interested in hosting things in a public cloud. It’s driving a huge demand for private cloud.



The motivation for a new security model is not just in terms of movement all the way to the other end of the agility rainbow, where in a public cloud you’re mashing up some of your data with everybody else's, potentially, and concerned about it going astray.

It’s really about that internal factory configuration and design that says, even internally in large enterprises, I can't rely on having zones of network security that I pin my security architecture to. I have to do it at the message level. I have to use some of the standards and the technologies that we've seen evolved over the past five, six, seven years that Paul Fremantle was referencing to really come to bear to keep me secure.

Once I do that, then it's not that far of a leap to conceive of an environment where those same security structures, technologies, and processes can be used in a more hybrid architecture, where maybe it's not just secure internal private cloud, but maybe it's virtual private cloud running outside of the enterprise.

That brings in other facets that we really have to sort out. They have to do with how we source that capacity, even if it's virtual private cloud or even if it's tenanted. We have to work on our zone security model that talks about what's allowed to be where. We have to profile our data and understand how our data relates to workloads.

As Paul mentioned, we have to focus on federated identity and trust, so identity as a service. We have to assemble the way that processing environments, be they internal or external, get their identities, so that they can enforce security. PKI, and, this is a big one, we have to get our certificates and private keys into the right spot.

Policy-driven governance

Once we build all those foundations for this, we then have to focus on policy-driven governance of how workloads are assembled with respect to all of those different security facets and all of the other facets, including quality of service, capacity, cost, and everything else. But, ultimately yes, we can solve this and we will solve this over the next few years. All this makes for good, effective security architecture in general. It's just a matter of helping people, through forums like this, to think about it in a slightly different way.

Gardner: As we're moving toward new kinds of architectures that can be inclusive of the past, but prepare us better for the future with this full set of requirements in terms of scalability, security, openness to sourcing elasticity, and so forth, what do we need to look for in terms of the underlying infrastructure itself?

Are there some key requirements that we would look for in terms of how the performance, technical characteristics, standard support, all come together in such a way that we can move forward including compatibility with what's in place -- and still start meeting up with what we want around performance, the sourcing flexibility and security? Let me take that first to Paul Fremantle. What needs to be in place?

Fremantle: I believe that the world has slightly gone backward, and that isn't actually that surprising. When people move forward into such a big jump as to move from a fixed infrastructure to a cloud infrastructure, sometimes it's kind of easy to move back in another area. I think what's happened to some extent is that, as people have moved forward into cloud infrastructure, they have tended to build very straightforward monolithic applications.

The way that they have done that is to focus on, "I'm going to take something standalone and simple that I can cloud-enable and that's going to be my first cloud project." What's happened is that people have avoided the complexity of saying,"What I really need to be doing is building composite applications with federated identity, with business process management (BPM), ESB flows, and so forth."

Learn more about WSO2 and cloud management
Download "Effective Cloud Management with WSO2 Strategies"
More information on WSO2 Stratos
Attend a WSO2 SOA Workshop to Energize your Business with SOA and Cloud

And, that's not that surprising, when they're taking on something new. But, very rapidly, people are going to realize that a cloud app on its own is just as isolated as an enterprise app that can't talk to anything.

The result is that people are going to need to move up the stack. At the moment, everyone is very focused on virtual machines (VMs) and IaaS. That doesn't help you with all the things that Paul O'Connor has been talking about with architecture, scalability, and building systems that are going to really be transformative and change the way you do things.

From my perspective, the way that you do that is that you stop focusing on VMs and you try and move up a layer, and start thinking about PaaS instead of IaaS.

You try to build things that use inherent cloud capabilities offered by a platform that give you scalability, federated security, identity, billing, all the things that you are going to need in that cloud environment that you don't want to have to write and build yourself. You want a platform to provide that. That's really where the world is going to have to move in order to take the full advantage of cloud -- PaaS.

Gardner: Paul O'Connor, from your perspective, what are some key characteristics that that platform should have? What are the necessary ingredients in order to make this automated, controllable, governed, and to scale across these new sourcing models that we're approaching?

The name of the game

O'Connor: I totally agree with everything Paul Fremantle just said. PaaS is the name of the game. If you go to 10 large enterprises, you're going to find them by and large focusing on IaaS. That's fine. It's a much lower barrier of entry relative to where most shops are currently in terms of virtualization.

But, when you get up into delivering new value, you're really creating that factory. Just to draw an analogy, you don't go to an auto factory, where the workers are meant to be programming robots. They build cars. Same thing with business service delivery in IT -- it's really important to plug your reference model and your reference architectures for cloud into that factory approach.

You want your PaaS to be a one-stop-shop for business service production and that means from the very beginning to the very end. You have to tenant and support your customers all along the way. So it really takes the vertical stack, which is the way we currently think about cloud in terms of IaaS, and fans it out horizontally, so that we have a place to plug different customers in the enterprise into that.

And what we find is, just as in any good factory or any good process design, we really focus on what it is those customers need and when. For example, just to take one of many things that's typically broken in large enterprises, testing and test environments. Sometimes it takes weeks in large organization to get test environments. We see customers who literally forgo key parts of testing and really sort of do a big bang test approach at the end, because it is so difficult to get environment and to manage the configuration of those environments.

One of the ways we can fix that is by organizing that part of the PaaS story and wrap around some of the attendant next-generation configuration management capabilities that go along with that. That would include things like service test virtualization, agile operations, asset metadata management, some of the application lifecycle management (ALM) stuff, and focus on systemically killing the biggest impedances in the order of most pain in the enterprise. You can do that without worrying about, or going anywhere near, public cloud to go do data processing.

I think we will see larger appetites by the business for more applications and a need to put them into a place where they are more easily managed.



So that's the here and now, and I'd say that that's also supportive of a longer term, grand unified field theory of cloud, which is about consuming IT entirely as a service. To do that, we have to get our house in order in the same way and focus on organizing and re-organizing in terms of transformation in the enterprise to support first the internal customers, followed by using the same presets and tenets to focus on getting outside of the organization in a very structured way.

But eventually moving workloads out of the organization and focusing on direct interaction with the business, I think we will see larger appetites by the business for more applications and a need to put them into a place where they are more easily managed, and eventually, it may take 20 years, but I think you'll see organizations move to turn off their internal IT departments and focus on business, focus on being an insurance company, a bank, or a logistics company. But, we start in the here and now with PaaS.

Gardner: Okay. Paul O'Connor, if I can just add one more thing to that. I read in some of your literature -- and I quote from you -- “Work load assembly in the cloud is the name of the game.” It seems that you're talking about private cloud first, then, ultimately, any number of other hybrid cloud scenarios. Is that what you mean across this development, test, deploy, workload assembly? What do you mean by that?

What is it doing?


O'Connor: Workload assembly. What I mean by that is that we need a profile of what it is we do in terms of work. If I plug a job into the wall that is my next-gen IT architecture, what is it actually doing and how will I know? The types of things vary. It varies widely between phases of my development cycle.

Obviously, if I do load and performance testing, I've got a large workload. If I do production, I’ve got a large workload. If I move to big data, and I am starting to do massively scalar analytics because the business realizes that you go after such an application, thanks to where IT is taking the enterprise, then that's a whole other ball of wax again.

What I have to do is understand those workloads. I have to understand them in terms of the data that they operate on, especially in terms of its confidentiality. I have to understand what requirements I need to assemble in terms of the workload processing.

If I have identify show up, or private key, I have to do integration, or I have to wire into different systems and data sources, all of that has to be understood and assembled with that workload. I have to characterize workload in a very specific way, because ultimately I want to use something like WSO2 Stratos to assemble what that workload needs to run. Once I can assemble it, then it becomes even easier for me to work my way through the dev, test, stage, release, operate cycle.

Gardner: Paul Fremantle, tell me what WSO2 is doing to help people like Paul O'Connor reach this workload assembly capability?

That starts with some very simple things, like identity as a service, so that there is a consistent multi-tenant concept of identity, authorization, and entitlement available wherever you are in the private cloud, or the public cloud, or hybrid.



Fremantle: What we have done is build our Carbon middleware on OSGi. About two years ago, we started thinking how we're going to make that really effective in a cloud environment. We came up with this concept of cloud-native software. We were lucky, because, having modularized Carbon, we had also kernelized it. We put everything around a single kernel. So, we were able to make that kernel operate in a cloud environment.

That’s the engineering viewpoint, but from the architecture viewpoint, what we're providing to architects like Paul O’Connor is a complete platform that gives you what you need to build out all of the great things that Paul O’Connor has been talking about.

That starts with some very simple things, like identity as a service, so that there is a consistent multi-tenant concept of identity, authorization, and entitlement available wherever you are in the private cloud, or the public cloud, or hybrid.

The next thing, which we think absolutely vital, is governance monitoring, metering, and billing -- all available as a service -- so that you can see what's happening in this cloud. You can monitor and meter it, you can allocate cost to the right people, whether that’s a public bill or an internal report within a private cloud.

Then, we're saying that as you build out this cloud, you need the right infrastructure to be able to build these assemblies and to be able to scale. You need to have a cloud native app server that can be deployed in the cloud and elastically scale up and down. You need to have an ESB as a service that can be used to link together different cloud applications, whether they're public cloud, private cloud, or a combination of the two.

Pulling together

And, you need to have things like business process in the cloud, portal in the cloud, and so on, to pull these things together. Of course, on the way, you're going to need things like queues or databases. So, what we're doing with Stratos is pulling together the combination of those components that you need to have a good architecture, and making them available as a service, whether it's in a private cloud or a public cloud.

That is absolutely vital. It's about providing people with the right building blocks. If you look at what the IaaS providers are doing, they're providing people with VMs as the building blocks.

Twenty years ago, if someone asked me to build an app, I would have started with the machine and the OS and I would start writing code. But, in the last 20 years we've moved up the stack. If someone asked me to build an app now, I would start with an app server, a message queuing infrastructure, an ESB, a business process server, and a portal. All these components help me be much more effective and much quicker. In a cloud, those are the cloud components that you need to have lying around ready to assemble, and that to me is the answer.

Gardner: Paul Fremantle, you're describing what you think is the best way to support a workload assembly capability, but how is that different from what we're seeing from some of the service delivery platform vendors, and what we could call "cloud in a box?" What's the difference between what they're talking about and what you're talking about?

The thing that those PaaS providers are missing, and most of the PaaS that I see out there is missing, is a real enterprise architecture view of the world.



Fremantle: I'm seeing various things in the marketplace. Obviously, there are people like Eucalyptus, Ubuntu, and of course VMware, who are providing private IaaS, and that’s very important. We work on top of those layers. I'm also seeing a lot of people producing PaaS. December was an exciting month. We've had two acquisitions in that space.

The thing that those PaaS providers are missing, and most of the PaaS that I see out there is missing, is a real enterprise architecture view of the world. It's fine to provide a web app as a service and a database as a service. Those are the basic building blocks that people need. But, if you don't have an open, clear definition of identity, governance, business activity monitoring, BPM, and ESB, you're stuck in a 10-year-old architecture.

So, for me, where you're going to have to move is to a complete platform that understands enterprise architecture (EA). It isn’t just about saying, "I've got a web app and a database that are somehow provided in a cloud native fashion."

Gardner: Paul O'Connor, I'm an advocate of showing rather than telling, when it comes to these sorts of complex issues. Do we have any examples of perhaps companies that ANATAS has worked with, where they have employed some of these approaches, whether from a position of the technology, the actual implementation of certain products and services, the methodologies, or all of the above? What do you get? What happens when you do this properly? What sort of business and/or technical benefits can we expect based on the record so far?

O'Connor: I'll tell you about a large enterprise that we have been working with for a good long while. They are building an internal PaaS, an internal platform which is operated as a service. This is key. They're looking at that as a way to achieve some tangible benefits right out of the gate, while supporting a longer-term vision, which is about beating back into submission as much of the sprawl that has grown up over the course of time in large enterprises.

The immediate benefits in that case are about efficiency and business service architecture and constraints. By that, I mean that if you have one standard service delivery process that’s highly efficient that starts with modeling and works its way all the way through to operation in a business sense of business services, what you wind up with is an approach on the business side itself to use that as a lever to go out and directly be able to add in efficiencies, attack new markets, and really focus on some things on the business side that were latent, because there was a feeling that it couldn't be delivered efficiently by IT or may not work.

Seeing it work

We're really seeing that lever work. It's right there. We're also seeing a focus on a broader picture. I want to make one point following up on what Paul Fremantle was saying earlier. We really need to have, and this is what this client has done, a reference architecture that is sort of the antithesis of cloud in a box.

It's structured so that you don’t get tied into one particular vendor's view of cloud or anything else. You’ve really taken an Architecture 101 approach. You build a reference model, you build a reference architecture, you go execute against that, and you don’t have either an inheritance from the IaaS guys up into the higher parts of the stack or the sprawl from the existing platform players down into the infrastructure space.

Ultimately, and this is how this client views it, cloud is more than a way of thinking. It’s open and it’s about getting your house in order, but it’s also about not being locked in and trying to, in the case where we feel like we should, turn the table on our existing vendors.

And that’s what WSO2 is doing in terms of a feature-driven lean middleware and also the way that they are approaching delivery in terms of a professional open-source model, and is very much in keeping with the way that my clients view the cloud.

Gardner: Paul Fremantle, we only have time for one additional example. Do you have some customers that you've been working with that are perhaps what you would consider a bellwether for where the rest of the enterprises are likely to go?

It’s something I'm seeing a lot of software companies looking at as well, which is to start converting their applications into SaaS.



Fremantle: I want to put a different spin on this, which is that as well as the companies that are doing what Paul O'Connor was talking about and using PaaS to create the software factory concept within their organization, there is another angle on this, which is interesting. It's the ability of people, not just software vendors, but also system integrators and even service providers, to start using PaaS to create their own cloud software as a service (SaaS).

This was brought to mind to me by one European-based system integrator and business process outsourcer. Unfortunately, I can’t name them, but they're a partner of ours. What they've started to do is think, "When I'm building an application or a process for customer, is that something that is really applicable just to this one customer or is it something that is a reusable asset, that can be offered as a service to multiple customers?"

Of course, that may not be offered over the public cloud. It may be hosted in a private cloud and different companies give a VPN access to their own tenant within that. It’s something I'm seeing a lot of software companies looking at as well, which is to start converting their applications into SaaS.

And as you do that, you quickly find that the things you need, the capabilities that you need, in order to offer SaaS are the same capabilities that you need in a platform. They're the things I was talking about before, things like identity, governance, metadata, monitoring and metering billing.

To me, the interesting thing here is the intersection between how large enterprises are treating their software development and how software companies are treating their software development, and system integrators and business process outsourcers are treating their software development. They're all converging on the most efficient model that we have come up with yet.

Gardner: Very interesting. It sounds as if the IT ecosystem is marching in tandem towards the same vision, and that will perhaps enable these enterprises to move all the more quickly, rather than the enterprises doing it essentially on their own.

Fremantle: Absolutely.

Gardner: Well, very good. I'm afraid we're about out of time. We've been discussing how workload assembly and the concept of a business service factory are important attributes to private clouds, and how private clouds when established using these best practices and principles, can provide a huge stepping stone in the right direction for the future of IT, a transformed future of IT.

I want to thank our panelists. We've been joined by Paul Fremantle, the UK-based Chief Technology Officer and co-founder of WSO2. Thanks so much, Paul.

Fremantle: Thank you very much.

Gardner: And, we’ve also been joined by Paul O’Connor, the Chief Technology Officer at ANATAS International in Sydney, Australia. Thanks for joining as well, Paul.

O'Connor: Thanks, Dana.

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

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Transcript of a sponsored BriefingsDirect podcast on how to modernize infrastructure to enable IT to become better "business service factories." Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

Learn more about WSO2 and cloud management
Download "Effective Cloud Management with WSO2 Strategies"
More information on WSO2 Stratos
Attend a WSO2 SOA Workshop to Energize your Business with SOA and Cloud

You may also be interested in:

Monday, October 25, 2010

FuseSource Gains New Autonomy to Focus on OSS Infrastructure Model, Apache Community Innovation, Cloud Opportunities

Transcript of a sponsored podcast discussion on the status and direction of FuseSource, which is being given its own corporate identity today by Progress Software.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: FuseSource.

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

Today, we present a sponsored podcast discussion on the rapid growth, increased relevance, and new market direction for major open source middleware and integration software under the Apache license.

We'll learn how the FUSE family of software is now under the FuseSource name and has gained new autonomy as its own corporate identity. We'll also look at where FuseSource projects are headed in the near future. [NOTE: Larry Alston also recently joined FuseSource as president.]

Part of the IONA Technologies acquisition by Progress Software in 2008, FuseSource has now become its own company, owned by Progress, but now more autonomous, to aggressively pursue its open source business model and to leverage the community development process strengths.

Even as the IT mega vendors are consolidating more elements of IT infrastructure, and in some cases, buying up open-source projects and companies, the role and power of open source for enterprise and service providers alike has never been more popular or successful. Virtualization, cloud computing, mobile computing, and services orientation are all supporting more interest and increased mainstream use of open-source infrastructure.

Please join me in welcoming ours guests. We're here now to discuss how FuseSource is evolving to meet the need for open source infrastructure with Debbie Moynihan, Director of Marketing for FuseSource. Welcome to the show, Debbie.

Debbie Moynihan: Hi, Dana. Thank you. It's great to be here.

Gardner: We're also here with Rob Davies, Director of Engineering for FuseSource. Welcome to the show, Rob.

Rob Davies: Hi, Dana. Good to speak to you today.

Gardner: Debbie, tell me about some of the trends. As I said, we're seeing some of the most aggressive use of open source and IT infrastructure. We're seeing great success in terms of total cost, efficiency, and agility. Why is that happening now, and where do you see the demand trends headed to in the next several years?

Cost reduction

Moynihan: As we all know, over the past couple of years, there has been a lot of focus on cost reduction, and that resulted in a lot of people looking at open source who maybe wouldn’t have looked at open source in the past.

The other thing that’s really happened with open source is that some of the early adopters -- we have had customers for many years -- started out with a single project and now has standardized on FuseSource products across the entire organizations. So there are many more proof-points of large global organizations rolling out open source in mission-critical production environments. Those two factors have driven a lot of people to think about open source and start adopting open source over the past couple of years.

Then, the whole cloud trend came along. When you think about scaling in the cloud, open source is perfect for that. You don’t have to think about the licensing cost as you scale up. So, there are a lot of trends that have been happening and that have really been really helpful. We're very happy about them helping push open source into the mainstream.

From a FuseSource perspective, we've been seeing over 100 percent growth each year in our business, and that’s part of the reason for some of the things we're going to talk about today.

Gardner: How about the popularity of the Apache license? We see controversy, in some cases, a lack of clarity and understanding about where some other licenses are going, but Apache seems to be pretty solid and pretty accepted.

Moynihan: We really like the Apache license. There's a lot of confusion around open source licensing. There are many different licenses. There is a lot of fine print. A lot of people don’t want to think about it, and a lot of legal departments get concerned about the gray areas. The Apache license is very easy to understand and it's very permissive in what you can do with software that’s licensed under the Apache license.

Essentially, you can make any modifications you want to the software and you don’t necessarily have to contribute back to the community. It's nice, if you can contribute back, but from a business perspective, if you want to use any of the components, it's what's considered a non-viral license. So, you're pretty free to do what you want, as long as you give credit back to those who wrote the initial code.

Gardner: Rob, we've seen a lot of popularity for open source in operating systems -- server operating systems, in particular -- but why has the use of open source for infrastructure, say for integration and middleware, become so popular? Why do you think that’s going to continue with such things as cloud?

Davies: There has been a trend over the last few years, and Debbie alluded to this, with companies looking to open source and kicking the tires around. In fact, I recently spoke to a large customer of ours in the telco space. They had this remit. Any open source that came in, they wouldn’t put into mission-critical situations, until they kicked the tires for a good while -- at least a couple of years.

Because there has been this push for more open source projects following open standards, people are now more willing to have a go using open source software.

Snowball effect

We've been around in this space for a while, but the earlier adopters who were just trying out in distinct groups are now rolling this out into broader production. Because of that, there is this snowball effect. People see that larger organizations are actually using open source for their infrastructure and their integration. That gives them more confidence to do the same.

In fact, if you look at the numbers of some of our larger customers, they are using Apache ServiceMix and Apache ActiveMQ to support many thousands of business transactions, and this is business-critical stuff. That alone is enough to give people more confidence that open source is the right way to go.

Gardner: Debbie, tell us a little bit about the FuseSource move toward more autonomy. This clearly is an opportunity, but it’s a different opportunity than a purely commercial license and software model. Tell us what’s going on with Progress Software and FuseSource.

Moynihan: We're really excited as a team. Progress is launching a new company called FuseSource that will be completely focused on the open source business model. The FuseSource team has been an independent business unit, since IONA was acquired by Progress Software. We have been fairly independent within the company, but separated as our own company we'll be able to be completely independent in terms of how we do our marketing, sales, support, services, and engineering.

When you're part of a large organization, there are certain processes that everyone is supposed to follow. Within Progress, we are doing things slightly differently (or very differently depending on the area) because the needs of the open source market are different. So being our own company we'll have that independence to do everything that makes sense for the open-source users, and I'm pretty excited about that.

Being our own company we'll have that independence to do everything that makes sense for the open-source users, and I'm pretty excited about that.



Gardner: So, here we are in the middle of October, and this is pretty much now a done deal. Tell me about the history of FuseSource and what led up to this movement.

Moynihan: Rob, who is on the call, can maybe talk about the early days. He was actually a founder of a startup company and that was really the genesis of that is now FuseSource. So Rob, why don’t you start out and I can chime in if needed.

Davies: The notion is of having open source infrastructure start with a group of developers and founders in open source projects. It worked for commercial license based infrastructure product companies before. We -- the other individuals are James Strachan, Hiram Chirino, and Guillaume Nodet -- realized that the best way to deliver open source for infrastructure was to develop open source at Apache.

We decided that open source is the best thing to do, because it opens up the software for engineers to look at, use, and enhance. We felt like that was a very good way to grow a community around the projects we wanted to do.

We started this company called LogicBlaze, which was acquired three years ago by IONA. At that time, we decided to sell to IONA because we wanted to piggyback on their expertise of doing large infrastructure rollouts. IONA, the FUSE brand, and the FUSE product line then really came into the forefront.

Get the message out

D
ebbie Moynihan, who was the director of open source at IONA, was working on another project at the time called Celtix, which morphed into Apache CXF. We decided to collaborate on this effort to get this message out about using really good infrastructure based on Apache open source projects and get that into the marketplace.

Then, when IONA was acquired by Progress, Progress initially liked the idea, or liked the fact that it’s disruptive. They invested in the group: we added more employees, more sales people, more people in marketing, etc. We have been involved in that for the last two years.

But, it has gotten to a point where we realized that to operate it in its most effective way it has to be outside of Progress to a degree, because it is so different in the go-to-market strategy and what we deliver to customers compared to the rest of what Progress is doing with the one-product solution.

Moynihan: Also, from a business prospective, Progress’ go-to-market is, as Rob said, offering solutions at the business level, whereas open source has traditionally been looked at by developers and project managers more from a technical perspective and more from an open source advocate perspective.

That’s growing over time, as we have talked about earlier. Open source is becoming more and more mainstream, but our approaches to marketing and sales are different in the FuseSource team and are much more community oriented and grassroots than the way that corporate marketing is done at Progress Software.

Our model is that there is no license cost. It’s a subscription support model.



Gardner: Let’s face it, the business models are quite different. The way in which you develop revenue is more through support and maintenance and not on the upfront costs and implementations. Maybe you could explain why the business models being separate makes more sense.

Moynihan: Absolutely. From a practical perspective, the business model is very different. In traditional enterprise software sales, there is a license fee which is typically a large upfront license cost relative to the entire cost over the lifetime of that software. Then, you have your annual maintenance charges and your services, training, and things like that.

From an open source perspective, typically upfront, there is no license cost. Our model is that there is no license cost. It’s a subscription support model, where there is a monthly fee, but the way that it is accounted for and the way that it works with the customer is very different. That's one of the reasons we split out our business. The way that we work with the customers and the way they consume the software are very different. It’s a month-to-month subscription support charge, but no license charge.

Gardner: It’s interesting to me that Progress with FuseSource recognizes that there is that little bit of apples and oranges going on, and perhaps keeping them separate is in the best interest of the users and the community. But, we're seeing the opposite in other companies, where people are looking to fold open source projects and products into a larger family or stable of commercial products.

Do you think that we are going to see that trail off in the market? I guess the question is: what about these mega vendors and the direction of how an open source model and a commercial model should or shouldn’t overlap or exist together?

Very difficult

Moynihan: There are a lot of opinions out there on whether or not open source can be successful in a hybrid model within a single mega vendor. My view is that it’s very difficult, especially because the business model is different. If you're a company and you're out there selling a large portfolio of products, where only a small amount of it is open source, you have a team of people trying to sell, market, and grow business around that portfolio. They're going to focus on the license product.

They're going to have a tendency to focus on those products that are going to drive revenue in the short-term, from a business perspective. It has nothing to do with whose model is better.

I'm very happy that Progress has decided to separate out FuseSource. We already had our own sales team, but now we can be completely focused on working with our customers to help them adopt open source, and when it makes sense, they can work with us to get support and to get training.

It’s a very consultative partnering model. In the early days we really like to provide everything someone needs to get going at no cost. You can come to FuseSource.com and get a lot of documentation, and you can get a lot of training webinars for free. We have weekly webinars that show you how to get going on our products, and that’s nothing that you would see in traditional commercially licensed software.

Gardner: Debbie, tell me about what a customer should expect. If you're a user of FuseSource and if you're in the community, how will this move towards autonomy actually impact you? Will you perhaps not even notice too much?

Overall, it will be really good for our customers. We've talked with them, and they're pretty excited about it. We're all excited about it.



Moynihan: From a customer perspective, this change will have a small but significant impact. We are continuing to do everything that we have been doing, but as I mentioned earlier, we will be able to have even more independence in the way that we do things. So it will all be beneficial to customers.

From an administrative perspective, our email address will change to FuseSource.com and invoices will say FuseSource instead of Progress Software, for example. But, from who they're going to be working with, who their account managers will be, who is developing the software, and who is providing the services and the support, it’s going to be the same people that they have been working with.

We have also launched a new community site at FuseSource.com, which we're pretty excited about. We were planning to do that and we've been working on that for several months. That just provides some additional usability and ability to find things on the site.

Overall, it will be really good for our customers. We've talked with them, and they're pretty excited about it. We're all excited about it.

Gardner: Let's get back to looking at the overall market for infrastructure, open source infrastructure in particular. Rob, tell me a little bit about what's going on in the market?

We're seeing a lot of interest in clouds, private clouds, hybrid clouds. We're certainly also seeing a great deal of emphasis on reducing costs, particularly from the service provider, where they are going down to minute margins in some cases. They really need to make to sure that they're doing this in the most cost-effective manner. Then I have to imagine that if the service providers are able to provide IT-as-a-service at a low cost, the IT enterprises themselves will have to follow suit.

Help me understand the new economics of IT and how open source infrastructure fits into that.

Disruptive in the market

Moynihan: From a market perspective, at a high level, open source is really disruptive in the market in that it's affecting how people are buying software. Generally, we've seen a lot of changes over the past 5 to 10 years anyway, where license costs seem to be coming down with more and more discounting, and people are looking at it.

Historically, software vendors looked at license revenue as the premium part of the business to focus on. More and more they're realizing that a lot of value really does come from the services side. Why? Because that’s where you partner with your customer. That’s where you get to know them. That’s where you help them select the right solutions.

In the open source community, that’s how it works. People come to the community and work with the developers directly. It eliminates a lot of the cost involved in large, complex software organizations, where you might have to wait to schedule time of the product manager, who then would have to spend time with the engineers understanding what's happening with the products, so that he could then relay it to the account team, and then they would meet with the customer.

Open source just breaks down a lot of barriers and eliminates a lot of the costs involved in getting the best software to the users. Why? Because people are talking directly to the developers in the community. The developers are getting the feedback directly.

While we do have some level of product management for open source, a lot of it is based around packaging, delivery, licensing, and these types of things, because our engineers are hearing directly from customers on a moment-by-moment basis. They're seeing the feedback in the community, getting out there, and partnering with our customers. So, from an economic perspective, the model is different.

You pay as you go. You scale as you go. And you don’t have that upfront capital expenditure cost.



Just from the overall "how it works" from a buy-in perspective for the customer, it's very different. It's very attractive in these times that we are having right now, because upfront you don’t have the capital expenditure costs. You can get going. You can go to an open source community site, download the software, and try it out.

We've actually seen people get to proof of concept before they have even spoken with us. We've seen people build our stuff into a product as an application provider, as an OEM, and then come to us. That will tell you how easy it is for people to consume and use open source without having to spend a lot trying to select or figure it out, before they even can try it out.You can try it before you buy it, and when you go to buy, you pay as you go.

That’s also the reason people like cloud. You pay as you go. You scale as you go. And you don’t have that upfront capital expenditure cost. For new projects, it can be really hard to get money right now. All these benefits are why we're seeing so much growth in FuseSource.

Gardner: Are there some salient examples that demonstrate what you've been talking about? I'll throw this out to either one of you. Some of your customers might be good examples of how this can work, both from an economic, technical, and innovation freedom perspective as well.

Moynihan: I'll mention a couple of examples. They are kind of similar and something that we are seeing more and more. Sabre Holdings delivers a lot of applications for various airlines. They have a lot of partners, travel agencies, and airlines. Also, the Federal Aviation Administration (FAA). Those are two of our customers.

In both of those cases, they started looking at open source at the project level, but eventually came to standardize on open source for their common integration infrastructure, and to recommend it - not just within their own organizations - but in both of those cases, to their partners.

Integration is easy

That’s the really nice thing about open source. Integration within your own company is easy. You can have any crazy interface and you'll figure out how to do it. But when you partner, you can't tell your partner how to build their interfaces. But, you can have a common integration platform and say, "Can you transform your stuff so it can connect to this platform?"

With open source, they don't have to have a license for that. So, it's quite nice. They can get going, try it out, and see how it works without requiring their partners to pay any cost. From an economic perspective, they could try it out, get going, look at some proof concepts, test it out, and then rolled it out for a standardized infrastructure internally for some major projects. Then, work with partners to roll it out further.

Gardner: To your point Rob, we've heard a call for more standards in the market around cloud, such as common operating environments and standards for interoperability. In lieu of having those structured standards develop rapidly, we have the open source fallback position. We can't always know what the commercial underpinnings are for services across an ecosystem of cloud consumers or providers, but having a common open-source infrastructure base might very well serve that purpose. Is that what we are finding technically?

Davies: That’s really on the money, Dana. There is this trend as well. When you look at cloud, there are different issues you have to overcome. There is the issue about deploying into the cloud. How do you do that? If you're using a public cloud, there are different mechanisms for deploying stuff. And there are open source projects already in existence to make that easier to do.

This is something we have found internally as well. We deploy a lot of internal software, when we are doing our big scale testing. We make choices about which particular vendors we're going to use. So, we have to abstract the way we are doing things. We did that as an open source project, which we have been using internally.

You have to have choice. You can’t really dictate to use it this way or the other way. You've got to have a whole menu of different options for connecting.



When you get to the point of deploying, it’s how do you actually interface with these things? There is always going to be this continuing trend towards standards for integration. How are you going to integrate? Are you going to use SOAP? Are you going to use RESTful services? Would you like to use messaging, for example, to actually interface into an integration structure?

You have to have choice. You can’t really dictate to use it this way or the other way. You've got to have a whole menu of different options for connecting. This is what we try to provide in our software.

We always try to be agnostic to the technology, as much as how you connect to the infrastructure that we provide. But, we also tend to be as open as we can about the different ways of hooking these disparate systems together. That’s the only way you can really be successful in providing something like integration as a service and a cloud-like environment. You have to be completely open.

Gardner: It sounds as if we've been able to capture the best of both worlds, with FuseSource being based on mature Apache software projects with the model around the FuseSource support, which is several years old and very well demonstrated in the market. But now that you are autonomous, you're also getting the benefits of being a startup, of being innovative, being able to move, being fleet, being able to be agile.

Debbie, is that a fair characterization? By going autonomous with FuseSource, you're getting the best of a mature, established mission-critical enterprise supplier, but also, you're able to move quickly in a rather dramatically changing market.

Best of both worlds

Moynihan: Definitely. We're really excited about it. Definitely being backed by Progress Software provides us the benefit that customers can have that assurance that we're backed by a large organization. But, having FuseSource as standalone company, as you said, gives us that independence around decision making and really being like a startup.

Sometimes, we get ideas, we want to make it happen, and we can make it happen. We can make it happen, the same day or the next day. We'll be able to move as quickly as we want. And, we'll be able to have our own processes in any functional area that we need to best meet the needs of the open source users.

Gardner: Rob, from a technical perspective, how do you view this best-of-both-worlds benefit?

Davies: From a technical perspective, it’s really good for us. The shackles are off. There’s a lot of suddenly reinvigorating that seems to move forward. We've got a lot of really good ideas that we want to push out and roll out over the coming year, particularly enhancing of the products we already have, but also moving onto new areas.

There's a big excitement, like you would expect when you have got a startup. It just feels like a startup mentality. People are very passionate about what they're doing inside FuseSource.

Because those shackles have been taken away, it means that we can actually start innovating more in the direction we really want to drive our software too. It’s really good.



It's even more so, now that we have become autonomous of Progress. Not that working inside Progress was a bad thing, but we were constrained by some of the rigors and procedures that you have to go through when you are part of a larger organization. Because those shackles have been taken away, it means that we can actually start innovating more in the direction we really want to drive our software too. It’s really good.

Gardner: Well, great. How can people learn more about FuseSource? You said earlier Debbie that you have a website that’s been refreshed. Are there some URLs or directions that you would point people to in order to learn more?

Moynihan: Yes, I would point people to FuseSource.com. They can always contact us directly as well. Rob and I would be happy to speak with anyone that has questions. You can send an email to info@fusesource.com and we would love to talk with anyone that has any questions or wants to hear more about it. FuseSource.com is the place to get information on the web. We have a Twitter account, twitter.com/fusenews, that you can follow as well.

Gardner: I want to thank you both. We have been discussing how a newly autonomous FuseSource is evolving to meet the need for open source infrastructure in a rapidly changing marketplace, and of course in an environment where cost and low risk are all very much top of mind.

So, thanks again to Debbie Moynihan, Director of Marketing for FuseSource. Thanks, Debbie.

Moynihan: Thank you, Dana.

Gardner: And also, Rob Davies, Director of Engineering for FuseSource. Appreciate your joining us, Rob.

Davies: No problem. Good to speak to you, Dana.

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

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: FuseSource.

Transcript of a sponsored podcast discussion on the status and direction of FuseSource, which is being given its own corporate identity by Progress Software. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

Wednesday, September 17, 2008

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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