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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment