Thursday, January 22, 2009

Case study: IT repositories help Wachovia manage change amid complex bank consolidation

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.

Read a full transcript of the case study discussion.

When large businesses need to change fast, the IT systems need to do more than keep up with change -- they need to manage, define and secure it. IT repositories are now effectively orchestrating multiple enterprise systems of record that must quickly operate together as result of massive mergers and acquisitions.

Using such repositories, or groups of repositories, IT and business assets can be quickly federated and integrated for business process alignment and consolidation. Furthermore, these processes can be managed centrally via policies and governance definitions, even across far-flung global operations.

To better understand the value and opportunity in using IT repositories to manage change in complex business environments, I recently discussed a case study at Wachovia, which is now merging with Wells Fargo. To help understand the role of repositories amid this merger, I spoke with Harry Karr and Hemesh Yadav, both IT architects at Wachovia.

Here are some excerpts:
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.

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.

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.

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.

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.

In production and 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. ... 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.

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.

[The repository solution] 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.

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.
Read a full transcript of the discussion.

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

Disclaimer: The views expressed in the podcast are not necessarily those of Wells Fargo & Co. or any of its subsidiaries or affiliates.

Wednesday, January 21, 2009

Services consumers and developers must now mount pressure for cloud computing neutrality

Sure, most people instantly get the need for network neutrality, but what about cloud neutrality?

Just like we'd be loathe to tolerate any one (often the only available) Internet provider from qualitatively managing our traffic and packets use based on their singular business objectives, we should also be concerned about any cloud provider exerting too much influence or setting de facto standards early on that diminish the cloud services market as a whole.

Now, the Obama Administration has enough on its plate, so I'm not advocating any regulatory or commerce enforcement policies to define or advocate cloud neutrality. But I do think it's important to foster an open market and encourage early adopters -- especially developers and independent cloud services providers -- to vote mindfully with their participation (and dollars) to establish and nurture broad openness and interoperability practices among the burgeoning cloud entities on the Internet.

If an open Internet has been good for sustained productivity and innovation, which few refute, why wouldn't cloud services also benefit from an open market environment -- at least through a formative stage (or two)? Wouldn't what's good for the popularity of the pipes also be good for promoting the widest consumption of the water?

Let's still favor the advance of general productivity on the Internet over more narrow commercial interests, even as we enter the cloud services phase of the Internet, eh?

Shouldn't a network infrastructure often described as "public" -- hence the common icon of the Internet as a puffy cloud -- become the substrate for an intensely fertile marketplace, and just not a handy subsidy for any number of, albeit competing, roach motels? The best form of competition comes from the hotels competing but also with low barriers of entry and exit over a long period of time. Choice is essential, not just among vendors but on how those vendors behave as a group.

The cloud services marketplace is not just a new Monopoly board in the sky, it's still the product of the World Wide Web. If you have to go through the cloud to reach the services, then the services themselves are a product of the cloud, and not the other way around.

Things in the nascent cloud services ecology are moving rapidly, so now's the time to set the proper perspective on what works best for the buyers and users of cloud services, as well as the commercial interests setting up shop along the Information Superhighway. Remember that metaphor for the Internet? I think we should think of a cloud superhighway in the same way. Now it's more than information, but it's just as or more important to the public good. There's a public interest in seeing this succeed for the highway travelers, which include big businesses, as well as those few building the toll booths.

There are some dramatic recent developments that point to how rapidly cloud things are shaping up:
  • IBM's Lotus brand is bringing a lot of what we know as Notes/Domino services, a longtime enterprise groupware leader, to cloud-based delivery. Think of it as a big nest of .nsfs in the ether (and that's data up there, folks!).
  • Engine Yard's Vertebra has extended cloud neutrality into its Ruby and Rails development and deployment solutions. Write anywhere, run anywhere, change anywhere, integrate anywhere ... repeat.
  • Sun Microsystems buys Q-Layer. Let's hope that Sun gets cloud "open" from the start this time, unlike the 12-year Java will be open someday saga (and keep those license fees coming).
There have been warnings about a potential and troubling lack of choice in cloud options, notably from Richard Stallman. And there have been major movements by vendors not known for their allegiance to openness first and profits later, including Apple and Microsoft, into the cloud model.

So even though things are moving fast and at the most impactful levels of the global IT business, there's very little being said and done about preserving the neutrality of the Internet economy for the cloud economy. And I know it's hard to actually define neutrality. But like pornography, I know it when I see it.

Better yet, I know non-neutrality when I see it. We should all be on the lookout for non-neutrality in the cloud ecologies, and seek and reward alternatives. Blog about these distinctions. Look to the decades-old Internet example for guidance. It really worked and keeps working.

That does not mean in any way outlawing good old fashioned capitalism in the cloud ecosystem. It means making savvy choices that favor data portability, and recognizing that APIs that carry over from one hosting provider to another make for good market drivers that entice more consumers that can exercise more choice. The pie needs to grow first, and the market leaders can seek domination in some way later when the playing filed is established and perhaps somewhat level.

Enterprises and small to medium size business especially should advance their long term interests as they examine and adopt cloud-based services to make sure they are not trading short-term savings in a recession for long-term IT lock-in. Once you're in the roach motel, you can't get out. And they can raise the rent (maintenance fees) to just below your cost of exercising painful choice for a long time. You may be familiar with this IT supplier dynamic.

There is a better path, and we've seen it with the Web: A modest, market-driven level of mutually beneficial interoperability of services and applications, data portability in its deepest forms, SLAs that clearly spell out the terms of engagement and what is acceptable in terms of services and data ownership.

These cloud terms of engagement will be tough and complex. We're in some uncharted territory here. Can you own a business process even if the cloud provider owns the constituent services? Yes, I believe you can, and should. Get it in writing, though.

So more than any regulations or broad policy dictates on the best practices for cloud computing, we need good licenses and a clear and understood framework for cloud ecology best practices that protects the users and developers, as well as the providers. The goal is to make strong enticements for all the participants in the ecology, not just a few or in a grossly inequitable way. We'll need escape clauses, too, just in case.

Indeed, the value and probity of cloud use licenses must be weighed against the IT total cost equation, including the cost of switching and the costs of integration. That is, if I get cloud services cheap, how much will that cost me in the long run? And is this and does this become a better deal than the traditional on-premises, per processor or application licensing models?

In short, we need the ability to calculate the cost-benefit analysis of modern IT that includes the new cloud computing options. And therefore we need to know the true costs of cloud computing -- including how open it really is -- to proceed. The more open, the less risk, and so the more overall adoption based on an understood cost-benefit projection.

Let's look at cloud services as hugely promising, perhaps the best alternative for IT resources and support for a number of applications types and certain business use cases. But let's not get lulled into treating a cloud provider relationship any different from any other business deal. Let's get the terms down, and vote well as consumers. It's in the best interest of the vendors, too, they just can't do this without us. Literally.

Let's leverage the fact that the Internet has set a powerful and essential precedent that upholds and protects an online market's open development as fundamentally more important than any one company's ability to stake out a claim and horde all the gold dust. Open markets are the best way to allow the miners, prospectors, shovel sellers, and real estate interests to all grow and prosper. And openness will allow the cloud market to reach its full potential fast, through unfettered innovation from all quarters.

Like with the Web and Internet over the past 15 years, the power of choice and unfettered innovation and dynamism of sufficiently neutral cloud markets should be the best guide of how the cloud future shakes out productively. In this economy we really need a new and huge productivity boost from IT lest we all get pulled into the downward spiral.

Tuesday, January 20, 2009

Enterprises find easier ways to package and deliver applications and data to mobile devices

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

Read a full transcript of the discussion.

Bringing more enterprise data to the mobile tier has been a thorny problem for many years now. A logjam remains between developers and their ability to productively deliver enterprise applications and data to mobile devices, such as cell phones, PDAs, and smart phones like the Apple iPhone.

To develop applications that reach even a small number of major handset environments means big-time custom plumbing, from the various data sources, to the mixture of networks, to the choices on integration, to the various security needs, to the many user interfaces and mobile client operating systems. Managing all these variables requires a high degree of skill across many different skill sets. There are not many developers that fit this bill in your average enterprise.

But new and innovative ways are emerging to extract and make enterprise data ready to be accessed and consumed by mobile device users. Kapow Technologies, for example, is focusing on the Web browser on the mobile device to allow data to be much more efficiently delivered via mobile networks beyond the limited range of traditional enterprise applications.

To gain an in-depth look at how more enterprises and their data can be packaged and delivered effectively to more users, I recently spoke to JP Finnell, CEO of Mobility Partners, a wireless mobility consulting firm; Stefan Andreasen, founder and chief technology officer at Kapow Technologies, and Ron Yu, head of marketing at Kapow.

Here are some excerpts:
Unlike conventional applications, mobile applications have a huge number of choices to juggle. There are choices about input and output, touch-screen versus QWERTY. ... You also have the choice of the device platform. That's also quite different from your traditional choice of development options.

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 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.

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.

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.

[The traditional mobile application development methods are] 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.

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. ... 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.

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.

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.

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.

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.

Where are the mobile apps cropping up? 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.

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.

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.

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.
Read a full transcript of the discussion.

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