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

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

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

Read a full transcript of the case study discussion. Find it on iTunes/iPod. Learn more. Sponsor: Hewlett-Packard.

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

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All