Rapidly Evolving IT Trends Make Open, Agile App Integration More Important Than Ever

Transcript of a sponsored BriefingsDirect podcast on the maturing of open source integration software and its role in making enterprises responsive to a rapidly changing IT landscape.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Register for CamelOne. 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 how enterprise integration requirements are rapidly shifting to accommodate such trends as cloud computing, mobile devices' explosion, and increased demand for extended enterprise business processes.

Application-to-application integration inside an enterprise's four walls is well understood, but very quickly the demands placed on integration are spanning multiple enterprises, multiple types of applications, and varieties of service providers. Software as a service (SaaS) and cloud computing are joining with legacy systems to form new and varied hybrid models that require whole new sets of integration needs and challenges.

Once these newer breeds of integrations are set up, can the old, brittle management and upkeep of them suffice -- or will agility and rapid upgrades and innovations require new tools to make integration a lifecycle function with ongoing management and more automated governance?

In this discussion, we'll examine how open-source integration projects like Apache Camel and lightweight integration implementations and graphical tools are making developers and architects more agile. At the same time, these open-source approaches are proving less vulnerable to the complexity, fragility, and cost that often plague aging commercial middleware integration products. [Learn more about the CamelOne conference May 24 in Washington, DC.]

Here to examine the new need for open and agile integration capabilities is Rob Davies, Chief Technology Officer at FuseSource. Welcome, Rob.

Rob Davies: Hi, Dana. Good to be here.

Gardner: We're also here with Debbie Moynihan, Vice President of Marketing at FuseSource. Hello, Debbie.

Debbie Moynihan: Hi, Dana.

Gardner: Debbie, what's going on out there? Why are things happening so rapidly? Why do people need to rethink integration?

Many challenges

Moynihan: Dana, there are so many things happening out there -- integration, in particular. There are so many challenges right now. The business models are changing and people are being asked to do more with less. Teams and applications are more distributed than they have ever been.

There are a lot of new technologies coming out that people are struggling to learn about, and figuring out how to incorporate them into their infrastructure: cloud, mobile, the explosion of the huge amounts of data that enterprises are trying to understand and make sense out of. Not to mention the social media technologies that people are being asked about and wondering how to incorporate into their enterprise infrastructure.

There are a lot of different skills that people are looking to have that they've never been asked to have before. More and more people are being asked to perform IT tasks. It isn’t just highly skilled developers, but also business analysts and people who have never done integration before are being asked to do integration activities.

A lot of people are looking for solutions and ideas. They're not sure how to keep up with all of these changes. Costs are a problem because essentially everyone has the same or smaller budget going forward and a lot of people have fewer people to do what they've been doing before.

People are challenged. I think open source is a great solution. At FuseSource, we've seen a lot people looking more and more to open source to solve some of these problems.

The reason why open source is a good solution is that with open source there's a lot of flexibility. When the environment changes and new technologies come out, you need to integrate new things into your environment.

The community people, when they see a problem or new technology, just make it happen. They can add, expand, and modify what's involved in the various open-source integration projects without the overhead and bureaucracy of some of the traditional software development environments.

Gardner: Debbie, in the past, when we had a shift in computing, we'd bring in a new set of applications, we'd update our platforms, and then think about integrating them. It was a sequential process and it could take three to five years to go through something like that.

We don’t really have that luxury anymore. Now things are happening in a simultaneous fashion. So integration really can't be an afterthought, but needs to be part and parcel with how you go about designing and implementing your applications.

Doesn’t open source, in a sense, allow for a compression of the time that we’ve traditionally taken with commercial products?

Moynihan: Absolutely. Open-source is a componentized, lightweight approach. As people develop their applications, they develop them in such a way that they can be broken apart in new and different ways down the road, and it's very transparent. It makes it easier over time to further integrate what you’ve built and to make changes as you need.

Gardner: Rob Davies, let's dive a little deeper into this notion of open and agile integration capabilities. What's wrong with simply going into traditional, commercial integration capabilities and somehow broadening them into this new domain? Is it not something that can be extended?

The pace of change

Davies: I think it is, but I think the real crux of the problem goes back to what Debbie was talking about earlier -- the pace of change. If you’ve got an open-source framework, you can actually have an insight into how the project works.

After we launched Apache Camel at the Apache Software Foundation, we provided a number of default integration components for Camel. But, as soon as they got out there and the community started to use them and saw the benefits of using them, we saw no end of contributions. People contributed adapters to weird and wonderful systems, and contributed them right back into the Apache project. [Learn more about the CamelOne conference May 24 in Washington, DC.]

Then we’ve got other components that people use to automate open-source but not at Apache. A number of components have grown rapidly since the inception of a project. When we started, we had probably 20 components, and now it's well over 100. Those are the ones we know about, the ones that people have open-sourced.

We know from our customers that they’ve got specific needs. They’ve got legacy applications. Because we've gone to the effort of making sure that it's very easy to add a new component into Apache Camel, it's very straightforward for someone to add in extra functionality.

For example, if you want to write a component for legacy mainframe application, you could very easily do in a matter of hours. The old approach would take you weeks, months, maybe even years, especially if you don’t have access to the source code. So, you’ve got that added flexibility.

The fact that it's an open-source project at Apache means that there is a vibrant community of users and developers.

The fact that it's an open-source project at Apache means that there is a vibrant community of users and developers. You can get feedback instantly, if you’ve got issues and problems. Of course, if you want professional help, there’s FuseSource as well. We have our own community at fusesource.com. So, all these things combined means that you have more flexibility and a much more agile way of doing integration.

Gardner: You know it strikes me that when we begin to talk about integration that I’d mentioned service-oriented architecture (SOA), but that was sort of yesterday’s buzzword. We're now into cloud, hybrid, and mobile. But, from an architectural perspective, you can't really scale and leverage these open components without that proper underpinning, typically an enterprise-service-bus (ESB) architecture.

Rob, help me understand why doing this correctly from an architecture (not just an open-source) perspective is really important as well.

Davies: You hit the core things about the SOA and the ESB architectures. We see where people are using, in particular, Apache Camel and some of our other open-source projects. They want flexibility there. So, they want to leverage a service bus, put things on, expose them as service, and expose them over the service bus, which uses different transports to enable that bus, be that messaging, HTTP, or whatever other means you want to use.

Application integration

At the same time, you also want to have the flexibility now to do it in application integration. You want to have that flexibility for some services and you very much need that enterprise service bus in place. But for other cases, you want to be able to do that more locally, where the integration points are.

The approach that we have is that we enable you to do both, because you can embed Apache Camel inside an application server, if you want it inside your application itself. If you want to use it in a more traditional sense, you can deploy it into ServiceMix. You can define your apps easily, deploy them into ServiceMix, and use it to manage the container.

Having that flexibility as well means that you can have the right architecture for your particular solution. If you look at how people would do the integration before, they’d have to get an ESB, and that would force the whole architecture of how they do things. When you’ve got more flexibility, it means that you can make the right architecture choices that you need, and you're not constrained to one particular style of integration.

Gardner: I'm facing a lot of questions more recently about how to cross the domains that we've mentioned -- SaaS, cloud, on-premises, traditional architecture, and private cloud architecture.

Does the service-bus approach and the open-source approach also give us some sort of a path or vision for how to go about this? I think we're just starting to enter into how to integrate my legacy applications with cloud or SaaS applications in a meaningful way? What are your thoughts about that, Rob?

You can only really get that speed of innovation to keep up with the way the environment is changing by choosing open source.

Davies: I completely agree. Having open source enables you to have the insight into how the integration application works. But more importantly, those environments are changing very rapidly.

If you just look back just a couple of years, when people were starting to use the cloud, they weren’t even thinking about having hybrid clouds. Now, we're seeing more and more people, more of our customers, looking to hybrid clouds and have a private cloud for applications.

When they need the capacity, obviously they can get that capacity in a public cloud. But, to have all those PCs working together seamlessly, they need the agility that you get from an integration solution that can be deployed on a public cloud, locally, or a combination of both. That’s something that you can only get from software that has evolved at the same pace as the demands of the environment.

You can only really get that speed of innovation to keep up with the way the environment is changing by choosing open source, because the open-source community itself is driving the projects to keep up with the demands.

So, you have to try to move outside of a traditional release cycle that you would get from a traditional product company. You don’t really have any other alternatives, if you want to keep up, than to look at open-source projects, the Apache ones in particular. [Learn more about the CamelOne conference May 24 in Washington, DC.]

Apache projects certainly hit the right notes in that you've got both very business-friendly license from the Apache license and very active communities, and you’ve got diversity in that community. You know these projects are going to live beyond the lifetime of particular individuals on the projects.

Support and consultancy

You also have the benefit of having companies like FuseSource, which created the projects in the first place, and who are there and able to provide support and consultancy if you need it. You get the best of having a dynamic community, a dynamic project, and you also get the security of having professional company to back it up.

Gardner: I'd like to revisit that thought about the traditional upgrade path in the product cycle. Many organizations have faced two stages of this. One is to wait for the commercial vendor, to come out with the upgrade or often, an association with larger projects that they have across different platforms, brings in various versions and iterations that they've done.

It's a fairly complex undertaking for the vendor, but then there is the complexity of them bringing that into your organization, and there's cost, because you have the upfront licensing cos. Many times, you’ll incur hardware cost and many times you want to have cohabitation of your older deployments, as well as new ones that come online. This is sometimes a three- to five-year process.

Tell me why an open-source approach and, from a cost perspective, that upgrade path is much different.

Davies: Because it’s open source. The projects that we are involved in Apache are Apache licensed. ActiveMQ, which is a message bus, Camel, ServiceMix, and CXF, are Apache licensed. It means that you don't have to pay the license costs upfront.

The problem that organizations are facing now is that the environments that they can deploy into and have to interface with are changing and evolving so quickly.

You're actually right about the time of the release cycle for a traditional product company. The problem that organizations are facing now is that the environments that they can deploy into and have to interface with are changing and evolving so quickly. You just can't have a luxury waiting for a three- to five-year release cycle.

And what often happens is that the software you are trying to integrate with is really out of date and people have moved onto something else. So, up front, you have to look at what you can use to integrate with these systems as they evolve. Things are evolving more quickly over time. There are different sorts of social networks that you have to interface with, and that market has been very dynamic over the last few years.

Twitter has been around for a few years, but we see people using Twitter as asynchronous communication within their organizations to give out real-time information updates. So, that’s important. Who knows what's going to be just around the corner, because things have evolved very quickly.

If you want your organization to keep pace with the changing environment we're in, you have to look for the right integration solutions right now, and choose the ones that will be able to keep pace.

Gardner: How rapidly are the iterations within the Apache project, within Camel in particular, happening? How rapidly is innovation taking place?

Very fast pace

Davies: It’s happening at a very fast pace. When we do release these out of Apache, it's typically every three months, but in that three month period there could be other components that have gone into the Apache Camel Framework. Because it's open source, people can actually look about, release their own components into an open-source environment, or develop them separately without necessarily releasing to Apache, just to get the functionality out.

That pace of change is very fast and it’s near real time. When the need comes up, within a few days or a week, you would probably find someone who has already written that integration component that you need and it’s available.

Gardner: This is, of course, a global community. You have a great number of different inputs and parties involved, different locations that are supported, and different localizations, and languages.

Davies: Absolutely. That’s another benefit of having an open-source, and a well-known open-source, community to drive our innovation and to back it up.

Gardner: Debbie, let's go look at what's happening in the community. I understand you have a conference that’s coming up May 24, a first of its kind. Why is this a good time to be pulling together the Camel Community, and what you’re going to do?

The nice thing about Camel is that it provides a basic foundation and a terminology of well-defined patterns.

Moynihan: We’re really excited. We have an event coming up in May. It’s called CamelOne and the reason why we focused on Camel with the name of the event, is that it’s actually an event for open-source integration and messaging overall. It’s because Camel is a really great way for people to get started, and it’s also a great way for more advanced integration developers as well. It brings together the entire community.

Rob was talking about earlier about how there is always these new technologies coming up and people can add components. The nice thing about Camel is that it provides a basic foundation and a terminology of well-defined patterns. The integration patterns themselves are very well-defined, but what's happening is all the different ways in which you connect and what you are connecting to have been changing and evolving over time.

Camel is a great foundation and CamelOne is an event to bring together users of Camel and other open-source integration and messaging technologies to learn more about Camel, open-source messaging like ActiveMQ, and ESBs like Apache ServiceMix.

You were talking earlier about cost savings. More and more people are being asked to do integration. The nice thing about Camel and about these other technologies is some people maybe just only needed to do lightweight integration. They can just learn how to use Camel and learn the basics.

Other people are going to be doing more in-depth management of many integration patterns and they may need to know all the nuances of an ESB platform. The focus of CamelOne is to bring people together to understand, learn about, and meet each other and to grow this community of open-source integration users.

Gardner: So, this is CamelOne, May 24, in the Washington D.C. area. Why Washington D.C.? Is there a lot of this going on in the public sector?

Central location

Moynihan: Actually, we do have a lot of users in the Washington D.C. area. We also thought that was a central location, where people could come from not only anywhere in the US but also from other regions of the world as well. There are a lot of direct flights to that location. But, we do have a lot of users in the area. For example, the Federal Aviation Administration (FAA) is going to be speaking and they have selected open-source integration for the next generation of their services infrastructure.

Since they connect with a lot of other agencies, there is a lot of interest in learning more specifically about that program and about the technologies that it's built upon, because a lot of other agencies need to connect.

Gardner: One of the other aspects of this that I'm seeing in the market is that more people need to take part in integration. It can't just go through a bottleneck of "beard-and-sneaker guys" in the back room who can do coding. Integration needs to be part and parcel with process innovation. That means we need to elevate it out to a wider group of individuals, maybe as many as possible that are on the front lines of process innovation and analysis.

The addition of tooling is going to help broaden how many people can do integration, and we're real excited.

What's being done about the integration that we've been describing? It’s wonderful that we have the open source and we have the cost benefits, but how about bringing this to a larger class of individuals, Debbie?

Moynihan: On April 11, we announced the general availability of a new graphical tooling for Apache Camel. [Users can download a trial version of the plug-in, which includes some of the functionality of the fully paid version found on the subscription-based Fuse Mediation Router.]

The addition of graphical tooling makes it easier for more people to do integration development. They don't have to write code. They can use a drag-and-drop environment to select the integration patterns that they want to implement, and the software will implement them. They can test them and deploy them into production as well.

The addition of tooling is going to help broaden how many people can do integration, and we're real excited. We've been doing a beta program since the end of January with over 500 participants. Rob mentioned the breadth of all the components and how hot Apache Camel has been. We're not surprised that more and more people want to use it. So, the idea of having tooling on top of it is really attractive to users.

Gardner: So, what's the name and where do you go to find out more about them?

Moynihan: The Fuse IDE for Camel is the name. It plugs into an Eclipse environment and you can get it at fusesource.com.

Gardner: And how about more information on CamelOne? It’s simple, I suppose search on CamelOne will get you there.

Moynihan: Yes, camelone.com is the website as well.

Gardner: Now, you guys have been involved with a series of books and you have something new coming out in that series. Tell me about that.

Camel in Action

Moynihan: There are a couple of books that recently have come out. One is Camel in Action, which is fantastic for people who want to get going with Camel and learn how to use and deploy it. Rob is coauthor of the ActiveMQ in Action book, which has come out in print recently from Manning Publications.

Davies: ActiveMQ in Action is really a scripted book, which goes through all the different use cases of using ActiveMQ, right from getting started and what messaging is about. It walks you through different deployment options, all the way up through using clusters of ActiveMQ brokers, to using ActiveMQ as a wide area network, so you can connect geographically dispersed locations.

It shows you how to tune the performance of ActiveMQ and get the best out of it. So it's very comprehensive book about how to use ActiveMQ. It's somewhat complementary to Camel in Action as well, which goes through all the different patterns you can use.

It doesn't talk about using Camel. It talks about integration patterns as well and then describes how you can use those using Apache Camel, and you can use Apache Camel with ActiveMQ. ActiveMQ also can embed Apache Camel. So, you have routes running inside the broker from Camel. The two of them are very complementary.

Gardner: Let's step back for a wider perspective. I'm seeing that the need for integration is increasing. The things that need to be integrated are increasing, perhaps exponentially. The pace at which that needs to take place is very rapid and dramatic, compared to the history of computing. Open source is well established. We’ve seen many different organizations embracing this. We saw Red Hat come out recently with some very strong growth figures.

It's coming to the point where organizations won’t have a choice other than to use open source as a way to try to keep up with a pace of change.

So, it seems to me that open source is a very mature approach now, not something that’s a new kid on the block, by any stretch. When you put these factors together and when you look at the need for integration as a service within applications from the start -- not something you bolt on or think about after the fact but actually build applications for, of, and by integration capabilities -- this perhaps spells a historic shift.

Maybe we could riff on the future or even look at this from an abstract or even philosophical perspective. Rob, are we at a shift here where the ability to integrate becomes an essential character of businesses?

Davies: We probably are at that shift right now. Sometimes, it's difficult to see things happening like that, if you’re actually right inside in the middle of it. But, if you look at the way the environments change, you’ve got to actually be running your compute resources.

We’ve talked about cloud environment. Also there’s social network, SaaS, and mobile devices, and you need to link all those together. It's coming to the point where organizations won’t have a choice other than to use open source as a way to try to keep up with a pace of change.

We're probably at a point now, where we’re going to see that the traditional model of providing software is going to dwindle over time, probably pretty rapidly as well, as organizations realize that they need the flexibility and the ability to change what they’re doing very quickly.

Future-proofing applications

It's a really good point that you made. You have to start thinking about how you're going to future-proof your applications right from the beginning to adapt to changes in their environments. You have to architect in how you’re going to integrate and future-proof your applications, because it does get more costly if you do it as an afterthought.

Gardner: Many of the SaaS providers are doing multitenancy and providing applications as services on demand at a very attractive and aggressive price point. They're leveraging open source on the back end, I have to imagine. Do you have any insight into what the service providers themselves are building with?

Davies: Most applications now, in particular on the cloud, are using open source at the back end. We can't give you any specific details of vendors that are doing that, but I know they're using open-source projects, and not just the SaaS vendors, but some of the other existing product vendors use open-source as well to enable their products.

We certainly see open-source as definitely mainstream now, and we’ve seen it has been the first choice that people use for building any kind of application or service they’re providing. It's more a case of people asking the questions now of not should we be using open source, but why shouldn’t we use open source? It's starting to become a first choice for people to go to.

Gardner: Let's look at some of the ways in which those people are making that choice. Debbie, you mentioned the FAA. Are there other organizations that you can point to and say, either by name or by use case scenario, that they’ve taken this leap, they’ve made those choices, they’ve embraced some of the new requirements around integration, and they have some positive proof points? Any examples that we can look to?

It’s more dynamic and flexible, and being involved with the community is really exciting.

Moynihan: Sure. Sabre is one of our customers. Sabre Holdings is using the FuseSource open-source software, and they started using open-source software many years ago. Years ago, a lot of people chose it because they were looking at cost and flexibility. Now, they're seeing that you actually were getting more features faster in open source than you were getting in traditional software. It’s more dynamic and flexible, and being involved with the community is really exciting.

One of the things that Sabre has done with open-source software is a travel gateway. They connect to many different airline technologies and travel agencies and they have over one-and-a-half billion transactions running through their infrastructure on any given day. They've been using FuseSource open-source software for over a couple of years with zero downtime.

Being able to use open-source, they have that flexibility, have the interaction with the community, and also have high-performance and reliability.

People are getting all of the traditional benefits of high-quality software, but also that dynamic ability to get new features, to get new technologies, to get bugs fixed, for example, really quickly with the community. With support vendors like FuseSource providing subscription so that they can have access to the engineers directly who are working on these projects, they can quickly get turnaround and get what they need to make those dynamic changes in their business.

Retail industry

Another area that we are seeing a lot of people look at open source is in the retail industry. Earlier on, people were looking for cost savings. If you think about retail, it’s common for retailers to have a lot of locations, whether it’s franchises or stores. Using open-source, you can save a lot of cost on your IT footprint in those locations.

Specsavers is one of our customers. They're deploying open-source to over 1,000 retail stores. We're seeing more and more retailers looking at open-source to be able to do that. They're going to get all the flexibility of being able to incorporate these new technologies as we incorporate them into the open-source projects really quickly. But, right from the get-go, they have reduced costs, flexibility and the involvement within the open-source community and directly with the development teams through working with vendors like FuseSource that support the open-source communities.

Gardner: For folks who are looking to ramp up their adoption of open-source integration, are there some resources that they should be aware of in terms of getting started?

Moynihan: I would encourage people, specifically if they are looking at open-source integration and messaging, Apache Camel is a good place to get started. We have a productized distribution at fusesource.com as well.

I would encourage people, specifically if they are looking at open-source integration and messaging, Apache Camel is a good place to get started.

The reason why I suggest Apache Camel is that it's is based on the enterprise integration patterns book and provides a nice foundation and definition around some of the most commonly used integration patterns. It’s a great way to get started.

People could obviously come to CamelOne, which is going to be really exciting, meet a lot of the people who are experts in the community, and meet other users of open-source integration messaging software.

Also on our website fusesource.com, we have a lot of webinars, which are happening live on a regular basis. We have a lot of archived webinars, which actually walk you through technical tutorials on how to get started with these various open-source projects.

So I’d highly recommend to check that out and to check out the books that we've mentioned and the documentation on our site as well.

Gardner: Very good. We have been talking about how enterprise integration requirements are rapidly shifting in order to accommodate such general and global trends as cloud computing, mobile device use explosion, and the increase demand for extended enterprise business processes.

I want to thank our guests, Rob Davies, Chief Technology Officer at FuseSource. Thanks a lot, Rob.

Davies: Thank you very much, Dana.

Gardner: And Debbie Moynihan, Vice President of Marketing at FuseSource. Thanks, Debbie.

Moynihan: Thank you, Dana.

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

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

Transcript of a sponsored BriefingsDirect podcast on the maturing of open source integration software and its role in making enterprises responsive to a rapidly changing IT landscape. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• FuseSource Gains New Autonomy to Focus on OSS Infrastructure Model, Apache Community Innovation, Cloud Opportunities
• Apache Camel Addresses Need for Discrete Infrastructure for Services Mediation and Routing
• Apache CXF: Where it's Been and What the Future Holds for Web Services Frameworks
• Workday Integration Cloud debut raises bar on integration as service, deeply ingrains integration as apps function
  

Case Study: How Fairchild Semiconductor Has Leveraged the Workday Integration Cloud

Edited transcript of a BriefingsDirect podcast on new forms of cloud-based integration and its use in enterprise business processes.

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

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 how new forms of cloud-based integration are helping a major high-tech company build new relationships among and between extended enterprise business processes.

We'll examine how Fairchild Semiconductor has been an early adopter of integration platform as a service (iPaaS). The venerable Silicon Valley company has been using graphical tools to build integrations among and between far-flung applications and services but with those integration platforms housed in a newly unveiled Workday Integration Cloud. [Disclosure: Workday is a sponsor of BriefingsDirect podcasts.]

We’ll learn here from the chief technology officer at Workday on what the integration cloud approach can do and how it points to a future in which broad integration capabilities are increasingly built into software-as-a-service (SaaS) applications.

This cloud-based integration model will prove far less vulnerable to the complexity, fragility and cost that plagues traditional on-premises middleware integration methods. It should also spur the evolution of services ecosystems among multiple business service providers and application providers.

So here to dig into what makes integration as a service (IaaS) tick and what it means for the future is Paul Lones, Senior Vice President for Information Technology at Fairchild Semiconductor. Welcome, Paul.

Paul Lones: Thank you.

Gardner: We’re also here with Stan Swete, the Chief Technology Officer at Workday. Welcome back, Stan.

Stan Swete: Thanks, Dana.

Gardner: Let me start with you, Paul. What's the problem now with integration? Why is this different than a few years ago? Why is it that we need to adopt a different take on integration?

Lones: For companies like Fairchild that are really trying to take advantage of some of the new capabilities that SaaS providers are offering and put together a broader group of applications, integrations are a new challenge, a broader challenge than they have been traditionally.

Gardner: And what is it about what Workday is doing as an application provider that makes this interesting -- the human resource management, the human resource (HR), equation. We’ve seen integrations in some other service orientations, such as in the supply chain side of things. Why was this a challenge?

Custom integration

Lones: Traditionally, in the HR arena, there has been no such thing as a standard integration. Every benefit provider, every payroll service provider that you want to work with requires a custom integration. That’s always been true, and having the set of tools that we now have at our disposal makes that a lot easier.

Gardner: So, in a sense, the HR ecosystem challenge is a really good place to try to perfect or advance iPaaS. Do you agree with that?

Lones: Absolutely.

Gardner: Stan, let's go to you. What needed to change and when you looked at this issue of your ecosystem and how it tied things together, what sort of requirements did you have for integration that now you can pass along to your customers?

Swete: We still look at it as having the same requirements for enterprise integration. Especially for hub systems like human capital management, there are ton of other systems that you have to integrate with. So the requirements are daunting and are still there. It's been the same for a while at enterprise software.

What we see as being a cloud vendor, a SaaS vendor, is just new opportunities to leverage the SaaS model to do integration a little bit differently, have the application vendor take on more of the ownership of the integration issue and use the fact that we've got all of our customers running on a single version of the product to tie some integration logic to that and bring more control and stability to that integration for our customers and our partners.

Gardner: Why is it, Stan, that the traditional systems, platforms, and middleware that are in place are not up to this task? Why not just turn the switch on your on-premises integrations and start tying together these cloud and SaaS based services?

Swete: There's just a split today between the technologies and the platforms that are used to execute integration and convey data and then the application’s endpoints that are involved with and tied up in the logic of that integration.

It's not that no one is up to it, but it's just that that gap splits responsibilities where maybe they don’t have to be split. What we’re trying to do is marry it, use what we know about our applications to create integration logic, and then embed technology that hasn’t been embedded with applications before to help with the delivery of that.

That hasn't replaced every single kind of middleware technology that you need. You still need a middleware technology behind your firewall. You still need specialized middleware technology in the cloud to do things that it does best. But, for the application-centric part of integration, application vendors can do more.

Gardner: Paul, at Fairchild, you've adopted a number of SaaS system approaches or services approaches. One of them is Workday. You have mentioned a few others to me earlier. When you look at your ability to absorb and adopt and exploit more SaaS, how does integration fit into that? Is this something that needs to be solved in order for you to proceed?

Critical enabler

Lones: It's a critical enabler to take advantage of some of the capabilities that we see are available to us and can help us in our business. We look for two things. One, we want to find a supplier that thinks of this in a more holistic ecosystem-like way, and that has a series of application-level partners, that we can add to our overall architecture and overall application capability.

In addition to that, we look for good integration tools, because even beyond those partnerships, we still have to do a lot of integration work.

Gardner: And how long has Fairchild been using Workday for their human capital management activities?

Lones: We've just recently gone live with Workday and several of their partners and have completely transformed our human capital management landscape with Fairchild.

Gardner: When you started to do this, I would think that that involved a number of integration points. Perhaps you could share how that works and then we would like to hear more from Workday about why their Workday Integration Cloud announcement has come to up to the bat to start swinging at this problem.

Lones: Sure. For the Workday partners who I was talking about earlier, those integrations are handled between Workday and their partner, which reduced our integration burden. We don't have to maintain those, as both of those applications continue to improve. In addition to that, we've built 28 application integrations ourselves, largely to benefit service providers and payroll service providers around the world.

Gardner: And you were using your tools or leveraging some of the investments you have made? How did you build those integrations?

Lones: We were fortunate enough that we were able to get some early access to the toolset that Workday is now making available to their broader customer and partner base.

I had a small team of IT staff that was completely unfamiliar with Workday when they first started, and we put them to work on these integrations. We were able to complete these 28 integrations in less than 120 days, which I think was pretty good performance.

Gardner: Just for comparison sake, how long would that perhaps taken in a traditional enterprise application integration (EAI) environment?

Lones: I wouldn't want to necessarily put a date on that. We do know that from an overall project implementation perspective that an on-premises application typically will take 2-3 times as long to execute, and I'd expect that the integration piece would have a similar scaling.

Gardner: Alright. Well, let's dig in a little bit more with the announcement recently that Workday made -- something called the Workday Integration Cloud. Stan, give us the top-down understanding of what this is about.

Important components

Swete: The Workday Integration Cloud is an extension of Workday's cloud that we use to host and process our on-demand applications and it has several really important components. One is a platform component. The tools that Paul mentioned that they used to build integrations, up until today, have been there for Workday developers. The announcement makes these tools fully available to Workday customers and to Workday partners.

In addition to the tools, there is a rich enterprise service bus (ESB) execution environment that runs the results of these developmental tools. We offer not only the tools to build integration systems but the execution environment for the integration systems. And then we've a set of scheduling and monitoring tools that our customers can use to directly schedule and monitor the execution of their integrations.

So those three things taken together form the platform, that's part of the integration cloud. The resulting integration systems we also consider a part of the cloud. Workday for some time has been building what we call Packaged Integrations and Connectors. We have a library of those that we can make available to our customers.

Fairchild has used some of these. These integrations are built with our tooling by us and for our customers. Packaged integrations really just look like another Workday product, but they handle both ends of the integration challenge.

We also have connectors that handle our end of it but build logic out. The main example is a payroll interface product that lets our customers, gives our customers a starting point for hooking up Workday human capital management to the variety of international payrolls many of our larger customers have.

This is very solid ESB technology, well thought of by the engineering talent that we now own.

Packaged integrations from Workday is another component of the Integration Cloud and the final one is just the body of integrations that our customers and partners create.

These are the intellectual property of our customers and our partners. Workday does facilitate sharing of those definitions if the customer and partners are interested, but there is that growing body of application as well. Those things taken together are the Workday Integration Cloud.

Gardner: And just to be clear, this is designed for your customers. This isn't just a general purpose integration service that you are opening up writ large. This is about your ecosystem and your customers, is that right?

Swete: The beauty of it is that it's based on middleware from a company formerly called Cape Clear that Workday acquired three years ago. I think that's very important to mention that. So it's not like we, an apps vendor, just did our take on an ESB. This is very solid ESB technology, well thought of by the engineering talent that we now own.

Built-in integration

We're taking this technology and integrating it into our applications, building integration into our applications as the way we refer to it, and then making the combined product available to both our customers and our partners. The partners are the equally important point. Systems integration partners from Workday can get access to these tools and this platform.

Gardner: And how about the pricing. Is this something that you would just check a box off and get a different bill for? How does this relate to the existing suite of application services you providing?

Swete: The Workday Integration Cloud platform is being made available at no additional cost to Workday customers and Workday partners. We make our money selling our application services.

Gardner: I'm intrigued by this notion of making integration part of the application. I think the history of this, Paul, has been that over the years, new applications and platforms, and even models of computing would come along. You would get great productivity from the application, you would buy and install and master the platform, and then you would be faced with an integration problem.

This is happened over and over again. We've seen it with mainframes to client-server and then into multi-tier and distributing computing and then ultimately with web and now cloud computing.

Companies like ours and many companies working on this are moving from a monolithic internal application orientation to one that's more of a hybrid model.

Given that integration has been a bolt-on, something that's been delivered after they shift in an application model, why now change? Why is integration and the application coming together now?

Lones: Part of it is that our approach to overall enterprise architecture is changing. Companies like ours and many companies working on this are moving from a monolithic internal application orientation to one that's more of a hybrid model, where we want to really take advantage of the new capabilities and the quicker pace of development and deployment of improvements that SaaS providers offer.

Therefore, integrations naturally become a critical part of that, because the number of applications that we use in our business increases somewhat with this sort of approach.

Gardner: Same question to you, Stan. Why this need to bring an application and its integration features together?

Swete: The challenge here is that the requirements in the large problem of integration haven't changed, and there have been a lot of tools developed to address the issue. Some results have been achieved, but I don't think anyone is satisfied with how maintainable enterprise integration is. And, we happened to think the answer is to build more robust integration where the integration definitions themselves are more informed by what exists and what's changing in the application.

Hub system

That's the opportunity that we were seeing. We came on to it by just being the provider of an application that is going to be the hub system and be hooked up to a lot of different systems.

We knew that integration was going to be front and center for us as a brand new SaaS vendor six years ago. One of the differences we wanted to make was to do more about the problem. So, we started with an investment of technology.

Where that has led us is really tying what can get done with integration technology to what applications know about, everything from their security model to, in our case, we leverage a lot the fact that we know about people and how they are organized. So, we're able to have integration definitions that can get routed around for the appropriate approvals before certain steps happen.

That’s unique, but it's breaking down the separation between integration that would be built by one side of the company and tying it back to who it's really serving, the other side of the company.

For payroll integration, the payroll admin can be hooked into the fact that a major feed of HR data is going out to a payroll system and they can get a check on that before it happens. That’s something we’ve built in and we’ll continue to look for those opportunities. I still think it's actually early days for what our integration tools can leverage inside the application.

You still have to have experts on integration middleware and we have that, but the real benefit we think comes from blurring the distinction and marrying these things together.

Gardner: So, the system of record for HR and the governance and policies about employees and their roles in the organization can now be applied pretty seamlessly to who gets to do integrations and/or how integrations as part of a business process would work. Am I reading that right?

Swete: Yeah, how they get executed, how they get approved is all built in to the same sort of system that you use to schedule a report or any other thing you’d do in your application. For us, it's just an extension of the application, rather than a hard line and then some integration technology that no one on the app side understands.

There still are differences. You still have to have experts on integration middleware and we have that, but the real benefit we think comes from blurring the distinction and marrying these things together.

Gardner: So you mentioned some tools and Paul mentioned very compelling timeframe for creating 28 integrations. Who are the people who use these tools typically and are they same old software engineers that were building EAI connections, or is this a wider group of people? Who can take advantage of this tool capability?

Swete: We’ve taken the approach of splitting the development tools into a framework that is more geared for developing simple integrations, as we call them. This is one-way data in or one-way data out of Workday to third-party systems, and we have a tool called the Enterprise Interface Builder (EIB) that is a non-programmer could use. You still need to know that you are sending something to a secure FTP location, but you don’t have to be a developer.

Sets of choices

We give you a graphical user interface, we give you a selected set of choices for how you can source data, a selected set of choices for how you can transform it, and a select set of choices for how you can deliver it. You can save that, and then you have a definition that you can then schedule on a recurring basis. That’s built for non-developers.

The other tool that we have has a completely different personality. It's what we call Workday Studio. This is the developer tool that we have used to build our integrations, and it is now available for our customers. But, on this one, you want to be a developer. You're not doing programming, but you are working in an Eclipse-based framework with detailed control over integration components and orchestration of how data flows. So, this is a technical development tool.

The thing it creates is the same thing that the EIB creates, an integration system that can then be executed in Workday, but the creation of it is much more technical.

Lones: Along those lines, this is really a marriage between having a strong, skilled team of developers with a great tool set. So, it's not a substitute for having well-skilled staff in the IT organization.

Gardner: What about the idea here that integration can be better and newly leveraged because we’ve solved with a SaaS provider’s multitenancy architecture some of these thorny and complex issues about version heterogeneity within the organization?

A lot of times companies might want to update an application, but fear breaking or disrupting integrations. That integration in the traditional sense can become an impediment to the advancement of features and functions in applications.

A lot of times companies might want to update an application, but fear breaking or disrupting integrations. That integration in the traditional sense can become an impediment to the advancement of features and functions in applications.

Paul, did it occur to you that the multitenancy, the fact that everyone is on the same version of this app and that all the integrations follow through by virtue of the responsibility of the vendor, not the user, that that’s sort of added bonus. How have you recognized that and what does it mean to you?

Lones: It's an important part of thinking about the use of SaaS applications in a company like Fairchild. To the extent that it's easy to maintain those integrations through the improvement cycle, we are going to be much more willing to follow a SaaS model, because upgrades come every three or four months, depending on who the supplier is.

We like that model. We'd much rather have a small incremental improvement every three or four months than have this huge disruptive step function upgrade. Really, it typically is more like a reinstallation that occurs for large monolithic installed applications every two or three years. You need to have your integrations keep up, and that's an important consideration.

Gardner: So it's interesting, Stan. You have a user like Fairchild, using these tools, building these integrations, moving more towards a multiparty ecosystem process-oriented benefit, but the responsibility on those integrations is with you.

It seems as if you're really giving an awful lot here. How can you do that with a strong sense of confidence? Isn't there a risk that if these integrations start breaking that you are in the catbird seat?

Levels of the game

Swete: Yeah, well, there are levels of the game for how you can leverage the support you get out of the core application that we keep moving forward. One level of the game is for us that's very important in the integrations we build and sell are ones that can just share the application definitions. So, we support those across all the updates and verify that the logic of those is going to work.

For the integrations tools, we can put smarts into the tools that share how the applications are constructed in that. It gives our customers a leg-up that they can start with these components. Then they can create integrations that are a little bit more impervious to being broken by changes in the applications, because they're sharing metadata back into the applications.

Lots of integrations are built on our application programming interface (API) and so we've got to be rigorous about versioning the API and having a contract to support back versions that gives us a certain amount of insurance. It's not like that with some of these opened in the tools that there couldn't be logic and coding errors that are put in and those are the ones that we would have to encounter together with our customers and we're not going to debug every single one of those.

So, for different levels of the game, more packaged, complete support, on up to the more open-ended integrations, you do what you can to try to make it so the integrations are a little bit more robust than what would have been built with a separate tool set.

Gardner: Paul, it sounds less like a buyer-seller relationship than a partnership. Do you view it that way?

Our experience to date is that companies like ours have more of a voice in the feature improvements of the application.

Lones: We do. Our experience to date, working with providers like Workday and some of the other SaaS providers that we are fortunate enough to do business with, is that companies like ours have more of a voice in the feature improvements of the application.

There tends to be, and certainly it's the case with Workday, a much more active community of clients, users, that are sharing information about everything from somewhat technical to very business process-oriented experiences that all of us have had. That's a very different experience.

In some ways, it's sort of ironic to me that we view it quite a bit more as a partnership. A lot of people perhaps think that it's a SaaS application and, if things don't work out, then when your contract is up, you just go find another SaaS provider.

It is true that there might be a little bit more flexibility, but what we’re finding so far in our experience, and it is early, is that the receptivity and the sense of making improvements together, I think it will actually stick longer than maybe some of the traditional software applications.

Gardner: And just to help our listeners understand the extent of your project with Workday, how many employees were involved? Tell us a little bit about your organization, Fairchild Semiconductor, and your global footprint.

Global base

Lones: Fairchild Semiconductor has roughly 10,000 employees worldwide. We're a semiconductor manufacturing company. We have manufacturing facilities in the United States and throughout Asia. Our customer base is global, our employee base is global. Over 70 percent of our business is in Asia and 70 percent of our employees are in Asia. Having the capability to provide a core HR platform like this to that broad a set of colleagues around the world is really exciting for us, and to be able to support our internal customers and the HR group.

Gardner: And have you brought all of those 10,000 employees up on Workday or has it been a staggered rollout? How has that worked?

Lones: We’re at the very end of our go-live process and we introduced this to our colleagues around the world on April 4.

Gardner: One thing that’s interesting is the degree of integration complexity when you’re dealing with multiple markets. So if you’ve brought all of these employees around the world up on this system -- different payroll, different benefits, different government, different cultures -- how is that issue something you can tackle, given that Workday’s integration was a service to you?

Now, we’re looking forward to doing some additional integrations with some of our local payroll systems.

Lones: Well, we had a lot of payroll integrations. I don’t think we would have gotten those all done in the time frame we did without having that capability that Stan mentioned. In fact, with our legacy system, we actually stopped doing payroll integrations, because they were too hard.

Now, we’re looking forward to doing some additional integrations with some of our local payroll systems to improve that connectivity between our system of record for HR and the payroll service providers that we didn’t build integrations to in the past.

Traditionally, we built integrations only for our large-sized locations. There are smaller-sized locations where we have sales offices, and the like and we typically didn’t build those integrations. We’re going to go back and look at doing that now.

Gardner: Well great. Stan, let's take a look to the future. Where can this go? It seems if this is a proving ground given the number of different integration points, a global organization like Fairchild. I know you’re pointing this at your ecosystem and your customers, but if IaaS works here, couldn’t it potentially work anywhere?

Swete: It could work anywhere but we’ve got a lot to do here. I think that when we look toward the future, there are just several different dimensions where we have to build this up. One is something that Paul has been mentioning -- just the value of the ecosystem and I think we've got a good start, but there is a lot of building we can do there.

That is, we can use the fact that this platform is out there and available and proven to attract more and more partners to it both development partners as well as application partners who can be the other endpoint in integrations that we can support.

So, building out packaged integrations for us to enhance the ecosystem is one aspect. Deepening what the tools are doing is going to be a never-ending task. We’re just starting to have ideas about how to share application’s functionality, and embed that inside the tools to make them more powerful integration tools. I very much look forward to continuing to enhance our toolset and that will benefit the integrations our customers and partners build.

The final aspect is the one you hit on, community. We have to encourage people to want to share these integrations. We didn’t need to do more to automatically support that because our partners are going to be generating these things, as our customers, and in the SaaS community, there is just this great notion about sharing the things you do. So, we see supporting that and we can ultimately see that even leading to selling some of the things you do. All of those are potential features for this space.

Gardner: It seems to me a very extensible model.

Swete: Well, let's hope so. We think we’re just starting.

Gardner: Well great. You’ve been listening to a sponsored BriefingsDirect podcast discussion on how new forms of cloud-based integration are helping Fairchild Semiconductor build new relationships among and between extended enterprise business processes. They're doing that using the Workday Integration Cloud.

I’d like to thank our guests, Paul Lones, Senior Vice President for Information Technology at Fairchild Semiconductor. Thanks, Paul.

Lones: Thank you.

Gardner: And Stan Swete, Chief Technology Officer at Workday. Thanks, Stan.

Swete: Thank you, Dana.

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

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

Edited transcript of a BriefingsDirect podcast on new forms of cloud-based integration and its use in enterprise business processes. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• Delivering Data Analytics Through Workday SaaS ERP Applications Empowers Business Managers at Actual Decision Points
• Workday Integration Cloud debut raises bar on integration as service, deeply ingrains integration as apps function
  
• Executive Interview: Workday's Aneel Bhusri on Advancement of SaaS and Cloud Models for Improved ERP
• Architecture is Destiny: Why the Revolution in Business Interactions Can't Work on Conventional Databases
• HCM SaaS Provider Workday's Advanced Architecture Brings New Business Agility Benefits to Enterprises

Master IT Support Providers Chris and Greg Tinker's Take on How Integrated Technical Support is the Future

Transcript of a podcast discussion on new methods for rapid-response IT support on mission critical applications and systems.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. View the blog.

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

Today, we present a podcast discussion on why IT customer support is so important and why industry changes are forcing an integration and empowerment effect for how helpdesks respond and perform.

We're here with two lauded IT Master Technologists from HP to learn more about what makes good customer support tick. Part of the solution comes from providing a more centralized, efficient, and powerful means of getting all the systems involved working, and all the knowledge necessary to come together to quickly get people back in action and keep them there. But, it also involves getting disparate parties and vendors across an IT ecosystem to work together in new ways. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

These two technologists, who happen to be identical twins, were chosen via a sweepstakes hosted by HP to identify favorite customer support personnel. We will learn why they gained such recognition and uncover their recommendations for how IT support should be done better now and later in a rapidly changing future of increasingly hybrid and cloud modeled computing.

Please join me now in welcoming our guests. We're here with Chris Tinker and Greg Tinker, both HP Master Technologists. Welcome to you, Chris.

Chris Tinker: Hi, Dana.

Gardner: And also to you, Greg.

Greg Tinker: Thank you, Dana.

Gardner: Let me congratulate you on this award. This was I think a worldwide pool, or at least a very large group of people that you were chosen from. So, congratulations on that.

Greg Tinker: Yes, Dana, thank you very much.

Gardner: Did this come as a surprise? How did you feel when you learned about it?

Greg Tinker: It was an honor, I can say that, and we are very grateful for that. Our customer installed base, as well as our peers and the management team, put our names into this situation. It was a great honor.

Gardner: Yes.

Chris Tinker: And it was a surprise.

Gardner: Just so we could fill this out a bit, in addition to the quiz and sweepstakes, there was a philanthropic element as well. Every time folks voted, a $10 donation was made to CARE, a leading humanitarian organization that fights global poverty. Is that right?

Greg Tinker: That's correct. For each vote that was cast, HP donated $10 to the humanitarian organization Care, to max out at a $100,000. They met that goal in just a few days. It was quite astonishing.

Gardner: Great. Now, it's kind of ironic from my perspective, because I'm thinking that some of the most unpopular people can sometimes be the IT support, because people are in a really difficult situation when they encounter them, but you guys won the popularity contest for an unpopular task. How does that feel?

Greg Tinker: It's definitely an honor. It's our livelihood, but it’s definitely rewarding.

Chris Tinker: Very rewarding.

Their darkest hour

Gardner: You deal with people when they are, in some cases, their darkest hour. They're under pressure. There's something that's gone wrong. They're calling you. So, you're not just there in a technical sense, which of course is important, but there must be a human dynamic to this as well. How does that work?

Chris Tinker: We become their confidant. We foster a relationship there between the two parties. For us, it's very exhilarating. It's the ultimate test. You want to build both the technical and business, but also the interpersonal relationship, because you have to weigh in on so many levels, not just technical. That’s a critical component, but not the only component.

Gardner: Anything to add to that, Greg?

Greg Tinker: No, Chris actually summed it up quite nicely. He and I both have a passion for what we do and we really thrive in the heat of the moment.

He and I both have a passion for what we do and we really thrive in the heat of the moment.

Gardner: All right. So what does it take to be a good IT support person nowadays? Let me start with you Chris?

Chris Tinker: It’s simply not enough to be a technical guru -- not in today's industry. You have to have a good understanding of technology, yes, but you also have to understand the tools and realize that technology is simply a tool for business outcomes. If you're listening to the business, understanding what their concerns and their challenges are, then you can apply that understanding to their technical situation to essentially work for a solution.

Gardner: Greg, how about for you? What do you think makes a good IT support person?

Greg Tinker: I second Chris's sentiment on that, and I'll add this. Chris and I study, almost on a daily basis, to stay ahead of the technology curve. Chris and I both do a lot in SCSI I/O control logic, with respect to the kernel structure of HP-UX as well as Linux, which is our playground, if you will.

And, it takes what I would call firm foundation to be able to provide that strong wealth of knowledge to be the customer's confidant. You can't be an expert at one point anymore. You can't be a network expert only. You have to understand the entire gamut of the business, so that you can understand the customer's technical problem.

Gardner: It's not enough to go to them and say, "Well, that's really not part of our technical expertise. You'll have to go somewhere else." People don't want to hear that. They want that one hand to shake, right?

Greg Tinker: That's correct, and today the customer expects the technical master technologist, like my brother and I, not just to know the one thing they're asking about, because that question is going to quickly turn. For example, I am having an Oracle performance issue, the customer thinks it may be disk related, but when you dig into it, you find out that it's actually an ODBC call, a networking issue. So, you have to be quite proficient at a multitude of technologies and have a lot of depth and breadth.

Gardner: How did you both get involved with this? Did one get into it first and the other follow? What's the story behind how you ended up here?

Lengthy road

Greg Tinker: It was quite a lengthy road. Chris and I actually started off going in one direction, and we agreed many years ago in school that one of us would go one direction and the other in another, and see who was enjoying the industry better. Chris joined HP and fell in love with it. He and I have a very strong Linux background. Then, I jumped ship and went with my brother Chris, and we have been with HP ever since, and have loved it dearly.

Chris Tinker: That's a great point. We look at IT support as a ladder and we just climbed that ladder. We started in mission-critical support and found it to be exhilarating. With mission-critical support you're talking about enterprise-class corporations. We're not talking about consumer products. We're talking about an entire corporation's business running on an IT solution and how we're engaged in that process.

Unfortunately, in our line of work, we do see customers, where the technology did not go as planned, predicted, or expected and it's up to us to essentially figure out what the expectations are with technology and ascertain whether or not the technology can deliver that. That's how we moved through support.

We started off as mission-critical support specialists. We became architects, designing solutions for corporations and found out that we were very good at escalations and that's where we are today.

Gardner: You've mentioned exhilarating a couple of times. Maybe you could provide us a memorable example of why that's the case. Is there some event that you were involved with in this capacity that comes to mind that illustrates that sense of exhilaration? Let me start with you, Greg.

When I talk about exhilarating, we're talking about C-level execs and everybody else staring at you with hands on the keyboard to figure out what's causing this panic situation.

Greg Tinker: Well, I can't give customer names out, but I will stick to one particular incident. It was a dire-strait moment, where a customer deployed a particular non-intrusive patch. They didn't think anything of it, and it actually caused a catastrophic kernel panic inside their infrastructure and shut down their entire enterprise. Once that condition was met, they couldn't boot the enterprise back up, and then it became a pointing game as to what was the fault, was it x, y, or z?

That's when my brother and I got engaged in this to find that one smoking gun that was causing the environment to panic. And, all eyes were on us. When I talk about exhilarating, we're talking about C-level execs and everybody else staring at you with hands on the keyboard to figure out what's causing this panic situation.

That’s where Chris and I really thrive. We were able to isolate the condition in probably about an hour-and-a-half and pull out that component, the offender, and get the enterprise back rolling again.

Chris Tinker: Not to speak light of the customer situation, but it was a fun moment -- and I say fun in air quotes -- because you have the C-level execs standing over your shoulder, literally watching what you are doing. They're sweating because they've been down for so much time. I should state here that it wasn't the HP technology or HP solution that was at fault. It was a third-party interoperability issue that had gone down and caused that interruption.

But, we did isolate it and we did figure out what it was. We talked to that vendor, partnered with them, and got the solution in place in very short order.

Gardner: I imagine that, even though typically these vendors don't always have all of their ducks aligned, when it comes to this sort of a mission-critical situation, they're probably thankful that there's someone there trying to corral this. So, I imagine the cooperation is pretty high in these circumstances.

Stakes are high

Chris Tinker: Yeah, the stakes are high at this level. You are talking about, not only the corporation, the customer, but you are also talking about the vendors, whether it be HP or third party, and we are partnering with all these vendors. Everybody has got a stake in the game. Essentially, their reputation is on the line.

So we partner, regardless. As we don’t want to be thrown under the bus, we don’t throw anybody else under the bus. We partner. We come together as one throat to choke or one hand to shake, however you want to look at it. But, essentially, we all have the same thing in common, the customer’s wellbeing.

Greg Tinker: I'll second Chris’ sentiment on that, in the sense that when we're engaged at our level, it's no longer a finger-pointing game. It's a partnership, regardless of who the customer is. If it's HP gear, so be it. If it's somebody else’s gear, and we see where the problem is at, we don't point the finger. We ask the customer to get their vendor on the bridge with us and we work as a team to get the business restored, because that’s priority one.

Chris Tinker: That’s HP technical support. That’s what we thrive at. That’s one of our charters. Our management has dictated that they want team effort, global effort.

Gardner: I suppose you can always deconstruct fault afterward, and the point is to get people up and running ASAP.

Greg Tinker: That’s right.

Chris Tinker: That’s exactly right. Root cause is a nice to have, business online is better.

Catchphrases change. Today it's cloud computing, but cloud computing has been around for a long time. We just didn’t refer to it as cloud computing.

Gardner: Right. How long have you guys been doing this? How long has this been your profession and your passion?

Chris Tinker: Thirteen years now.

Greg Tinker: Twelve for me.

Gardner: Okay, 12 and 13 years. What's changed over that period of time? It seems as if complexity just keeps rolling higher and higher, with more unintended consequences as a result of that. What would you characterize, Chris, as what's evolved or changed most in the past dozen years or so?

Chris Tinker: Catchphrases change. Today it's cloud computing, but cloud computing has been around for a long time. We just didn’t refer to it as cloud computing. Shared infrastructure of course is what we called it.

Virtualization today is becoming a big ticket item, where in years past, big iron was the thing that was a catchphrase. Big iron was very large computers. We still have big iron in storage, that’s true. We still have that big footprint, big powerhouse, that consumes a lot of power, but that’s a necessity of the storage platform.

The big thing for today is converged infrastructure. These are terms you wouldn’t have heard years ago, where we are trying to converge multiple type of protocols, physical media under one medium, networking, Fibre Channel, which of course is your storage network, TCP/IP network, going across the same physical piece of media. These are things that are changing, and of course with that comes extreme amount of complexity, especially when it comes into the actual engine that drives this.

Gardner: Additional thoughts, Greg? What's changed in your perception?

Big iron

Greg Tinker: As Chris stated, the key phrase of yesteryear was big iron. I want a big behemoth machine that can outdo mainframe. If you look back to 1999 and 2000, what you were looking for in the open system world was something to compete with Big Blue.

Today it's virtualization and blades. Everybody used to say -- probably about mid-2005 -- "I want a pizza box. I want a new blade." We no longer call those blades. Those are called pizza boxes now. Today, the concept is all about blades. If you can't make the thing 3 inches tall and 1 inch wide, there is something wrong.

Gardner: You've been describing how things have changed technically. How have things changed in terms of the customer requirements and/or the customer culture? That is to say, what are their expectations or perceptions? Let's start with you Chris.

Chris Tinker: Expectation is more for less. They want more computing power. They want more IT for less cost, which I think that’s been true since day one, but today, of course, that "more for less" just means more computing power. The footprint of the servers has changed.

And two, the support model has changed. Keep in mind, we're in support, and we're seeing a trend with these concepts where customers are having all these physical servers and the support contracts on all these servers are being consolidated down to one physical server with virtual instances.

The support model of yesteryear doesn’t always fit the support model that they should have today.

The support model of yesteryear doesn’t always fit the support model that they should have today.

Greg Tinker: What Chris is talking about there is consolidation efforts. Customers used to have 500 servers. Today, -- I want to exaggerate my point here -- we have it on a virtualization of one or two physical machines that are behemoth and it's virtualized 500 guests.

Though that model works right for consolidating the cost effort of the infrastructure, so your capital cost is less, the problem now becomes the support model. Customers tend to reduce the support as well, because it's less infrastructure. But, keep in mind, most customers kind of forget a lot of times that they've put all their eggs into the basket and that basket needs a lot of protection.

So now you have your entire enterprise running on one or two pieces of physical hardware that is a grossly complex with not only the virtual servers, but the virtual Ethernet modules, the Fibre Channel model concepts are all now basically one concept to run every protocol type, whether you are running infiniband, Gigabit Ethernet, Fibre Channel, etc., the complexity requires a great deal of support.

When a customer calls up and says, "We've made a change in our environment and my server has crashed, the physical server went down, or has lost access to its storage or network," you're not just affecting that one physical server, but you're affecting hundreds. So, the support model today is quick.

Chris Tinker: To add to Greg’s point, a compartmentalization of yesteryear was, "I have physical servers in racks and I will go to another row with a different rack. It has more servers there." So, your compartmentalization, your isolated zones, were in the physical data center, where today your isolated compartmentalized zones are within the same chassis.

Gardner: It sounds to me that there is a higher risk profile. Is that a fair characterization?

Hardware redundancy

Greg Tinker: That would be a fair characterization. There is a higher risk on the hardware end in the sense that you still have hardware redundancy, of course, but you're fully dependent upon cluster technology and complexity.

Let's talk about the chassis. The chassis concept of our blade infrastructure, and this is true for most vendors, is that you are redundant there. But, if you want to be redundant at the hardware layer, you've got to have yet another chassis. In order to get that redundancy across the chassis components, you have to have a virtualization software on top of it, adding more complexity, which becomes a real need for a powerful support base.

Chris Tinker: A good solution design for business risk assessments are still a critical component to your solution design.

Gardner: I'm going to guess that over the past several years in the tradeoff for cost and risk, people probably favor the cost side a bit. So, that means the people in your position are the backstop. "I'll assume more risk and I'll have some cost benefits, but in order for me to survive, I'm going to need a more capable IT support function." Is that a fair assessment?

The new light today is that customers are focused more on the higher end support models, meaning four-hour call to repair.

Greg Tinker: That’s what the trend is becoming. The trend is, "We're going to reduce our cost in the CAPEX and reduce our cost in the infrastructure. We're going to consolidate and virtualize that concept, and we are going to look at our support strategy in a different light." That’s what most customers think.

Gardner: What is that new light?

Greg Tinker: The new light today is that customers are focused more on the higher end support models, meaning four-hour call to repair, where it used to be 24-hour or 48-hour support models, where we were not in a huge rush. If we had a disk drive failure, we had plenty of time, because we had full redundancy, whatever. So we had plenty of time to fix those components.

Today, with all this consolidation effort, it becomes a real critical need when you have a failing component, whether it be hardware or software, to get that component addressed urgently. You don’t really have the time.

Chris Tinker: That’s a great point. Looking at that standard support model, you had so many physical servers and your business was essentially interlaced with these systems. You could handle an outage, whether software or hardware condition. It wasn't as strategic or as strong as today’s virtualized environments, where you would have much heavier business impact.

To Greg’s point, this inter-support model used to work with some of these virtualized environments. I am not saying all virtualized environments, but some of these virtualized environments. With four-hour call-to-repair, you can imagine in four hours what’s required. The technologists who answer the phone first have to address the business concerns to figure out what the business impact is and understand what the problem is.

Once we ascertain what’s causing that problem and the problem has been defined, we have to figure out what’s going wrong with the technology in order to bring it back online.

Business assessment

All that has to be done within four hours on some of our most critical contracts. Of course, that’s the most advanced contract. There are many stages between that one and all the way down to standard support. There are all levels in between, and that customized support model has to be a business assessment.

Gardner: So, we have these trends around increased complexity, reduced time to repair or meantime to emulate your issues. We also have a higher level of concentration of risk and an impetus to cut cost, and you guys are dropped in the middle of that.

What does this mean for your role? It sounds like you need to be good technically. You need to be almost Professional Services as well as helpdesk and support. You need to have those good interpersonal skills, a background in architecture, a background in a variety of different technologies. Help me understand what it is that you think comes together that allow somebody to do what you do?

Greg Tinker: I think the biggest thing I would say is having strong technical background. Having in-depth knowledge of C is a good idea, knowing the kernel structure. That way when you have a failure in a component, software or hardware, you have a clear understanding in the stack as to where the problem most likely resides. You need to have a good idea of where to focus.

"I'm having a set-sock-opt error in the TCP protocol stack." You know you don’t have to look at the Fibre Channel stack. Granted, I'm making that way too simple on purpose. My point is that you have to have a very clear understanding of where the stuff resides.

The very first thing you do is not start looking at logs. You start listening to the customer’s problem and having that relationship

Chris Tinker: It's having an understanding of the actual layers, and in computer technology it's understanding all about the layers of the technology, whether it be the hardware layer or the upper layer stack. If they describe a problem to you as X, it's being able to understand where would that fall, what layer would that fall in. And, that’s going to expedite your ability to troubleshoot that problem.

But, to Greg’s point, that goes back to listening -- listening to the problem, listening to the customer's situation. The very first thing you do is not start looking at logs. You start listening to the customer’s problem and having that relationship. One of the key components here is ownership, letting the customer know that I am engaged now, I own this, I'll work with you, and we will get this solved. That gives them the confidence and the reassurance that there is somebody that’s going to work with them. That’s what HP Technical Support is all about -- having that ownership.

Gardner: There have also been some shifts over the past dozen years or so in the degree to which remote support is possible and your ability to get inside and get that information. Maybe we could take a moment to learn more about what tools have been brought to bear to help you with this, when you get that phone call. When you're dealing with that customer in their moment of need, their darkest hour, you also have a bit more of an arsenal. You have some arrows in your quiver. Maybe you could explain what you think are the most powerful ones and why they work well.

HP virtual room

Chris Tinker: The HP Virtual Room (HPVR). If you go to rooms.hp.com, it’s a good example. As you just mentioned, yesteryear it was, "Hey, send me the logs. Send me the examples. Send me some data, and I'll parse through it and figure it out." You had to wait for data to come in and then start parsing those logs, parsing that data, and building your hypothesis of what might be the problem.

Now, imagine if I were able to take that in real time. So, Greg, talk about real time.

Greg Tinker: Real time is key in today’s technology world. Nobody wants to wait. Take your phone for example. Can you stand it when you have pressed the email button and your phone takes more than three seconds to load it up? Everybody gets annoyed when it's slow. Well, the same is true in technology services support.

When customers call in, they expect immediate response. By the time it gets to our level, where Chris and I sit and our team resides inside the support model, the customer is in dire straits. We use the Virtual Room technology. It's similar to WebEx.

There are a lot of similarities out there. Different vendors have different tools. We use the HP Virtual Room toolset and we can jump onto any machine in the world, anywhere in the world, at a moment’s notice. We can do crash analysis on a Linux kernel crash in real time on a customer’s machine. The same with HP-UX, Solaris, AIX, name your favorite.

We can look at these stack traces and actually find the most likely component that compromises the infrastructure. We can find it, isolate it, and remedy it.

We can look at these stack traces and actually find the most likely component that compromises the infrastructure. We can find it, isolate it, and remedy it.

Chris Tinker: Not only is it just us troubleshooting, but it's bringing to bear our peers. It's team work, a two-heads-are-better-than-one mentality. Greg even lived that first. At the end of the day, you've got 2, 4, or 20 people on the phone. You can imagine all of those people sharing the same desktop at the same time to try to look at a problem. You get all these different levels of expertise.

You're able to take all these talents and focus them on one scenario. So, now with four-hour call to repair, how is that even possible? It's possible when we have to bring these people and partner with these people. They could be not only HP employees and HP technical support. That goes back to vendors and those relationships. We bring those vendors into the same Virtual Room, showing them where we're seeing the problem and asking what we need to do to solve this.

Gardner: That puts you in the role of being the conductor in an orchestra in a sense. That’s another skill set as well, getting that leadership and the ability to get people to line up and focus on a common problem. Does that come up more nowadays?

Chris Tinker: We have many hats to wear. It goes back to our prior point that being a technical guru is not the only critical component to being able to execute at this level.

Greg Tinker: It's knowing one’s limitations. As powerful as Chris and I are in the technology world, we have limitations like anyone would. That’s why it's a team effort. Using tools like the Virtual Room, we can look at a situation and have a good idea of where the problem may be.

Leadership role

If we don’t have that skill set, in a moment’s notice we can get one of our team members to jump into the room with us, look at the desktop, look at the situation, and assess it with us. So, it's a leadership role that we hold in our organization, in the massive technology world of HP, to go out and grab those experts that you need and bring them to bear to the situation.

Chris Tinker: Dana, to your point, it's not enough just to know the technology that you're responsible for supporting. For example, you’re tasked with having to know third-party vendor technology, but you are also tasked with having to understand the technologies like HP Virtual Room.

For example, Greg mentioned WebEx, there are many technologies out there, tools that we use that HP doesn’t create and doesn’t support, but the industry as a whole utilizes on a daily basis. I'm sure you're using one right now that’s either a freeware or a public license.

Greg Tinker: Take Outlook for example. That’s a tool. Today, everybody is expected to know Outlook. If you find someone that doesn't know it, you then question their ability. Everybody would. I'm using that as an example, but a lot of people take these types of tools we use today for granted.

Gardner: While we are on the subject of tools, what's coming next? If I were to design these types of tools, you would be the guys I would go to, to get my list of requirements. What are you asking for? What would you like to see come next in order for you to be able to do your jobs better?

The hard one to fix is "My application is not running the way I want it to, Fix it."

Chris Tinker: The mind meld or The Borg.

Gardner: Reading minds, that’s a good one. More practical.

Greg Tinker: Now, there are some tools that are being leveraged daily inside HP as well as outside. HP Storage Essentials being one. The biggest thing we see today is storage. The growth rate of storage is enormous. And the biggest problems customers run into are performance and capacity.

Capacity is the easy one, right? I am 100 percent full in my file system. I just need more. That's the easy one to fix.

The hard one to fix is "My application is not running the way I want it to, Fix it." Those are the difficult ones. We have to have a lot of tools to help us understand what the load conditions are, because it's no longer the yesteryear scenario of a Superdome, HP Rack, one big behemoth machine, four terabytes of memory, 400 CPUs, loading up one storage array. That's no longer the case.

We have grid computing structures of 600+ nodes running a multitude of different things -- SAP, Oracle, Informix, Exchange, etc. All of these different load-bearing concepts are coming into one monolithic storage array. It can become quite daunting to understand what's causing that load condition, and we have a lot of tools today that are helping us ascertain the root of those problems faster.

Chris Tinker: We have become the bleeding edge of technology. Essentially, it's software that hasn't been released. It's tools which are not actually production ready, and we use these tools as well, and some tools we can’t even speak about.

Business realities

But, these are tools that will be in the enterprise eventually. They will be out in the world eventually. You asked earlier what we see coming down the road? Imagination is essentially one of the only things in technology. In today's world, there are other factors of course. Business realities temper the development of technology, but it's going to be very exciting to see what technology is being developed and what's coming next.

Gardner: While we're looking at what's coming next, you mentioned that level of interest in applications not performing, a very general sort of problem at the surface. It seems to me that the definition of application is shifting. As we look at more hybrid computing models, we look at people who will be compositing from a variety of services, all perhaps coming from a variety of sources. The business process needs to be supported, but the constituent parts now are even more scattered, harder to identify.

It seems as if folks who are in your role are going to have an even more important play here when it comes to these distributed and cloud and hybrid types of applications. Any thought about what you would be needing and what to expect if that's the future?

Chris Tinker: Well, with performance, your key challenge is understanding what tools we use, what metrics we look at. With databases, there are databases tools like AWR with Oracle. When should I be looking at AWR, as opposed to the operating system performance metrics, as opposed to the storage array or network performance?

It's having this very large breadth of technology expertise. It's being able to understand first what tool I use to look at performance.

It goes back to what Greg said earlier. It's having this very large breadth of technology expertise. It's being able to understand first what tool I use to look at performance. Then, of course, you have to go back to the business. You have to ask the business owners, the P&L owners, "What is your expectation? What is actually your business challenge?"

Maybe it's a batch job. Maybe it's a report they want to run at month end. Maybe they want to run a month-end processing for their business accounting, calculate payroll.The business has to be able to define what it is they are going after. Their challenge is being able to align the technology to deliver on that challenge.

Gardner: I wonder if you might have just some last advice for those listening to the podcast as to how they on the consumption side might help folks like you on the services and support delivery side do your job better? What advice do you have for them in order to have a better outcome? Any thoughts on that, Chris?

Chris Tinker: Yeah, it's being able to articulate the actual problem at hand, and the challenge that you have with your technology, because keep in mind that technology, IT, is nothing more than a tool that allows us to have business outcomes. So it's nothing more than a tool that the business utilizes for their requirements.

Then, to have metrics around their environment. They have to have a baseline. They have to have an understanding of what the technology has been doing.

Trending is key

Greg Tinker: Trending is key in a lot of these new virtualized consolidated environments. You need to have a baseline, as Chris stated. We need to have the performance characteristics. Your logging and ESX is about as common as sliced bread in a grocery store. ESX environments are very common and thought of very highly. I enjoy them. They are very nice.

Customers tend to start moving towards ESXi, which is fine, but ESXi doesn't log. It does log but you only get like a two hour history. The point is that customers take that logging for granted. You have to have your logging enabled and you must keep at least a six month trend.

So you don't keep all your logs and your service forever, but a six month trend is very helpful when you have a mysterious problem show up. Then, we can compare yesterday to today and see what differences have shown up in the environment.

Gardner: It comes down to data, having the data at your disposal.

Chris Tinker: Not just data, but having a baseline. We get a lot of calls where customers have no idea of what the environment was doing before. They say, "We're having a problem now. Our users are complaining." We ask, "How did it used to run? How long did this job used to take? Did it use to take 2 hours, and now it takes 20 hours?" A lot of times, they simply do not know.

I wish customers would yield to knowing that logging is critical. You don't have to keep it forever, but keep it for a strategic period of time. Six months is a good number.

I wish customers would yield to knowing that logging is critical. You don't have to keep it forever, but keep it for a strategic period of time. Six months is a good number.

Gardner: So as we look at the benefits from a cost and performance angle of concentrating and converging, you might increase your risk profile and become more dependent on folks like Chris and Greg, but having that data and having an understanding of your baseline can help reduce that risk significantly. That's good advice.

Terrific. I want to thank you two for your input and, again, congratulations on being designated favorites at something that's probably, as I say, not a popular role. So to be popular in an unpopular position really speaks well of you.

We've been listening to a podcast discussion on how IT customer support is growing in importance and why the industry changes are flipped, forcing more work towards reducing that risk, but with an emphasis on the people at the front line on your support services.

So thanks to Chris Tinker. I really enjoyed your thoughts.

Chris Tinker: Thank you, Dana.

Greg Tinker: Dana, thank you again for having us. I would like to add one more comment. For those of your listeners that are willing to come out to the HP DISCOVER Event in Las Vegas, Chris and I have multiple publications and we are giving multiple advanced session discussions on internal I/O control logics at HP DISCOVER Event in Las Vegas, June 6-10. So, if any of your listeners wish to come out and meet us firsthand, we would love to see them.

HP also has a site where you can connect with HP Technology Services experts. We encourage your readers to engage with HP directly.

Gardner: Thanks to you Greg. We have been, as I say, discussing the support life and the trends, and both of you gentlemen are HP Master Technologists. So thanks again.

Greg Tinker: Thank you so much.

Chris Tinker: Thank you.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. I've been your host and moderator and you've been listening to a 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. View the blog.

Transcript of a podcast discussion on new methods for rapid-response IT support on mission critical applications and systems. Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

You may also be interested in:

• HP Premier Services Closes Gap Between Single Point of Accountability and Software Sprawl
• HP's Kevin Bury on How Cloud and SaaS Will Help Pave the Way to Increased Efficiency in IT Budgets for 2011 and beyond
• HP's Instant-On Enterprise Takes Aim at Shifting Needs of Business and Government