BriefingsDirect Analysts Discuss Service Oriented Communications, Debate How Dead SOA Really Is

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 36, on communications as a service and the future of SOA in light of hard economic times.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Charter Sponsor: Active Endpoints. Additional underwriting by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Dana Gardner: Hello, and welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 36. This periodic discussion and dissection of IT, infrastructure related news event with a panel of industry analysts and guests comes to you with the help of our charter sponsor Active Endpoints, maker of the Active VOS visual orchestration system, as well as through the support of TIBCO Software.

I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions. Our topic this week, the week of Jan. 12, 2009, starts and ends with service-oriented architecture (SOA) -- dead or alive?

We're going to begin with an example of what keeps SOA alive and vibrant, and that is the ability for the architectural approach to grow inclusive of service types and therefore grow more valuable over time.

We're going to examine service-oriented communications (SOC) a variation on the SOA theme, and a way of ushering a wider variety of services -- in this case communications and collaboration services from the network -- into business processes and consumer-facing solutions. We're joined by a thought leader on SOC, Todd Landry, the vice president of NEC Sphere.

In the second half of our show, we'll revisit the purported demise of large-scale SOA and find where the wellsprings of enterprise architectural innovation and productivity will eventually come from.

We’ll also delve into the psychology of IT. What are they thinking in the enterprise data centers these days? Somebody’s thoughts might resuscitate SOA or perhaps nail even more spikes into the SOA coffin.

Here to help us calibrate the life span of SOA is this week’s BriefingsDirect Analyst Insights Panel. Please welcome Tony Baer, senior analyst at Ovum. Hey, Tony.

Tony Baer: Hey, Dana how are you doing? I hope you're keeping warm up there.

Gardner: Oh yes. Jim Kobielus, senior analyst at Forrester Research. How are you, Jim?

Jim Kobielus: Hi, Dana. Hi, everybody.

Gardner: Joe McKendrick, independent analyst and prolific blogger on ZDNet and ebizQ. Hey, Joe.

Joe McKendrick: Hey, Dana. Great to be here.

Gardner: Dave Linthicum, founder of Linthicum Group and Blue Mountain Labs.

Dave Linthicum: Hey, Dana.

Gardner: JP Morgenthal, senior analyst at Burton Group.

JP Morgenthal: Good morning.

Gardner: And, Anne Thomas Manes, vice president and research director for application platform strategies at Burton Group. Welcome to the show, Anne.

Anne Thomas Manes: Thanks, Dana.

Gardner: As I mentioned, we’re welcoming our guest Todd Landry, vice president of NEC Sphere. Let’s go to you first, Todd. First of all, welcome to the show.

Todd Landry: Good morning, Dana. We’re joining you today from sunny Chicago, where it started out at minus 17 degrees.

Gardner: Many of us are at or under zero this morning.

Landry: We're looking forward to the balmy weather.

Gardner: I hope you get to move south soon. First, tell us what you mean by SOC and help our listeners, who might not be familiar, understand a little bit about NEC, which is based in Tokyo, and Sphere in particular within that larger organization.

Variety of Applications

Landry: Sounds great, Dana. With SOC, what we're really talking about here is the fact that organizations today use a variety of business applications to help them improve efficiency and drive productivity in their organizations.

But, if you look at any implementation and then what happens in the business, the real connective tissue between all of these includes people. The decisions and actions that take place in a business on a day-to-day basis are highly dependent on these people being effective.

Therefore, the manner in which we can help them with their communications and help them collaborate becomes a critical factor in how the workflows can be more effective and more efficient. We've looked at that and said the more you can make communications into business applications, the more you can make communications a more natural part of an SOA.

The workflow can naturally connect people, when they become part of that workflow process. It should streamline how those processes can be completed, and therefore the result is streamlining how businesses can be effective.

Gardner: Well, exactly what types of services are we talking about here? Is this simply mashing up instant messaging into some more applications? Is it more than that? What’s the scale that we are talking about?

Landry: The idea of being able to click-to-call has been around for quite some time. With the more recent technologies mashing up the directory listings, mashing up a call function inside of a business application, is much more achievable and can be done much easier manner than it has in the past.

Now, that said, we can go to the next step and to give you examples. In one view, we are reaching a human for an approval on a transaction. It can be instigated from the business application itself. So, notifications reaching out to individuals to get approvals, using voice technology for actual voice imprint signatures, is one method.

Another example of use is digital assets of the corporation. As we are all aware there are times when we unfortunately have to have organizations come in and collect a lot of emails and history to help the organization. As part of that, organizations are now looking at dialogues between humans, whether they were voice, text tool, conference calls, or exchanges via email. They become part of the digital assets of the corporation.

When we look at communications wrapping those dialogues with some metadata, bringing them back up into content management system so they become indexable, they may become part of the digital assets of the corporation and become uniquely valuable.

Gardner: Just quickly tell us about Sphere. You were acquired by NEC just a year or two ago, right?

Landry: That’s correct, Dana. Sphere Communications was founded in 1994 with a focus on a mission of turning communications hardware into software and, as a result of turning it into software, building it more like a business application.

About 18 months ago, we concluded a transaction with NEC Corp., headquartered in Tokyo. Our focus stays on the software aspect of building communications for the business environment, but we do that now in the context of a much larger organization.

Gardner: With this philosophy of converting the hardware to software as software services, these communications functions can now be brought into a wider variety of business processes, particularly if you're using SOA, mashups, or a variety of different development frameworks and types. The goal here is to bring people into process. Is that fair?

The SOC Ultimate Goal

Landry: That’s really the ultimate goal. On any given day in a business, do people care about doing the mashup or do they care about having their business be more effective, especially in these times? We believe that people will continue to look for more efficiency in their IT infrastructure. They'll continue to look for how people can be more connected, not only internally but with their customers. At the end of the day, you're right. It’s really about how people get more interconnected with the business process.

Gardner: How about this taxonomy? Why do we have to have another acronym, another three letter word, SOC? Wouldn’t this simply be part and parcel with SOA? Why do you see them as different?

Landry: Well, if there isn’t one born, and then it won’t ever die, right? We looked at it and had to communicate to the industry the concept of how communications integrates into frameworks in the IT infrastructure. SOA is a one term still used out there to define an approach. When we built our communications platform, we opened up all its services in a manner that we believe fit very naturally into the concept of a SOA. Therefore, our communications platform is really more service oriented than it is a closed and proprietary traditional PBX-oriented system.

Gardner: Lets go to our panel. Tony Baer, we've talked about this disconnect between processes and the business world, SOA architectural values, and people. I think we had a show devoted almost entirely to the BPEL for People spec when it came out.

Clearly, if SOA is not to wither and die on the vine, bringing people into the process, finding ways of creating new types of efficiencies and innovations, not just repaving cow paths but doing something quite new all becomes important. From your perspective, Tony, what’s the important deal here with bringing communications services into the play?

Baer: I hate to use a cliché, but it’s like the last mile of enterprise workflow and enterprise processes. The whole goal of workflows was trying to codify what we do with processes and trying to implement our best practices consistently. Yet, when it comes to verbal communications, we’re still basically using technology that began with the dawn of the human voice eons ago.

Gardner: I've seen people use sign language.

Baer: Well, that maybe too, and smoke signals.

Gardner: A certain finger comes up from time to time in some IT departments.

Kobielus: At least the use of a trusty index DTMS finger.

Gardner: There you go.

Baer: Exactly, and maybe some other fingers as well. But the fact is that in some cases, there's a huge gap. An example is in the area of compliance. It was a well-publicized case. I won't mention the name of the corporation, because I don’t want to get us into legal trouble here. But, there was a major case of cooking the books. The CEO went to jail, but his predecessor, under whom it was alleged these practices began, was never touched. Allegedly, it’s because he left no trail of breadcrumbs. He never used email. It was all spoken.

The idea of being able to manage and integrate spoken communications may actually be a critical gap in compliance strategy. I could see that as being an incredible justification for trying to integrate voice communications. Another instance would be with any type of real-time supply chain or with trading.

Very often, when I call my broker, the message says please do not leave voice messages on the phone. Provide trading instructions. We can now start to track all that. I'm not sure that it’s such a great idea to leave trading instructions in a voice mail, but there are lot of areas where you're integrating voice communications that could provide business value.

Gardner: Jim Kobielus, isn’t there more to this on the consumer side as well? We've got these hand-held devices that people are using more and more with full broadband connectivity for more types of activities, straddling their personal and business lives and activities. We know Microsoft has been talking about voice recognition as a new interface goal for, what, 10 years now. What’s the deal when it comes to user habits, interfaces, and having some input into these back-end processes?

An Important Extension

Kobielus: That’s a huge question. Let me just unpeel the onion here. I see SOC as very much an important extension of SOA or an application of SOA, where the service that you're trying to maximize, share, and use is the intelligence that’s in people’s heads -- the people in the organization, in your team. You have various ways in which you can get access to that knowledge and intelligence, one of which is by tapping into a common social networking environment.

In a consumer sphere, the thing is the intelligence you want to gain access to is intelligence sets residing in mobile assets -- human beings on the run. Human beings have various devices and applications through which they can get access to all manner of content and through which they can get access to each other.

So, in a consumer world, a lot of the SOC value proposition is in how it supports social networking. The Facebook environments provide an ever more service-oriented environment within which people can mash up not only their presence and profiles, but all of the content the human beings generate on the fly. Possibly, they can tag on the fly as well, and that might be relevant to other people.

There is a strong potential for SOC and that consumer Facebook-style paradigm of sharing everybody’s user-generated content that’s developed on the fly.

Gardner: Joe McKendrick, it seems that bringing communications into the stew really does add value. These are the areas that traditionally have been separate. People did voice activities, they did communications, and they also did data and application activities. Straddling the two was something you did with wetware, with your mind or your hands. Do you think that SOC is perhaps a catalyst to increase value in SOA?

McKendrick: Absolutely. There always have been two levels to this discussion. On the upper level, you’re looking at a lot of business traditionally driven by serendipity. That's the chance encounter in the hallway between two people. Or, it's a phone discussion that may evolve to, "By the way, did you hear about such and such a company laying off or such and such company moving to this market."

One challenge that’s always been out there is to figure out a way to capture this more informal transmission of knowledge that highlights business opportunities. If there's a way to at least capture even a segment of that, to digitize it, and put it into the knowledge base. I think that’s a great advance for companies.

Gardner: So it’s bringing tacit knowledge into play with business processes. Is that what you’re getting that?

McKendrick: Exactly. We heard a lot about artificial intelligence (AI) a couple of decades back, and that showed a lot of promise for capturing some of the knowledge. You had these Jedi Knights that seemed to know everything and had everything in their heads. Once they left the organization, that was it. They walked out of the door with the knowledge and moved to Florida or Arizona. That has been the challenge for AI. Now we refer to it as knowledge management, being able to capture this knowledge, this serendipity, and these informal channels the voice communications.

Landry: It’s human nature to use reference points, historical reference points of dialogs -- whether they’re written or wherever I find them -- to remind me of a topical discussion and bring me tighter into the fold of a particular thread. Think of how we use email. Often, there's a thread of email that helps us go back and look at the history of the dialog that occurred. This has happened in pseudo real time basis with instant messaging these days.

As you described, the natural tendency is a quick discussion at the water cooler. To the degree that we can capture that information, put it in a format that’s indexable, and in my day-to-day workflows as an individual be able to pull that up as I am having more and more dialogs, it becomes very useful referenceable information about why we made certain decisions in the business. That’s one aspect we look at there.

Text-Mining Capability

Kobielus: One of the services in the infrastructure of the SOC that will be critically needed in a consumer or a business environment is a text-mining capability within the cloud. That can go on the fly to all these unstructured texts that have been generated, and identify entities in relationships and sentiments to make that information quickly available. Or, it can make those relationships quickly available through search or through other means to people who are too busy to do a formal search or who are too busy to even do any manual tagging. We simply want the basic meanings to just bubble up out of the cloud.

Gardner: Dave Linthicum, it seems like we're just finding ways of joining different networks. There were the telephone networks. We have had IM networks that are still based on Internet protocols, but are doing their own thing. We've had all these disparate communications types and modes that have popped up over the years and now we are trying to bring them to some kind of harmony.

Do you agree that this is really what SOA, as an approach, should do, and that we don’t need a subset of SOC? And, what are your clients looking for in terms of how communications relates to business applications and processes?

Linthicum: Well, if you're going to take services like this, expose them as services, and make easier use of them, then it’s there. You have to create the integration yourself through very disparate mechanisms and things like that. People are always struggling, trying to figure how to aggregate this stuff and its solutions. This is definitely one approach and it’s viable on the market.

As SOA evolves, they are much more rudimentary. We'll talk about later about the whole "death of SOA" thing. The fact of the matter is that people are just getting their arms around exactly what a service is and how you take multiple services and turn them in solutions.

What's occurring, especially with the downturn in the economy, is that people are focused on more tactical and, what I call a shorter, SOA issues. They're trying to solve particular problems with particular instances of technology. Some organizations have the potential for doing that.

When you look at SOA, you talk about this whole big strategy around structuring services and aggregating those services into solutions. But, if you really look at what people want to do, they want to solve particular tactical problems in a very short period of time and show a very quick value proposition. The ability to take all these communications and actually turn them into services and leverage them is a wonderful use case within the context of SOA. It makes sense.

Gardner: Todd Landry, even though we're in such tight economic circumstances, cost savings obviously need to be part of just about any activity. Is there a clear return on investment (ROI) from your perspective in doing away with the hardware and the PBX-based infrastructure around telecom at least inside of enterprises and going to pure software?

Are you able to really demonstrate that going to software, not only for the purposes of extending it into business processes but just alone as replacement for the cost of a traditional PBX infrastructure, is a good story?

The Two Levels

Landry: There is, and there are two levels. I can put some examples around that. At the first level, remember the three large guys with tool belts who show up in a moving van. They roll some big thing that looks like a refrigerator into the secret room and everybody says, "Yeah, that’s the phone system." Nobody knows how it works, except for the specialist who's been through 10 months of training. These systems are very, very costly to maintain these days. They are specialty hardware, very proprietary, and the maintenance alone has become quite an issue now.

Imagine all that capability being delivered to you as part of a download. You run it on the same computing infrastructure that you use for many of your other business applications and you administrate and manage it in the same way. You don’t have to look very hard at that to imagine some significant efficiencies in IT infrastructure. If it’s built in a way where it opens up its services, you can look at some real examples in the business.

Suppose I have a customer who is a major distributor of airline parts. The issue with parts for aircraft is that they are under strict inspection. Once they are put into the distribution center and shipped to a mechanic, they can no longer be restocked without going through a very expensive, re-inspection process.

What happens with airline mechanics is they'll call in to get certain parts and not being sure what they really need, they'll order three or four different parts. The theory is they'll just send the one’s back that they didn’t need.

This has been a big problem for the distributor. What they've utilized is an actual recording of the dialog between the mechanic and the order entry as that order is posted. They can now go back and very easily pull up that transaction and pull forward the recording. Therefore, the mechanic and the airlines have to take those parts.

These are just real, street-level business issues that I've dealt with. We have several of those scenarios, where once you look at inefficiencies in your business and look at how the human action makes that transaction occur, you can apply the technology to overcome it.

Gardner: JP Morgenthal, we've got cell phones, mobile Internet devices, netbooks, this notion of always on and multi-modality always on. Now just saying that you've got voice, text, and the ability to have two-way communications -- synchronous and asynchronous -- begs the necessity for bringing more communications into business processes. Do you agree with that?

Morgenthal: I definitely do. Clearly from an analyst perspective, you can talk about it and give it a very analytical representation, but the interesting thing is that I actually have real world experience in data behind this. Before coming back to being an analyst and joining Burton in November, I had my own software company, Avorcor, and we had developed supply-chain management as a service.

One things I did was integrate with an open-source communications project called StarPound, which is business-process management integrated with Asterisk, and we built a demonstration that really illustrated the value proposition in the warehouse.

I'd been working with a number of companies who had warehouse issues, and we were basically normalizing those issues by instituting a new services architecture and layering that on top of that legacy system, so they could build their business processes.

One of the biggest issue was they were still communicating exceptions that were happening in the warehouse because device limitations were scanners and text in a very noisy environment. Everyone agreed that the best communications tool in that environment was their cell phone because it vibrated. Well, the Blackberry now has vibration too. So, that’s also a valid form of communication.

If you tie this as a unified communications strategy to the business process, it’s very effective and not only is it very effective, but -- I hate to say it -- it begs only more constant information overload.

Years ago, we took it for granted. You didn't get things for a couple of days, because the communications pipeline took that long to complete. Now, we expect things in microseconds. So, it's enhancing the expectations of people in general because of that. But still, I think overall productivity goes up tremendously, and we move much more effectively toward a real-time event architecture across communications and systems and people. It’s really fascinating to watch and it’s very effective.

Gardner: Anne Thomas Manes, we think about crossing these gaps between what were traditionally telephony technologies, and now it can exercise the services and access the services, but there remains a cultural gap. Analysts, architects, and developers are not always thinking along the communications network line of reasoning. They don’t always look necessarily for these on-ramps and off-ramps to business processes. Do we need to try to encourage developers and architects to think differently around SOC capabilities, as they increase their business agility?

Change the Way We Talk

Manes: We’ll get into the "SOA is dead" discussions later. One thing that I have pushed is not that service orientation needs to go away, but that we need to change the way we talk about it. What we need to be focusing on are services that actually provide value to the developers who need access to capabilities and to the business guys who need the capabilities to be inherent inside their systems.

When we're talking about communications services, you want to make sure that those services are very easy to access. With communications services, when you start looking inside PBXs, voice over IP, and those kinds of things, that’s arcane and completely out of the realm of normal development skills that you would get in a Web developer.

Now, we do have some nice capabilities like click to call, and those are set up as drop-in components that people can now use inside their Web applications. Wouldn’t it be nice, if we actually had a much more powerful communications service that a developer can use to communicate with a customer, communicate with a shop manager, or communicate with whatever at this point in the application?

They can call out to a communications service and specify, "Here is who I want to talk to. Here is the information I want to send. And, here is the method through which I want send it." And, and then they can have the communications service completely take care of the whole processes associated with making that work.

I can guarantee that a developer is going to choose that over, "Oh, I have to write all kinds of arcane code in order to figure out how to send an email or how to launch a phone call." So, building these services that simplify a very complex process is extremely valuable from a productivity perspective.

You can also look at it from another perspective and that is that I can call out to this communications service. This goes back to the first conversation we were having about this topic, which is, "I need to make sure that I actually record this and capture this in my CRM system or I need to audit it for whatever reason."

You can apply policy to the service and have that be something that you can manage and maintain from a policy perspective, which is separate from the code that’s actually implemented in the application or in the communications service.

Gardner: How about that, Todd Landry? Do we still require developers to do arcane integrations, or are there application programming interfaces (APIs) and/or other means of automating and easing the ability for developers to exploit communications services?

Landry: I'm really glad you raised that point, because we know your example of click-to-dial has been around for a while, but the execution of that has been very complex. A lot of companies that have enabled that have done it using people who are rich in telecom protocol experience and things like that.

With SOC platforms, we see it as creating an abstraction to those telecom functions -- such as making a call, recording a call, or setting up media streams -- and hiding that all from the developer. You are welcome to a white paper that describes this approach of abstracting the communications complexity.

When we looked at it in terms of how you would make it available to the applications developer, for example, our tools include Web services description language (WSDL) files that can be imported into your environment. So, you can take an IBM Rational environment, bring in functions available on the communications system and use application and Web-type technologies, without having to understand the complexities of underlying telecom protocols. That’s probably one of the most critical things that we need to do on the communications side to allow the developer community to benefit from this.

Gardner: Isn’t there another approach to this, in addition to trying to ease the actual development, to make these services all part of the same cloud? Perhaps salesforce.com or Google might start offering more telephony services within their cloud. Therefore, the integrations are being done within their infrastructure and it becomes easier for developers to create processes. Do you expect that SOC will have a role in how some of these cloud providers increase their value to developers and then therefore to end-users?

Distributed Cloud SOC Services

Landry: Yes, and in the way we deploy today in many of our customers, we would, in some respects, describe it as a private cloud, because of way it’s built and because of way it’s a distributed and shared service within the enterprise.

We've got a handful of cases where we deployed that in more of a service-provider approach and you could argue that, because the consumer, the enterprise, has some stuff on premises they can also overload that or use services from the local provider. It’s built on that kind of model.

There's is another piece of this that says these platforms are bringing together multiple forms of media, so that you can utilize text messaging, audio, or video communications. You can do screen-sharing data collaboration in a simpler and more consistent fashion and you can utilize one set of services to do that.

Whether they're deployed as a cloud and the enterprise is using those services from within a cloud or whether they've made the decision to do them on premises, both are very viable and, in many cases, both are being done today.

Gardner: Okay, last question on SOC. Dave Linthicum, with the emphasis on cloud nowadays, do you see bringing these communications services into a cloud portfolio as a way of enticing more enterprises to get involved, particularly if we're talking about reaching out to consumers through these communications channels? Where do you see SOC and cloud intersecting?

Linthicum: They already are, probably not as formal services and definitely not as integratable data into the enterprise, but anything that’s a value within enterprises, as we are finding, ultimately will be something that some start up or even some big company packages up as a set of services and sticks them up in the cloud.

If you look in ProgrammableWeb, you'll find that there are a ton of services that are very communications oriented. They're probably not as sophisticated as the ones we're talking about now, but as more and more people adopt that as a paradigm and need these things to build enterprise composites or even mashups, then you're going to see a lot of movement in that direction, because it’s a fairly simple thing ultimately to do.

It’s going to be a very high value service to sell. You're not competing with the guys who are giving the stuff away for ad share. And, it’s just going to be another value cloud out there that people can leverage and integrate within their enterprise.

Kobielus: I want to add one last observation before we go to the "SOA is dead" topic. In order for this integration to happen in the cloud, the cloud providers need to federate their new registries with those of their enterprise customers. But, humans are reachable through a different type of registry called a directory, lightweight directory access protocol (LDAP) and other means.

Cloud providers need to federate their identity management in a directory environment with those of their customers. I don’t think the industry has really thought through all the federation issues to really make this service oriented, business communications in the cloud scenario a reality any time soon.

Gardner: So we need an open Wiki-like phone book in the sky.

Kobielus: Exactly.

SOA: Dead or Alive?

Gardner: All right. Let’s move on to our next subject -- "SOA: dead or alive?" Anne, you created a little bit of stir with a recent blog or around declaring SOA under significant pressure, particularly as a result of the economic climate, because people are not going to spend money without that verifiable ROI.

These large-scale SOA implementations are too complex and taking too much time. The economic climate is going to postpone, if not kill them outright. Did I get it right, and what’s been your position since the blog, in terms of the viability of SOA?

Manes: Certainly, lots of people have refuted my claim. At the same time, I've had at least as many people, and probably more, I am dead-on right. My goal with the blog post was to at least get the conversation going, and I think I managed to do that effectively.

I still believe that if you go before a funding board this year -- if you are an IT group and you are trying to get funding for some projects -- and you go forward with a proposal that says we need to do SOA, because SOA is good, it’s going to get shot down. Instead, what you have to go forward with is very specific value-add projects that say we need to do this, we need to do that, and we need to do that.

You need to talk about what services you're going to provide. In the example of communications services, there's a really strong value proposition associated with creating communications services. Likewise, going forward with a request to say, "We need to build a billing service which replaces the 27 different billing capabilities that we have in each of our product applications out there."

That’s a very strong, financially rich, good ROI type of proposal that’s going to win. But, it's not going to work, if you go forward and just say, "Oh, we need to go get an ESB. We need to go get some registry and repository technologies. We need to invest in all the SOA infrastructure. We need to do SOA just because SOA is what everybody is telling me we need to do."

Just talk about the services and talk about the practices that are going to help improve the architecture of your systems. Talk about doing application rationalization and talk about reducing the redundancy within your environment.

Talk about dismantling the 47 data warehouses you have that contain customer information and create a set of data services instead that actually gives you a richer, cleaner and more complete information about your customers. Those are things that are going to win.

Gardner: Does that mean that we're really still heading toward SOA, but we're just going to do it through a variety of tactical measures, and ultimately, without even realizing it, you're going to be doing SOA and that, at some point, you might need to rationalize that at a higher architectural abstraction with such things as ESBs and wider governance? Does that sound right?

Manes: Yes and no. It’s absolutely critical that you still have a strong architectural group. One of my favorite comments that came back from the blog post were the number of people who said, "Basically, we just really suck at doing architecture."

One of the primary reasons that a lot of SOA initiatives are failing is because people don’t actually do the architecture. Instead, what they do is service-oriented integration, as opposed to SOA. If you're truly doing architecture, then you're doing an analysis of your applications architecture, figuring out why you have so much extra garbage in your environment, and figuring out what you should actually start to get rid of.

You still need to have that planning group which is very strongly focused on setting the priorities. But then, what you go forward with in terms of funding are the projects that are actually going to help you achieve your architectural goals.

Bunker Mentality

Gardner: Another observation I had from watching the discussion that you helped create is that there seems to be quite a bunker mentality out there right now. A lot of people in IT are saying, "Listen, we're not going to do anything. We are going to just hunker down and keep it the way it is. We don’t need to innovate now. Wait until we get through this terrible crisis and then we will figure out how to be modern or agile."

On the other hand, I am seeing people saying, "No, now is the time to get innovative, to leapfrog, to take advantage of the pressure to reduce waste and look for efficiencies which ultimately will allow us to be more competitive not only in the short-term but over the long-term." Are we really looking at a typical, conservative-liberal breakdown in terms of the philosophy inside of IT department?

Manes: I suspect that you're going to have a lot of organizations that don’t have a lot of architectural maturity following the first camp, which is, "We're going to cut out everything. We’re just going to focus on tactical projects."

But, the folks who have a little more architectural maturity recognize the value of taking this opportunity, when lots and lots of projects are no longer going forward. They can say, "Well, now is a great time for us to start focusing on architecture and figure out how we can position ourselves to take advantage of the economy, when it does finally turn around."

Gardner: Okay. Tony Baer, we're heading into this deep depression, recession, whatever you want to call it. Those companies that aren’t very good at architecture will probably, if they hunker down, fall even further behind. Those organizations that have some budget to play with, that are not in survival mode alone, and are looking to be something bigger and better on the other side of the recession, they move further ahead. Are we coming into a bifurcation of who does IT better or worse, based on this recession?

Baer: I don’t think there is any question about that. I'd call that the Walmart strategy. Take a look at the previous recession. To some extent, the same thing is happening now that happened back in the recession of 2001-2002. Walmart actually increased its spending for expansion with the expectation that its low-price strategy was sound. In other words, its marketing architecture was sound for that period, but that it would be better prepared for the upswing, when the recovery happened.

I think what Anne is saying right now is that organizations that did get ahead of the curve with SOA, that thoughtfully began the architecture process and rationalized it, will go ahead, because there will be real economies at some point compared to traditional application development.

Those that have been basically doing what Joe McKendrick has called "just a bunch of web services" are just going to essentially retrench and say, "We just can’t afford to create more spaghetti right now. We are just going to do it a lot of break fixes." So, I would totally agree with Anne there.

Gardner: Joe McKendrick, are we going through an acceleration of winners and losers in IT, particularly at a sort of company-strategy level and core-competency level?

McKendrick: Yeah, Dana, absolutely. I've always said that the companies that have gravitated towards SOA are the companies that will probably do well anyway. Those are the companies with more visionary management and more tightly integrated approaches to business. Those are the companies that we've seen in all the case studies that over recent years that have gravitated towards SOA. Let’s face it, if they didn’t have SOA, they probably would have been doing okay anyway, because they're well-managed companies.

The companies that really could have used SOA, the companies not likely to be adopting SOA, or not likely be looking at SOA, as Anne and Tony discussed, those are the hunker-down companies, the companies that have fairly unsatisfactory architectures or no architectural approach. We're going to be seeing that going forward as well.

Gardner: To further refine this, Dave Linthicum, are we talking about companies that are good at IT, regardless of what’s in their quiver whether it’s SOA, Web oriented architecture (WOA), or communications and SOC? Regardless of the tools that you have at your disposal, it’s how well you use them that defines you, and if you fall further behind and you don’t adopt more tools, that’s a bad thing. Is that oversimplifying it?

IT Talent Shortage

Linthicum: Not really. The point that I made is the same point I have been making for a long period of time. We have talent shortage in the world of SOA. There are companies out there that have some very good IT talent, and they can take SOA, WOA, or cloud computing, look at the business problems, make some very nice systems, and automate the business nicely.

However, the majority of people out there who are wrestling around with architecture are ill equipped to solve some of the issues. They have a tendency to focus in wrong areas. Anne hit this in her blog as well. It was brilliant.

In the area of, "Let’s do quick tactical things, and look at this as a big systemic issue we are looking to solve," it just becomes too big, too complex. They try to solve it with things that are too tactical and just don’t have enough value. There are no free lunches with SOA or any kind of an architectural approach or any thing we have to improve the business.

You're going to have to break things down to their functional primitive and build them up again. You're going to have to think long and hard about how your architecture relates and links back to the business and how that’s going to work.

I wish there were something you could buy in a box or something you could download or some cloud you can connect to, but at the end of the day it’s the talent of the people who are doing the job. That’s where people have been falling down. Over and over again, in the last three years, we have identified this. I don’t think anybody has taken steps to improve it. In fact, I think it’s gotten worse.

Gardner: JP Morgenthal, without trying to be derogatory, it sounds like those people who do just tactical things, who are not evolving to a larger culture at a business-process level, at a agility level are kind of like Neanderthals. They were walking around Europe 25,000-100,000 years ago. Then, these Homo sapiens come on the scene and maybe have a little higher abstraction of skills, competency, look strategically at IT, much more services-oriented that eventually will overtake the landscape. Does that sound right?

Morgenthal: It's a great question. To say that you are going to be successful in business because you focused on IT architecture is a stretch. When we did our 2009 predictions, one of my predictions was the rise of disposable computing. For a certain class of businesses, it’s going to be okay to have "good enough" software and not worry about, "Am I going to be using the same application 20 years out," -- really moving the thought processes from 3-5 year plans to 5-9 month plans.

When you talk about things in that range, SOA falls apart as a requirement, because that’s something that you definitely want to engage in where you have longevity or a long-term strategy to apply. Including cloud computing and the rise of start ups in the cloud, or at least their IT infrastructure in the cloud, versus building data centers, is going to introduce an opportunity for that to occur.

There is a class of organizations that hears SOA. They're going to get IT staff that come from an environment where people did SOA. There's going to be a little culture clash, because the executives there are going to be saying, "I don’t get this. I don’t get you. Who are you? I want my cell phone to do this, this and that, and I can make it do that by looking at it sideways. You’re telling me I've got to go spend all this money. Are you nuts?"

So, you have that going on, and then you have organizations that are involved in some very complex business opportunities in the financial sector or in the manufacturing sector. If they don’t look at their business and model it in a way that their systems mirror what they are doing one for one, they’re going to continue to fight that impedance mismatch that’s been going on since the early days of computing.

Then, the mismatch made sense, because the costs of computing were so expensive that we had to take small bites, chew on it, and make it work. Now, with the cost of computing where it’s at, we should be disregarding that notion, reexamining our systems, and saying our systems should meet our business requirements one for one. We shouldn’t have this discrepancy that when I talk business, it needs to be translated for IT purposes.

Gardner: Todd Landry, for some organizations, SOA is dead, at least during the economic downturn. For other organizations, it could be alive and well. From your perspective, what differentiates these organizations? How do you separate the innovator class from the "let’s just keep it simple and do our jobs and hope for the best" class?

Landry: Finding them and separating them is probably an arduous task. During tough economic times, the question of what projects should be worked on becomes more of a financial question than just it’s a cool technology question. During better times, we do many different projects and don’t spend time looking at the business benefit.

JP’s point of, "if you do technology architecture, your business will get better" is not real. There are hundreds of different projects you can look at in any IT infrastructure, and, especially today, people are spending more time looking at which ones will help the business operate in a more streamlined fashion.

They’re questioning what it’s going to cost to do that, how I can do that without spending outrageous dollars, and is it going to make a difference for my business? Again, the observation of cost associated with those projects becomes more heightened during these kinds of economic times.

We're looking for people who are investing in new initiatives, because they see this as an opportunity to optimize, an opportunity to streamline, and it will help them longer term. We look for those kind of people that realize that this can be seen as an opportunity, as much as a tough situation to deal with the economy.

Kobielus: The whole "SOA is dead" theme struck a responsive chord in the industry, because there's a lot of fatigue, not only with the buzzword, but the very concept. It’s been too grandiose and nebulous. It’s been oversold, expectations have been built up too high, and governance is a bear.

We all know the real-world implementation problems with SOA, the way it’s been developed and presented and discussed in the industry. The core of it is services. As Anne indicated, services are the unit of governance that SOA begot.

We all now focus on services. Now, we’re moving into the world of cloud computing and, you know what, a nebulous environment has gotten even more nebulous. The issues with governance, services, and the cloud -- everything is a service in the cloud. So, how do you govern everything? How do you federate public and private clouds? How do you control mashups and so forth? How do you deal with the issues like virtual machine sprawl?

The range of issues now being thrown into the big SOA hopper under the cloud paradigm is just growing, and the fatigue is going to grow, and the disillusionment is going to grow with the very concept of SOA. I just want to point that out as a background condition that I’m sensing everywhere.

Gardner: Anne, is there a hedge on this somehow? That is to say, can you continue to be tactical, can you avoid some of the larger cost issues around SOA, but, at the same time, not put yourself at a disadvantage 18, 24, or 36 months down the road for moving closer to SOA at that time?

Manes: My core recommendation is to think big and take small steps.

You need to do the planning, and your architecture team should be able to do that, without having to go get permission from your funding organization to do planning, because that’s what they’re supposed to be doing. But then, they have to identify quick, short, tactical projects that will actually deliver value.

That’s what they should do and are designed to do to improve the architecture as a whole. It can't be just, "Oh I have to integrate this system with that system." They really should be focusing on identifying projects that will, in fact, improve the architecture. In that way, you’ll be in a better position when things are over.

Gardner: Just to pull our two discussions together, do you think that SOC forms one of those tactical benefits that demonstrates ROI, improves productivity, but that also sets you up for larger benefits later?

Manes: Communications services, as a general rule, are valuable because having your applications integrate with communications is often challenging. But, you need to take a look at your individual corporate priorities to determine whether that actually is a higher priority this year than something else.

Gardner: Does anybody else want to chime in quickly on SOC as a tactical benefit to SOA? Todd, you must have something to say on that.

Landry: The tactical benefit we’re seeing is a lot of very specific cases already in the end-customer areas, where people have made the decision that this is important. We talk about the economy, but security concern is at an all-time high, and there is a lot of sensitivity there.

In most government organizations, they’ve now assigned a geo spatial officer, someone to go look at how the communications system is better used across the different emergency organizations, and how first responders can come together and communicate and collaborate in emergency situations.

We’ve recently demonstrated some multidimensional collaboration tools that bring together the identity of vehicles and simplify the manner in which you tie radio IP-based communications across different emergency entities. You’ve got real cases here that people are addressing today. There are some tactical activities out there related to that.

I think the point made about think big and pick small projects is really important, because it is a big ocean out there and you’ve got to pick the things that makes sense for your business.

Gardner: Great. I want to thank the panel for this week, we had Tony Baer, senior analyst at Ovum. We had Jim Kobielus, senior analyst at Forrester Research. Joe McKendrick, independent analyst and blogger. David Linthicum, founder of Linthicum Group. JP Morgenthal, senior analyst Burton Group, and Anne Thomas Manes, vice president and research director of Burton Group.

We also thank our guest, Todd Landry, vice president of NEC Sphere. I want to also thank our charter sponsor for the BriefingsDirect Analyst Insights Edition podcast series, Active Endpoints, maker of the Active VOS visual orchestration system.

We’re also coming to you through the support of TIBCO Software. This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and come back next time.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Charter Sponsor: Active Endpoints. Additional underwriting by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 36, on communications as a service and the future of SOA in light of hard economic times. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

IT Repositories Help Financial Giant Manage Change Amid Complex Systems Consolidation

Transcript of a BriefingsDirect podcast on the role of repositories in data integration for large enterprises. Disclaimer: The views expressed in the following are not necessarily those of Wells Fargo & Co. or any of its subsidiaries or affiliates.

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

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 solutions for enterprise repositories in service-oriented architectures (SOAs).

We'll look at how enterprise systems of record need to be increasingly managed by repositories, or assets need to be quickly federated and integrated in cases of mergers and acquisitions (M&As) or unexpected business consolidations. Done incorrectly, managing and consolidating data from various systems of record may create multiple information systems that may "disagree" about the same piece of information.

Using SOA and repositories effectively, however, can pave the way for harmonious data integration and service mappings across these critical systems. Getting your systems-of-record act together in conjunction with enterprise repository solutions provides more flexibility for change and disruptions -- challenges not unheard of in today's tough economy.

While the challenge is significant, gaining new value from managing repositories and SOA governance sets a stage for much greater visibility and agility, when facing wholesale shifts, unexpected or otherwise, in how applications and data are used.

We're going to provide an in-depth look at how enterprise repository solutions are evolving in conjunction with systems of record. We're joined by two IT enterprise architects from Wachovia, a bank currently moving through a massive acquisition process with Wells Fargo.

We welcome Harry Karr, an IT architect at Wachovia. Thanks for coming on the show, Harry.

Harry Karr: Thank you very much. I appreciate it.

Gardner: We're also joined by Hemesh Yadav, also an IT architect at Wachovia. Hi, Hemesh.

Hemesh Yadav: Thank you so much, Dana.

Gardner: Now, we don't really want to focus on the acquisition so much as we want to focus on the systems of record, and we are looking at managing multiple systems under perhaps difficult circumstances.

Let's start with you, Harry. Tell us how IT architecture is destiny when it comes to these systems of record, and how to manage multiple systems effectively?

Karr: Well, the hardest part is keeping track of what we have, especially in times of mergers and acquisitions, but also at any other time. When we are trying to add new functionality, the first thing you have to know is what you have in place. So, keeping that up to date, knowing what we have is probably the biggest challenge.

Gardner: How is it different now from the past, when it comes to the tools you have at your disposal to manage these various systems and try to bring them into some concert or harmony?

More Distributed Systems

Karr: The difference is that we have more distributed systems now. We have services being offered by a half dozen or a dozen different service containers. We have many different clients hitting those services. We have many more pieces to the puzzle than we had before, and they're all owned by different people, different groups, and different teams.

Keeping up with that is much harder than it used to be with a single monolithic type of application, as in knowing where the touch points are, what the integration needs are, and where the security mechanisms are applied. There are a lot of things you have to know between the applications.

Gardner: How does the repository come into play here? How does this fit into the puzzle in order to make that complexity a bit more manageable?

Karr: I like to talk about a repository solution. A repository solution has more than one physical repository, and each one has certain specific information or a slice of the data. All together, it gives us a good enterprise solution for a repository and gives us a picture of what we have.

In our world, we do a lot of outsourcing and going through a change of structures, determining what we're going to do right now. We're being acquired by Wells Fargo, and all those changes mean different people will be involved with different things.

If something isn't written down, you've lost it. It's not going to be there. What we need to do is make sure that we have a record of what's there, so that anybody in the bank can go back and look and say, "We have this at this point, and these are the touch points involved, this is the security, and these are the access requirements." Anything they need to know about those touch points can be known from that repository solution.

Gardner: I suppose it must be a great comfort if you were to find yourself working with another organization that had gone through the same diligence and has also embarked with repository solutions.

Karr: Oh yeah, it definitely helps. When you first sit down together, you are out there fact-finding. What do you have? What do I have? Having that in a repository, I can look it up and research it. It's readily accessible. I don't have to wait and call another meeting with the right experts in place who weren't there at the first meeting. I have all the information there, and I could talk to one architect to look up all that information.

Gardner: And this seems to be a reactive and proactive benefit. That is to say, you can look into these systems and understand more about your applications and data, but you could also then execute through these repositories, apply policies and rules, and then have a certain level of functionality follow through. Is that correct?

Karr: It is correct, and we have done that to a limited extent. I think there's room to do it a lot more than we've done it, but right now we've just done very minimal amounts of that.

Gardner: Okay. Hemesh, what sort of role do you have in this, and how do these various federated repositories come together effectively?

One Place to Go

Yadav: Dana, my experience is based on my previous job and my current position. I was involved with repository implementation for Bank of America, when we picked the HP repository (HP SOA Systinet). At the same time, I was working with Harry to pick a repository for enterprise solution for Wachovia. I'd just like to add what Harry was trying to convey here. If you have a single repository and multiple federated systems, you have one place to go.

This is especially true around merger and acquisition, when you are trying to consolidate all the information into one place. I've personally used repository for mergers and acquisitions. When we did the merger with Bank of America with another large banking operation, we put all their Web services into one place, and we put our Web services into one place.

Even though you put their services and your services into one place, if you don't have a common place to store and keep the information in very organized way, if you don't have a single repository and you don't have a good taxonomy to classify those services, even though you have a single enterprise solution, it doesn't really make you very productive.

We tried to address single repository with single classification scheme, single taxonomy, and single policy. So, you have policies for the design time or runtime implementation, naming conventions, and also how we store the metadata, even though you have a different source of systems. But, if you build an enterprise repository and implement a single enterprise metamodel, it will be very easy to classify, store, access, and understand data.

Karr: I'd like to add to that. Hemesh brought up a good point about the consistency of the data in a repository. In my mind, there's no value at all in putting information in a repository. The value is when we get the information out, and in order to get it out, you have to be able to query it. Having it in with a consistent taxonomy and consistent metadata is the only way that you can get the information back out again.

Gardner: Hemesh also raised an interesting point about this lifecycle benefit, bridging the gap between design time and runtime. This has some relationship to a configuration management database (CMDB), moving into quality assurance and the whole production process around services, perhaps even in an agile situation where there is very rapid development and many iterations managing that whole lifecycle. Harry, do you have any thoughts on how powerful repositories are in terms of this lifecycle benefit, perhaps, integrating across internal processes?

Karr: You can come up with a case that there is a selling point for repository at any point in the lifecycle, and all together it's a huge story. But, even at any point, such as the original conception part, do we have this already? Is that already available? How does it fit with what we already have? Going into development, are there pieces that can be reused? How do people know what's developed? Where do you put the Web services description languages (WSDLs) and schemas, when you are developing services?

The next point is around the testing. Testing needs to match the business requirements. If those requirements are not in a repository, are they being handed over on a notebook somewhere? Where do they exist? Repository helps a great deal there.

Then, in production and troubleshooting, deployments, end production, or any kind of troubleshooting you need to know what changes have happened. What's going on with that application? What's changed since the last time it was running properly? Without all that tie-in from all those different repositories, you lose track of what you have, and it helps every single lifecycle.

Gardner: Almost on a philosophical level, it seems that repositories help balance the best of decentralization organizationally. And, in terms of policy and access and control with centralization, you want to have both. Does that strike you as fair?

Karr: It does. There are different corporate mandates for centralization, how much is centralized versus not, but the data can be centralized whether the teams are or not. The organizational structure shouldn't be affected by how the repositories are put in place.

Gardner: Hemesh, what sort of requirements do you look for in choosing repositories? I should think that is better to have more standardization, and the ability to embrace as much data and as many systems formats and used structures as possible. Right?

Defining a Metamodel

Yadav: When we looked at a repository, we looked at a couple of points. I'll just mention couple of key points. Number one, you should be able to define a metamodel for a repository. If you have a repository that comes with an out-of-the-box metamodel, there is a specific way you can define the services or load the services into repository. But, we wanted to customize those metamodels. We wanted to change those models so that we could customize according to Wachovia needs. That's number one.

Some products, when you store their services, they try to keep the level at the Web-service level. They don't keep it at the operations level. Web services could have multiple operations. They don't treat operations as a first-class citizen. There is a gray area there, and most of the vendors have not done a great job.

The third point was that we were looking for how to generate good reporting. So even though you load the data into a repository, there's no good way to generate a report using some types of tools. We found that some products are very good with that, but some products had a lot of weaknesses.

Fourth, we wanted to make that sure that when we stored any data in the repository, we should be able to integrate it with extensible markup language (XML) appliances, universal description, discovery, and integration (UDDI), or SOA management solutions, so we can have complete closed-loop governance.

So, you define your policies, you mandate your policies, you track your policies back, make sure you are meeting your service-level agreements (SLAs), and you generate good reporting. These are the three or four items we were looking very closely when we looked at the products.

Gardner: I suppose another important aspect is how to get started on something like this. Harry, given that you're managing multiple repositories, you're probably going to be managing even more over the course of your business activities.

Is there an opportunity to sort of crawl, walk, and run with these? And, once you do get into sort of a jog or are moving along rapidly, how widely can you establish an SOA, vis-à-vis these repositories?

Karr: Well, it's hard, because you want to look at the whole enterprise repository solution. You want to look at what touch points need to be between the different repositories. Once you map out that, then choosing and working on one repository at a time, putting it in place, and putting it in for a certain unit or division within your company will work very well.

If you don't have the big picture to start with, then, when it comes time to integrate those repositories into a cohesive picture of what you have, you are going to be stuck. You'll have to look at a lot of redo of your work, and that's very expensive.

Gardner: What recommendations do have for folks in order to avoid that?

Karr: It's important to look at the whole picture. They need to look at what's important between all the different repositories. You need to have some way of storing your business-process model. That includes business rules, services, information about your systems of record, information about the data, contracts, who's using what, requirements for change management, SLA management, problem management, organizational structure, and process flows.

All those different repositories need to have touch points. Mapping that out ahead of time will give you an idea of what to do with any one of those, as you put each one in place.

Yadav: One thing I want to add here is that when we were looking into repositories, one thing we were looking at was how to implement a repository where we can leverage the implementation for risk lifecycle management and SOA governance. We wanted to keep that bigger picture in mind, so that whatever information we had in place, we wanted to make sure we could capture it and have it be useful for SOA governance purposes as well.

Gardner: That's interesting. We have a need for backward compatibility, if you will, to be inclusive of as many systems and repositories as we can, but we also want to provide insurance for the future. We want to be able to provide a better business process model and management capability with tools along those lines.

How do you view this as a return on investment (ROI), Harry? Is this money well spent, in that if you do this right, it's going to have many returns for quite some time?

Hand in Hand

Karr: I agree completely. It is going to have a lot of benefits. If you can make the business case for governance of any sort, then the repository goes hand in hand with that governance -- being able to track what you are doing, your processes, everything involved. The repository is a key piece of the governance. I don't think that anybody would disagree that governance has a great business case behind it, and the repository is part of that governance model.

Gardner: I've been in some conversations recently where we've gotten into the notion that governance is not only going to be powerful for managing information systems, but ultimately the same repository can be applied -- and the rules and policies extended -- to actual business processes and across front-office and back-office activities. Do you have a sense that we're going to move this beyond just IT?

Karr: Definitely. As I mentioned a minute ago, the business process models are the business. The business owns that, but they need to see what goes on beyond that. How is that implemented? How does that make you real within the services that are being called? Business process models have an active part in this.

Everybody talks about alignment between IT and business. The repository is the key piece of that. In order to have some kind of alignment, you have to have visibility, and the repository gives you that visibility.

Gardner: Do you agree, Hemesh, that this repository solution set provides a better way, a broker or pivot point, across multiple aspects of a business?

Yadav: Definitely. If you start doing your top-down business process modeling, and you try to create a business activity, build a business service, or implement business services, that's the only way you can track it end to end.

You say, "Okay, this is the business activity, and this is a service that belongs to that particular business activity." If you don't have a single point of storage, or if you don't have an enterprise repository, it's very hard to align business needs with IT implementation.

Gardner: Let's look further out on the horizon, as people start doing sourcing across different types of hosting scenarios and models. We hear a lot about cloud computing these days. Do you sense that these repositories and this solution approach can help you manage services from a variety of different environments, different sourcing, and perhaps even entirely different business models?

Karr: We do sourcing in a lot of different ways. We outsource development. We have services that we buy from other vendors. We have services that are hosted by other vendors -- all those different models.

Getting back to one of your original questions, Dana, about why it's different now than it used to be regarding repository, this is much more distributed than it ever was before, and that trend is only going to increase. As we become a global company, we need to be able to communicate and have that visibility into what each of the pieces is doing. And, as the distribution goes across company boundaries, so it gets even more important.

Gardner: Do you have anything to add on that, Hemesh?

Yadav: No, I agree with Harry. I just wanted to give you an example, how we implemented in my previous job, how we leveraged the SOA repository for-end to-end development. We started with the service architecture as very top down. We put the data into a service repository. The designer would come and add WSDL information to the repository.

Then, the offshore resources would add additional metadata about the system. Then, when we'd go to the hosting team, they would add additional information like WSDL endpoints, service hosting data centers, and other things. So the service repository really helped us to bring different parties to work together and share the information in a common way.

Gardner: Now, you're in the banking industry, and we're going to see more regulation. I don't need to be an analyst to make a big bold prediction that there is going to be increased regulation in the banking industry.

Do these repositories and solutions benefit the compliance and regulations that might also be fast changing in the coming years?

Regulation Means Tracking

Karr: Good Point. I don't think I'll question the fact that we're going to have more regulation. It's going to happen. Any time regulations come in, it requires us to track more of what we have, what we're doing, and how we're doing it, and that's where repositories come in. They don't come from different groups owing that information. It needs to be visible at the highest level throughout the company. That's where repository really helps, and having a centralized repository solution is a big part of that.

Gardner: Harry, if you were to go write a book about your experiences with repositories, what would you say would be the first two or three most important chapters that you need to get into that for setting people up for this journey?

Karr: The big part to me is looking at the scope. How big a picture are we looking at? Are we looking at something just for SOA? Are we looking at something that includes change management or business process models? Make sure that you all agree on the scope before you start. That's probably the number one point. Then, know where you're going to go from there.

The next point would be around flexibility. How much flexibility can you allow different groups to have to determine their own metamodel and to make sure that the taxonomies are similar? Are you going to allow a lot of flexibility there, or you are going to make sure it's more governed? There are business cases on both sides, but you want to have agreement upfront on what's going to happen there.

Those are the two biggest points. I can't think of anything else that would be on top right now.

Gardner: Hemesh, what sort of chapters would you add to that book?

Yadav: I agree with Harry on the first two chapters, but I'd like to add two more chapters that are close to my heart, especially around SOA governance. I'd like to define my end-to-end governance first, before I implement a service repository, so that I have a clear scope in mind and a clear metamodel in mind to capture the information.

The fourth item is to identify the key stakeholder and the role-based authorization in the system. I don't want to share based on the regulation discussion we had just now. We need to give a real emphasis on who can modify the information, who can access what information, and who can change the information. That way we know who really owns the data, and who is using the data. So, in chapter four, I want to define the key stakeholder, the librarian of the services, and their role and scope of influence in the repository.

Gardner: Could you finish up our discussion with a little case study on how you brought this about? How did you sell this internally? Both of you seem to feel strongly that this needs to be comprehensive, holistic, and top down, but that makes it more difficult to sell and get buy-in. Harry, how do you get that inclusion and everyone's buy-in?

Karr: We have issues constantly that point to the need for this type of solution. You have issues happen in production, and someone says, "Well, what changed lately?" People need to get that information quickly. It needs to be tied to the systems that were affected. Who is impacted by those changes. That's a very big part of it.

We've built a lot of services. Some of them are great services, and some of them we probably shouldn't have built. We didn't have the visibility to decide that upfront. We didn't have the governance in place to solve that upfront. So, there's a lot of waste there with any of those services. They had to be redone later, which affects the clients, and affects the systems of record in some cases. There's a lot of waste when we do that.

The next selling point we would have would be around regulations. It's a very big concern to the people making the decisions about the purse strings. In a lot of industries, but especially banking, the regulatory and auditory concerns are huge.

We need to look at those as not new. We've always had them, and we're going to have more, and so that's a big selling point. I can help you with the auditing and regulatory systems that will help you meet your requirements. That's a big selling point right there, because that takes up a lot of their time at the top levels.

Gardner: Hemesh, last word to you. How do you help sell this in terms of business value to a wider audience inside of your organization?

Yadav: I'll add to what Harry was trying to say. When I started selling the service repository, one of my key concerns was that if I can't show you what services I have or if I don't provide enough information to reuse the services, it's very hard for me to justify that you need to reuse my services. Service reuse cannot be achieved without implementing the centralized service repository.

The service repository, if you look at it from business perspective, provides more productivity, more agility, and speed to market, and it reduces the silos.

A real-world example is in interest rate services. Most banks have multiple channels. Each channel provides different implementation of the same services. When you try to put those services in to a centralized repository, you start getting feedback. "I have four services. " "I have five services."

Our business started getting the inputs that said by implementing a centralized repository, there is definitely a way to leverage a single service, and it reduces your maintenance cost, production cost, and also posting cost, and it provides a lot of market value and implementation agility.

Gardner: We've been discussing the role of SOA, repositories, management across complex business circumstances like mergers and acquisitions, and how to future-proof your business against complexity, regulation, and ability to manage across the lifecycle of services in IT, and as well as extending into business processes.

Here to help us understand these topics, and I very much appreciate your input, we've been joined by Harry Karr, IT architect at Wachovia. Thank you, Harry.

Karr: Thank you very much. I appreciate it, Dana. It's been enjoyable.

Gardner: Also, we were benefited by the presence of Hemesh Yadav, IT architect, also at Wachovia. Thanks so much Hemesh.

Yadav: Thank you Dana.

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

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

Transcript of a BriefingsDirect podcast on the role of repositories in data integration for large enterprises. Disclaimer: The views expressed in the podcast are not necessarily those of Wells Fargo & Co. or any of its subsidiaries or affiliates. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Enterprises Seek New Ways to Package and Deliver Applications and Data to Mobile Devices

Transcript of BriefingsDirect podcast on new ways to deliver data and applications to mobile workers using Kapow Technologies solutions.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Listen to related webinar. Sponsor: Kapow Technologies.

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 bringing more data to the mobile tier. We'll look at innovative ways to extract and make enterprise data ready to be accessed and consumed by mobile device users.

This has been a thorny problem for many years now, and the approach of Kapow Technologies in focusing on the Web browser on the mobile device has some really neat benefits. Kapow's goal is to allow data to be much more efficiently used beyond the limited range and confines of traditional enterprise applications and interfaces, when delivered out through mobile networks.

As enterprises seek to cut cost, while boosting real world productivity, using ubiquitous mobile devices and networks to deliver actionable and real-time data to business workers in their environment has never been more economical and never has made more sense.

Here to provide an in-depth look at how more enterprises and their data can be packaged and delivered effectively to more mobile users, is JP Finnell, CEO of Mobility Partners, a wireless mobility consulting firm. Welcome to the show, JP.

JP Finnell: Thank you, Dana.

Gardner: We're also joined by Stefan Andreasen, founder and chief technology officer at Kapow Technologies. Welcome back to the show, Stefan.

Stefan Andreasen: Thank you very much, Dana.

Gardner: We're also joined by Ron Yu, head of marketing at Kapow. Thanks for coming on the show, Ron.

Ron Yu: Thanks for having us, Dana.

Gardner: I want to take a look at the state of mobile applications and the need now to get fresh data out to the field. Why is this a time when the imperative economically and in terms of business agility has perhaps never been as acute or as important?

Let's take this to JP Finnell. You're in the field and you work with a lot of folks who are dealing with these issues. Why is this such an important time?

Finnell: I used to head up professional services for Nokia worldwide. Before that, I was with the Deloitte Consulting, Xerox, and Cambridge Technology Partners for Novell. So, in the past, I've really seen these cycles and adoptions of technologies a number of times, and mobility is different.

Unlike conventional applications, mobile applications have a huge number of choices to juggle. There are choices about input and output, touch-screen versus QWERTY. For example, we've seen that with RIM recently, where there is a lot of controversy with the Storm device versus the touch-screen versus the Bold. So you don't really see that dimension in the traditional adoption.

You also have the choice of the device platform. That's also quite different from your traditional choice of development options. A lot of choices have been holding things back, and companies like Kapow are making it much easier for developers to get on board. Hopefully, later on during this podcast, we'll touch on some of the other factors that are coming in place to make 2009 a year when we're going to see some [large scale] adoption of mobility.

Gardner: Now, this complexity has been going on for a long time, and there are many choices. Aside from what we can bring to the solution on the technical side, from your perspective, JP, what is pulling people to find the solution because of the real benefits of moving to the mobile tier and leaving the PC back in the office?

Finnell: There are a number of elements of suitability. When I was at Nokia, we wrote a book called Work Goes Mobile: Nokia's Lessons from the Leading Edge. According to Wiley Publishing, it's one of the top best-selling books on business mobility. We're seeing that need to be more responsive.

Business processes that really either are business to employee (B2E) or business to business (B2B) is where responsiveness and timeliness is really an issue. I'll talk more later about the application we did in the field for a major bank where we were able to take substantial cycle time out of the process. So, being able to be more responsive and doing more with less is the motto in 2009.

Gardner: Let's go to Ron Yu. What is it about data in particular that, at this time, can start to help these organizations be more agile and responsive?

Complex Legacy Systems

Yu: What we see within the enterprise is that the IT organization is really buried in the complexity of legacy systems. First and foremost, how do they get real-time access to information that's locked in 20- or 30-year-old systems.

On the other hand, there is a tremendous amount of data that's locked in homegrown applications through Internet portals and applications that have been adopted and developed through the years, either by the IT organization itself or through mergers and acquisitions. When you're trying to integrate all these heterogeneous data sources and applications, it's almost impossible to conceive how you would develop a mobile application. What we see IT focused on today is solving that data problem.

Gardner: And, what is it about being able to get to the data presentation beyond a full-fledged application that is attracting people nowadays?

Yu: The interesting thing is that Kapow is not a mobile company. The reason we're having this discussion today is because Kapow customers have actually brought us into this market. Because of how we have innovatively solved these real-time, heterogeneous, unstructured data challenges, customers have come up with their own ideas of how they can develop mobile apps in real time. That's what Kapow solves for them.

Gardner: Let's go to Stefan. Stefan, what is it exactly that Kapow is doing that these users have innovatively applied to the mobile problem?

Andreasen: Let's just go back to the foundation here -- why is the need for mobile application growing? It all started with the Internet and the easy access to applications through the Web browser. Then, we got laptops and we can actually access this application when we are on the road. The problem is the form factor of the laptop, opening it up at the airport, and getting on the 'Net is quite cumbersome.

So, to improve agility for mobile workers, they're better off taking their mobile out of their pocket and seeing it right there. That's what's creating the need. The data that people want to look at is really what they're already looking at on their laptop. They just want to move it to a new medium that's more agile, handier, and they can get access to wherever they are, rather than only in the airport or in the lobby of the hotel.

Gardner: JP, what's wrong with the way some of the other vendors and combination of hardware and vendor and service provider have tried to tackle this problem? Have they been using the wrong tools? Have they had the wrong philosophy? Why has this been so long in coming, and what's the alternative that Kapow and folks like you are putting together as solutions?

Finnell: Before addressing that question, Dana, I'd like to back up and to what Stefan was talking about use cases in airports, for example. We saw that in a use case for a major bank. This was a unique problem where it was a process that automated the capture of credit card data or credit card applications in particular.

You see these kiosks in airports, stadiums, and shopping malls. It's like in the airport, where there is really no power, and no connectivity. There's more of that today, but in football stadiums and shopping malls, it's still very hard to find a laptop solution that has power for eight hours and will have broadband connectivity. That was another unique use case, where there is a need for visibility and automation.

Gardner: I'd like to add to that too. It seems that there's a behavioral shift as well. The more people use smart phones, the more they're used to doing their email through a hand-held device. They cross this barrier into an always-on mentality, and they can't take time to boot up, set up, and charge the battery for a full-fledged PC experience. The expectation among people who start doing this always-on activity is that they want their data instantly wherever they are, whenever they are.

Consumers Driving the Need

Yu: Dana, that's a great point. Consumerization is an interesting market dynamic that is really driving more need for mobile apps. We, as consumers, are being wowed by the iPhone applications, the Facebook applications, and things that we can do in our private lives and in the social networking context.

When we come into the business world, we demand the same type of tools, the same type of access, and the same type of communication -- and we just don't have that today. What we see is the line-of-business knowledge worker putting a lot of pressure on IT. IT tries to respond to this, but dealing with the old traditional methods of technical requirements, business cases and things like that, just doesn't lend itself to quick, agile, iterative, perpetual-beta types of mobile application development.

Gardner: So, we have this growing dissonance between the expectations of the individual, the ubiquity of the mobile device and people's comfort level with it, and then the older approach and some of the solutions that have been attempted for mobile delivery which seem to be extremely expensive and cumbersome. JP, again, what has been wrong with the standards of the old methods?

Finnell: I wouldn't say it's wrong. I'd say it's incomplete. The approaches of these large platform vendors, and I am strategic partner in several of them, aren't strong, when it comes to agility, prototyping, and being able to accommodate this real-time iterative application development approach. That's really where Kapow shines.

Gardner: I've spoken to a number of developers over the years and they've likened this mobile issue to an onion where with every layer that you peel back, you think you're getting closer to the solution, but you just keep digging down, and there are more variables and more hurdles. Eventually, the cost and the delays have dissuaded people from pursuing these types of activities.

Stefan, what is it about Kapow that should help people become more engaged and actually look forward to developing in the mobile tier?

Andreasen: The answer is very simple. It's because we work in the world that they already know. If you want a mobile application, if you want agility, you want it in the world of applications that you're already working with.

If you're already opening your laptop and working with data, we give you that exact same experience on the mobile phone. So, it's not that you have to think, "What can I use this for?" It's about taking what you're already doing and doing it in a more agile and mobile way. That's what's very appealing. Business workers get their data and their applications their way on the mobile phone, and basically, it's making them more effective in what they're already doing.

Yu: Dana, the metaphor that comes to mind for me is not an onion, but it's really on a baseball diamond. When you look at Sybase and other independent software vendors (ISVs) that are selling platform and infrastructure, there are huge investments that you have to make.

To me, it's almost as if you are looking for that home run hitter, that Mark McGwire. I won't say Barry Bonds anymore. But there's a place to go for the home run, and to go for that large global enterprise deployment. With mobile apps, what we're seeing with our customers is that they want to hit singles.

They want to be able to meet the demands of a line-of-business department and to get that in their hands -- the 80/20 rule applies -- and get some experience and develop best practices and learning lessons about how they can iterate and roll out the next one.

I think Stefan is going to elaborate, when we talk about Audi, but Audi literally rolled out four mobile apps within the first week of implementing Kapow.

Gardner: Let's get into the actual solution. We want to solve these mobile data access problems. We're writing directly to XHTML. You refer to this as extract, transform and load (ETL) and then extension of data for Web data services. Help me understand technically what it is that Kapow is providing here.

From Laptop to Mobile

Andreasen: The best way to describe it is with an example. This is actually a real use case. Let's say I am the CEO of a big network equipment manufacturer. I go to the airport and I open up my laptop to see what are the latest sales figures. I have these applications where I can see sales data, performance, market changes, etc.

What's unique with Kapow is that you can go then to the developers and say, “Hey, look at this. This is what I want on my mobile app -- on my mobile phone.” And, they can get the data from the world of the browser, turn it into standard application programming interfaces (APIs), and get it through any mobile devices.

Just to give you an example of what we did there. With three hours work, we developed a mobile XHTML application for Blackberry that gave the dashboard that the CEO needed. That shows the power of Kapow right there. The alternative approach would be three months of development and probably $150,000 of cost.

Gardner: What's required in the handsets to be able to access what you're describing?

Andreasen: Handsets today are getting more and more browser enabled. So, of course, if you have a browser-enabled phone, it's very easy to do this. You can write just in XHTML as you've mentioned. But, a lot of companies already have like a mobile infrastructure platform.

Because our product turns the applications into standard APIs, standard feeds, it works with any mobile platform and can work in the devices that they support. You basically get the best of both worlds.

Gardner: How do we get over the hurdle of applications that are developed for a browser on a full-blown PC, where there's quite a bit of visual graphics and images, but we want to boil that down into really text and numerics. What is it that you bring to the table to solve that problem?

Andreasen: We recently had a webinar, and we asked what are the biggest challenges that people have. The number one challenge that came out of it was standard access to data, and that's exactly the problem we solve. We allow you to very, very quickly -- almost as quickly as it would take to browse an application once -- turn an application to standard API. Then, you can take it from there to your mobile phone or your mobile applications.

Gardner: People, of course, can deploy with virtual private networks (VPNs) and use a variety of secure socket layer (SSL) or other authentication, so that this data and this delivery to the mobility tier remains secure, and access privileges are maintained.

Andreasen: Exactly. We basically leverage the security mechanisms already in place. The benefit with Kapow is that you don't have to re-write anything or get any new infrastructure. You just use what you already have, because you aren't working with the data. You just do it in the mobile way you want to work with, and we allow you to do that.

Yu: What's powerful about Kapow is that we have an integrated development environment (IDE) that basically allows the IT architects to service enable anything with a Web interface, whether it's a homepage or an application. The power of that really is to bring the knowledge worker or line of business manager together with the IT person to actually develop the business and technical requirements in real-time.

This helps perpetuate the beta development of mobile applications where you don't have to go through months and months of planning cycles, because we know that in a mobile world, once you've gone one or two or three months past, the business has changed. So, as Stefan was saying, the ability to develop data applications for mobile in a matter of hours is powerful.

Gardner: Let's go to JP again. Give us a sense of what types of content and data have been the first to be deployed and delivered in such a fashion. What sorts of developers are the most ready to start exploiting these capabilities?

Funding Requires Business Case

Finnell: Dana, we're not seeing most projects get funded. Where the traction is today is where the projects are getting funded. Projects don't get funded unless there is a business case. The best business cases are those where there's a business process that's already been defined and that needs to be automated. Typically, those are field-based types of processes that we are seeing.

So, I'd say, the field-force automation projects, utilities or direct sales agents, are the areas where I'm seeing the most investment today on a departmental level.

Also, to echo what Ron was saying, you need to go through that prototyping or iterative phase. For example, we had these utility technicians in the field, several hundred of them. Initially, we designed the screens to be scroll down. An alternative user interface (UI) for that was actually to have a screen for each question. Once they answer the question, they hit the next screen.

Unlike a pure Web application, where you want to have a scroll bar and you scroll down and answer every one of 10 questions on a page, the technicians much preferred to have one question per page, because of the form factor. That only was discovered as a result of the prototyping. So, that's another example.

Andreasen: And it's a good example of exactly what Kapow can do. If you have an existing Web-based application with 10 questions on one page, you take our product, pull it into our visual IDE, and turn it into an API service-oriented interface. Then, you can put a new UI on that, which basically asks one question at a time and solves exactly the problem that JP is referring to.

Gardner: This strikes me something that's going to be even more important, as organizations adopt more software-as-a-service (SaaS) applications and as we see more of SaaS providers deliver their applications for both a PC browser experience as well as a stripped-down mobile one.

We're already started to see that on the social networking and consumer site for users of iPhones or iPod Touches. It's going to be interesting to see if a field mobile warrior is going to be accessing this information through the SaaS provider, while they wouldn't be able to in the on-premises applications that are delivered through the enterprise.

It's almost as if the SaaS world is going to drive the need for more of these types of interfaces in the enterprise environment. Does that make sense, Ron?

Yu: Yes, absolutely. Once again, there's this whole notion of completeness that JP mentioned earlier. The SaaS vendors, the Salesforce.coms are going to be focusing on building out their applications. But, at a company level, at a departmental level, we're going to have unique requirements that Salesforce will not be able to develop and deploy in their application in real time.

Yes, they have the application, the AppExchange. And, you have access to Force.com, and you can write your own apps, but, once again, you're talking about software development. With Kapow, we completely leapfrog the need to actually write code. Because of the visual-programming IDE tool, you can actually work, as Stefan was saying, at the business logic level. You work with the interfaces that you know to service-enable your data and roll out apps in real time.

We see this is as enabling and empowering the IT organization to take control of their destiny today, as opposed to waiting for funding and cumbersome development and planning processes to be able to scope out a project and then to write code.

Gardner: Because of Kapow's heritage and the fact that it's been doing Enterprise 2.0 activities for a while now, it seems that, as the developers have become attuned to thinking for the mobile tier, they can, in a sense, develop the application once to then appear anywhere. Is that starting to happen, JP, in the market?

Juggling Mobile Choices

Finnell: One thing that's unique about mobility is the degree of fragmentation. As I mentioned before, there are a lot of choices you have to juggle, not just the device, but actually the platform. You have WIN Mobile, Symbian, UIQ -- which I understand filed for bankruptcy today -- RIM, and Palm. So, there are a number of device platforms, and then you have development options: mobile browser versus SmartClient, J2ME versus .NET.

Stefan and Ron could probably talk about some case studies that they have been seeing in terms of write once-run anywhere.

Gardner: Let's look at this same question, but through the lens of case studies. Now, you've got users like Bank of America, CNET, Audi, Visa, Intel. Tell us about some of these use cases and also if there has been a write once-run mobile, as well as through traditional interfaces.

Andreasen: Let's talk about Audi. It's one of Kapow's largest customers. It's very Web-enabled. Actually, we see that most companies are getting Web-enabled. Audi has a big intranet with a lot of applications.

One application, for example, is for the manager on the assembly line. He can monitor where cars are in production, where they are in the assembly line, and their status. He's walking up and down the assembly line and his laptop is probably in a different office. So, going back and forth to work on his application is very cumbersome.

One of the first things we did for them, as Ron said early, was build four mobile apps in the first week. We took that intranet application and mobilized it, so that the assembly line manager could actually stand right there in front of the car, pick up the phone, and access the entire application. This is an example of the same application existing both as a traditional browser application and as the mobile application.

The interesting thing here is that Kapow enables you to leverage what you already have, the Web browser application, and reuse and repurpose that into a mobile application in a very, very short time, as was just described.

You can take the equation further, if you're going to an entirely new application and you want output in both media. The key is first to get your data in a standard interface and then build on that. That's where you use Kapow. Get the data in a standard interface and then you can build it out for different media as needed.

Yu: Dana, would you like to hear about the iPhone app that we built for Gartner?

Gardner: By all means.

Andreasen: We just attended the Gartner Application Architecture, Development & Integration Summit (AADI) in December. They have a very neat website where you can go and check their agenda. You can also walk around with "the bible," this big book, and see what's going on.

Let's say I'm sitting in a presentation and say, “Wow. This is boring. What's going on right now that I'd rather see?” What you really would like to do is take out your phone, click a button right now, and the rooms and what things are going on now.

So, together with IBM's Rational solutions, we built a mobile version of the Gartner AADI agenda. Using Kapow, we turned the existing Gartner agenda website into a standard feed, and the Rational guys built an iPhone application on top of that. And we are promoting that.

It became a big hit at the show. All the Gartner people loved it. Virtually, you could build your own agenda. You could push a "Now" button, when you were in a boring presentation, and you could walk somewhere else. We got all the benefits of mobility with just two or three hours of total work, and for thousands of people.

Yu: Dana, the most amazing thing about this is that Stefan and I had a conversation on Thursday evening in preparation for a mobile analyst meeting that we were going to be having at the show.

We said, “Wouldn't it be great to walk into that briefing with an iPhone app?” And, Stefan said, "Great." So, in the evening, he spent an hour-and-a-half to create this service feed and he contacted our partner at IBM. In an hour-and-a-half, they used their tool and developed that application. It was just phenomenal. Stefan, why don't you talk about the interactions that you've had with the IT folks at Gartner?

Andreasen: The IT folks of Gartner, of course, were amazed that we could actually produce this and they could see how popular it became. I ended up having a meeting with them, and we're talking with them right now. Actually, if anybody want to see this application, we have it live running on our website under the Mobile Solutions page. So, please feel free to go there and check it out.

Same-Day Development

Yu: This is really a perfect example of how the enterprise in 2009 will operate -- the ability to wake up one day and to have a line-of-business or an IT person, conceive a mobile application and to be able to deploy it within the same day. It's powerful and, hopefully, we'll see more examples of what we did for Gartner within global enterprises.

Gardner: This also raises another issue, which probably is sufficient for an entirely separate podcast, and that's the juxtaposition of this sort of data with location and positioning services. Perhaps at a conference not only would you want a room number, but you might be able to get directions to it and be able to juxtapose these services.

Quickly, to anyone on the panel, what is it now that enterprises should consider, not only delivering this data out to a mobile device, but juxtaposing it with location services and what that could offer?

Andreasen: I think there's a more fundamental question. Can we leverage different sources of information into the same application. If we just go back to the Gartner thing, I could pull out the name of the room, but I didn't have a map on the Gartner side. The hotel itself, of course, has a separate website with hotel information, maps, and everything.

We could actually use our product and service-enable that as well, combine the two, and get a new mash-up mobile application, where you leverage the benefit of multiple applications that couldn't even work together before. That's one answer to that question. You can now combine and mash up several applications and get the combined efficiency.

Gardner: That strikes me as the real return-on-investment (ROI) benefit, because not only are you justifying the cost of delivering the data, but you are able to then use that data for much higher productivity, when you do these as a mash-up. That's really important in our economic climate -- basically 2+2 = 6 -- and that's what I think we're talking about here.

Andreasen: Exactly. Today, people have to look at different places on their paper and, in their mind, combine things. That's what you can automate and create a lot of efficiency.

Gardner: We're almost out of time. What does the future portend for Kapow and some of these mobile services? Is there a road map for improving the breadth and scope of the solution? Once again, I'll throw this out to anyone on the panel.

Andreasen: There is one thing that we're doing, you mentioned as earlier, with SaaS. We launched Kapow OnDemand half-a-year ago and we can see that that's driving a lot of mobile business. So, now we can use our product, not only for on-premises solution, but also in the cloud. We see that as a major driver in our road map to support that.

Yu: The other thing is that I think it's pretty clear now that, from our perspective and from JP's perspective, there are no clearly defined mobile applications. We see the ISVs and IT organizations focused on security and infrastructure.

But, really, beyond email there hasn't been one killer app. I think that tells a story that every enterprise will have their specific mobile apps that they are going to roll out. At Kapow, we will continue to mobile-enable IT organizations to be able to roll out applications as quickly as they can conceive them.

The other part of that is that we will continue to focus on partnering. At Kapow, we will not be a mobile ISV, per se, but will continue to partner with the platform providers to help drive more adoption of mobile.

Gardner: JP hit on this little earlier when he was focused on the business process. Perhaps we're not going to see mobile killer apps or killer mobile apps, but killer business processes that need to have a mobile element to them.

Finnell: That's right, and there is something that I call "strategy emerging from experience." The best way to get adoption in your enterprise is to rapidly iterate at the departmental level, gain experience that way, create centralized governance or coordinative governance that captures the lessons from those, and then become more strategic.

What I am seeing in 2009 is a good experience space. Almost every enterprise today has at least one department that's doing something around mobile. One way to get that to be more strategic is to be more iterative with your approach.

Gardner: Well, great. We've been talking about delivering more content and data out to a mobile tier, but without some of the pain, expense, and complexity that's been traditional in these activities. We've been joined by a panel of JP Finnell, CEO of Mobility Partners. Thanks so much for joining.

Finnell: Thank you.

Gardner: We also had Stefan Andreasen, founder and chief technology officer at Kapow Technologies. Thank you, Stefan.

Andreasen: Thank you, Dana.

Gardner: Also Ron Yu, head of marketing for Kapow. I appreciate your input, Ron.

Yu: Thank you, Dana, I enjoyed the discussion.

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

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Listen to related webinar. Sponsor: Kapow Technologies.

Transcript of BriefingsDirect podcast on new ways to deliver data and applications to mobile workers using Kapow Technologies solutions. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.