 SOA governance, your questions answered. I'm Chris Harding, the Open Group Director for Interoperability, and part of my responsibility is to support our members' work on SOA, including the work that we have done on SOA governance, which resulted in the publication of our SOA governance framework. The purpose of this webinar is to give those of you who are participating the opportunity to ask questions of the panelists and to discuss those, for the panel to discuss those questions relating to SOA governance, and in particular the SOA governance technical framework of the Open Group. Now, I have a tutorial on SOA governance, which I can keep as a background information if we need to look at specific points on the governance framework. I see we have on our panel Bob Laird from IBM, who is something of an SOA governance expert. Some of his ideas were major factors in the SOA governance framework that the Open Group produced, and he has also authored other books and works on SOA governance. And we have Jed McSuba from Accenture, who is a governance expert who has been involved in using SOA governance, and Dave Hornford from Conexium, who is the chair of the Open Group Architecture Forum, and also has some experience of applying governance to SOA projects. I will give a brief introduction by extracting some of the material from this tutorial to the topic of SOA governance and the Open Group SOA governance framework, I should say. And can I ask people if you have questions, please to submit them online using the WebEx Q&A facility. I see we don't have any technical questions yet, so let's proceed with the introduction part of this webinar. SOA governance is a means for establishing and enforcing how people and solutions work together to achieve organisational objectives, and it provides the framework for planning, developing, deploying and managing an SOA solution. It has benefits of ensuring alignment, establishing controls, reducing cost over time and mitigating risk. SOA governance does not stand by itself, but it's part of the overall enterprise governance regimen, and it extends IT and enterprise architecture governance to ensure that SOA is governed properly. The SOA governance framework is really concerned with three things, the people, the processes and the technology, and roles and responsibilities of the people and the organisational structure, the governing and the governed processes, and the technology infrastructure and tools. The SOA governance framework defines an SOA governance reference model containing guiding principles, roles and responsibilities, some process material and some technology descriptions. And this model is used as part of the overall SOA governance framework, and the key attribute of this framework is vitality. So the SOA governance reference model is the starting point, and taking that as the basis, you use the SOA governance vitality method to develop a customised and focused SOA governance regimen for your enterprise, and this is not just a one-off process because the governance vitality method goes through a cycle of plan, define, implement and monitor, and that cycle should be repeated to ensure that the SOA governance regimen of your enterprise is up-to-date and vital. So the key governance guiding principles defined in the framework, these actually are example governance guiding principles, so I will skip over them. This slide shows an example again of governance roles and responsibilities in the context of the example company. The SOA governing processes include compliance, these are the three processes defined by the framework, compliance, dispensation and communication. Compliance is the mechanism for review and approvals. You have to have a dispensation mechanism in case that compliance mechanism is too rigid, particular cases, and key to the governance process is communication, to educate people about SOA governance and to communicate what it is they need to do. Here are some examples of how those processes might apply in particular context, and again further examples. Now this slide shows the SOA governance processes and these really can be viewed of the SOA on two axes, the solution versus service and the planning versus design and operational axis. And there are basically four processes, solution portfolio management that ensures you have the right portfolio of SOA solutions. Service portfolio management that ensures you have the right portfolio of services. The services are what your SOA solutions are built from, and then the life cycle processes in the solution life cycle and service life cycle management processes. And those at the top of the slide are shown as the key governance processes. At the bottom of the slide there's a slide expansion that shows how they relate to each other. And these again are showing how this applies in the context of the example. The vitality method, as I explained, is repeated. It's not sufficient to simply define a governance regimen and leave it, particularly for SOA. It is important to keep it up to date as circumstances change and the cycle consists of planning, defining, implementing and monitoring your governance regimen. And this summarizes what we've been over, what SOA governance is, how it relates to other governance structures because SOA governance is not standalone. It is in the context of enterprise and IT architecture governance, and we've looked a little at what high level governance structures and processes need to be put in place. And from this, the conclusions of all this, governance is the means of ensuring that enterprise operation aligns with business goals. This is crucial. The whole point of all this is to make sure that you're aligning with the business goals of the enterprise. Good governance is needed if SOA is to realize its business potential. This is crucial. And the SOA governance framework of the open group includes an SOA governance reference model that describes the processes, organizational structures and enabling technologies for SOA and a vitality method that enables you to customize these to produce the customized governance regimen for your enterprise and to update this over time to keep it relevant. And good SOA governance enforces continued compliance with an enterprise SOA reference architecture. So that really is a summary of what the open group SOA governance framework is about. And I suggest we now move into the discussion phase of this webinar. And I'll start by asking the panelists to put forward their questions on this and to kick the discussion off. But again, please, for all participants, as you come up with questions, put them forward on the Q&A facility of this session. Okay, so perhaps we could start, Bob, your perhaps the primary SOA governance expert amongst us. Do you have any comments to make on that overall summary? Any questions that come out of it for you? So thank you, Chris. And I'm not sure I deserve that accolade, but I'll have to deal with it, I suppose. One of the common questions and concerns for people on SOA governance that you typically hear about is where do we start? So it's great that there's now an open group reference model and a vitality method. But those are guidelines as to how to structure your governance. So the answer, of course, is it depends, but that seems a bit too disingenuous. So I think in general one of the really good areas to start in governance is to look at your development methodology and your governance around that. So most everybody has a very good service development life cycle and there's at least some sort of governance around it, maybe peer reviews. Maybe you may have some level of architectural reviews, something of that nature. When you make the transformation from systems to services, things are a little bit different. The concept of the contract of the service, i.e. the specification, is very important in a SOA-type governance environment as opposed to an IT-type governance environment, more important at least. And so identifying what the state transitions are in your service development life cycle and what the control points are around those who needs to approve, who needs to review brings a level of discipline and specificity to your governance that, or at least to your SOA governance that perhaps you haven't had before. In addition, it's something that we, especially in IT, are comfortable with. We've had experience dealing with, again, the service development life cycle. There's been some level of governance hopefully around that. And so it's not too much of a leap to then say, okay, so what are the things that we have to do from a SOA governance point of view in your development life cycle? What are the, again, the states? What are the control points? What are the things that we have to do in order to ensure quality in our services? And some of that can be more difficult than others, especially in my experience I found dealing at the front end with requirements for services, particularly non-functional requirements, and then also dealing at the back end with our handoff to production operations and having the appropriate kinds of governance checklist. Nevertheless, it is an area that we hopefully have had some experience before with, and so it's not too much of a leap to try and get good governance going in that respect. And then the other area that I would say is a good place to start. Chris touched upon organization. Typically, we're moving from a stylo-type environment for our systems, development to a more shared environment, more horizontal environment for our services. And so consequently, your organization needs to evolve into having at least some groups that are more horizontal. Specifically, there should be some sort of shared services architecture board, architecture review board, whatever you want to call it. And then at the more executive level in order to provide guidance and prioritization and that sort of thing, there should be some sort of executive board, executive review board is sometimes used. And then associated with that, Gartner used the term center of competency, you will see center of excellence, some sort of group that is responsible for providing adult supervision across the organization and to identify the things at a more macro level that makes sense. So I think if you focus on those two things and start to develop a level of expertise and confidence in terms of your service development lifecycle, the governance around that and then what are the horizontal organizations, that's an excellent start. Thanks very much, Bob. So that's a good introduction to getting started with our governance. Dave, I wonder if you could comment on, first of all, perhaps you could give a little background on your involvement with SOA governance and related projects. And what are the issues that you've found when trying to put a SOA governance regimen in place? Certainly, Chris. My background is I'm a consultant. I run an organization that is focused on helping architecture teams be effective. And in the SOA space, the vitality method that Chris has talked about and Bob talked about are key, particularly when you go and look at the image that you had of Chris which looks at the interaction between solutions portfolio, service portfolio, solution lifecycle, and service lifecycle. Can you flip back to that one? The key element for us as an organization who helps architecture teams become more effective is helping them understand the distinct elements that operate differently. And the governed processes, originally people look at this and they go, oh, I have to do so much work. I have to worry about my portfolio. I have to worry about my services. I have to worry about my solutions. The answer is you do because if you do not do good governance, you are going to get almost none of the benefits of good service oriented architecture. The reusability, the agility, the ability to reconstruct elements of your business aren't possible if you can't manage that lifecycle. And the key element here, particularly if people want to go down a loosely coupled path, is your contract must have terms of change. What is the offering and when are the terms of change from the offer of the service? The other element in terms of an implementation that is governed that we've found is absolutely critical in a loosely coupled is the testing paradigm needs to be adapted so that the services being consumed have to fail predictably. Because if you're loosely coupled, you're maybe consuming services that you're not interacting with the service provider, how will you tell when you're orchestrating something that the overall SOA solution is working properly if you cannot test for predictable fail? Those are the key elements that we've found in terms of using and is being very clear that the portfolio and the lifecycle need to be considered and absolutely critical is the contract. Any basic questions from there? Before we take further questions, I'd like to give Jed a chance to comment in a similar way on his experience with SOA governance and issues he sees with the governance framework. Sure. Thanks, Chris. So I've been involved with designing and implementing SOA solutions since the early 2000s and I guess if you want to include some of the core board work I did back in the late 90s, I've been thinking about this for a while. I've had I guess the, I don't know if it's a pleasure, but the fortune of implementing, designing and implementing services in large organizations where SOA governance both existed and where it didn't exist. I think one of the key learnings that I've had over the years in seeing those two scenarios is an organization can and many follow this pattern where they absolutely can do web service development without having SOA governance in place. However, one of the key messages that we need to communicate to our customers or our business partners is if they really want to achieve the maximum value that SOA really can bring to the table, then a SOA governance framework is absolutely critical. So many times in helping my customers roll this out, it's really around communicating the value of SOA governance. Probably not surprisingly, governance is viewed kind of uniquely in many organizations, especially by the development community where they see governance as being unnecessary overhead. A couple points to that is that the governance is meant to add value. So it's the constant change management and the communication mechanism to say that what we are implementing when we roll out a SOA governance framework is really intended to add value to your organization. It's to ensure that you're designing services, service interfaces, and implementations according to best practices and standards that you're ensuring that the services themselves deliver maximum value to the business, that the services themselves are able to be shared across the organization. So it's very much a change management communication as it is anything. So any questions on that? We have one question from Rude Romans who is asking, and all three of you have talked about why SOA governance is crucial and what are the things to do to get it set up. The question he's asking is what are the common pitfalls when setting up or executing SOA governance and how best to overcome these? What are the things that you've observed that people, the errors that they might fall into and how do you make sure that people don't make those mistakes? So this is Bob. I'll go first. So one of the common pitfalls of governance, and I think Jed and Dave both alluded to this, is that if governance is too difficult or it's not adding value, people will stop using it, will work around it, will ignore it. And so to the extent that you can automate your governance and make it easy to use and show that it adds value, that's a good thing. I talked before about the service development life cycle, and one of the things that you can do is to read that you could say, automate your development governance, perhaps be able to run your code, your programs through a machine that would check with your development policies and indicate to the developer where they have an issue, then governance almost becomes fun. It becomes relatively easy to do. And then I think the other thing is that what tends to happen a lot of times is governance flounders upon the rock of groups having to work together and siloed organizations are not used to working together. They may regard the other organization as the enemy. And so it's impossible to overcommunicate. So to the degree that you can replace fear and be in doubt with round-bag lunches, talking about the plan, with communications that identify what's going on with one-on-one, with seminars that talk about the technology, anything you can do to help communicate among the different groups that are having to work together now is a good thing. Dave or Jed? Sure. Comments right to that? Sure. And this is Jed. And from my experience in terms of common pitfalls, I think many of them were just captured. But one other thing is making sure that you're starting at the right level. So within the governance framework, there's a pointer to the silo maturity model. So one of the things that certainly in my experience, and I would recommend that you don't want to do, is you don't want to overburden the organization with unnecessary governance. I mean, the framework itself is very robust. There are many different parts to it. But what's key is to understand really where the organization sits from a maturity standpoint, and you're tailoring the governance framework to be specific to their needs. Again, depending upon where they are in the spectrum, they may be dealing with really fundamental basic issues, like not having a common service development lifecycle, but that you can pretty easily go in there and very concrete deal with that. If they're at a nation stage and they have organization issues, while very important going in initially, that may not be an area that you really want to focus on too strongly. So I guess the message is just making sure that you tailor it to the customer's needs or your needs of your organization as opposed to just taking the framework itself holistically and just putting it in place. Thanks, Jed. Dave, anything to add to that? Well, first off, Bob and Jed were right, and the second unique ad that I'll bring in is people need to be very clear about distinguishing between a management process and a governance process and not blurring the line between the activities undertaken to manage something and manage an activity, manage a development activity, manage a change program and governing it. The second aspect for me is absolutely critical of understanding the distinction between when you are loosely and when you are tightly coupled. Because if what we're doing is building web services and calling it service oriented architecture, but all of our web services are tightly coupled, unorchestratable, unisolatable activities, and we're using web services as an integration tool, that governance activity is no different than how you would govern any other tightly coupled development activity. When we move to the area of our services actually existing and can be orchestrated and can be consumed, we're in that place that Jed talked about where we're now having organizations that are not used to working together. Somebody I don't know of in my organization is consuming my service. Somebody who is external, a question we'll probably get to on consumerization and mobility, is consuming my service. And in that space, our governance becomes absolutely critical around what is the life cycle of that solution and that service so that we can deliver predictability. Because if our services, because we're not used to working together and we're following a tightly coupled operational model, and that any service that is provided will never succeed in the transformation and the goals that we're looking for, because I can't rely on it being predictable. And the goal of the whole governance and life cycle management is ensuring predictability for things that you're just going to reach out to and consume. I can't stress enough in our experience where we see people again and again fail because the services are not predictable, because they are carrying forward activities that are applicable to tightly coupled operational models. Chris, this is Bob. I have one other thing to add, and I certainly agree with what Dave just and Jed talked about. Broadly speaking, SOA is, and again, this is a very macro level, so take this with a grain of salt, but you're really talking about SOA at two levels. One is more of a technical level where you're concerned about the SOA principles and whose coupling and development cycle and that sort of thing. And that's typically where we see SOA start and SOA governance start. The second level is more at a more business level where you're trying to do engender agility. You're trying to use your services in a fashion that helps you create that agility in the organization. And I think in that latter, more business-focused, agility-focused SOA, change management, which is while important at the technical level, becomes even more important at the business-focused level. And there's a guy from Harvard named John Carter who has written a wonderful book about leading change and change management that I urge everybody who is really interested in governance and leading change to get a copy and read. But in it he talks about the eight steps that you have to go through in really leading change. And at the end of the day, that's what SOA and SOA governance is about. SOA governance ends up being to some degree adult supervision over the organization, and it's a lot like being a parent. And if you don't look at it from that point of view of you really are leading change and you're making things different, which is tremendously uncomfortable for a lot of people that those people will fight you and could ultimately defeat you. And that's one of the anti-patterns that I think is very common that we see when there is failure. Okay. We have a question from Christopher Harkill, which is, did I hear you say that organizations are slowly moving away from system development, lifecycle to service development? I'd actually like to generalize that question a bit, if we can, because SOA has now been around for quite a few years. So perhaps what I'd like to ask people is what are the trends that you see, the underlying trends that you see in the way that organizations are using SOA and how does this impact on the governance? Is it making governance easier or is it making governance more difficult for SOA? I guess I'll go first in less paper. Jet, do you want to go? Okay, I'll go first. So yeah, I think SOA has to some degree become accepted and yesterday's news. And in fact, one of the common things, the decision points that you make is, is this a build or a buy decision? Is it a system that we need to create or is it services that we need to create? And so certainly the needle has moved more toward services. That doesn't mean that everything is a service, of course. Has this made things more difficult? Yeah, actually I think it has because trying to work across organizations and build software that is going to work for a variety of needs is more difficult. It requires more communication. You're probably working with people that are not necessarily co-located with you physically. And so that requires more governance. All other things being equal. On the other hand, you know, is the benefit that you get from that reuse and agility worth that and that's the question that you have to ask. Hopefully the answer is yes and therefore it makes sense to pay that price. Dave, I think picking up on one of the points you were making about the fact that you don't know who your consumers are and it's more difficult in that environment to put a governance regime in place. But do you think perhaps the fact that people are now getting more used to doing this is making it easier or are we discovering new issues as we go along? I would say it's both, Chris. This is Dave. And the big trend that I'm seeing is people understanding the distinction between box categorization of two levels so at a technical layer and so at a business layer. Too often in the past we've blurred the outcome and the target of what we were trying to achieve and understanding that we can solve some things technically and we can solve some things at the business level. And the critical element as you identified is that when we start to develop services that are consumed by people we don't know and don't interact with, that predictability, the lifecycle portfolio management becomes absolutely critical because the consumer has to rely on a service at the same time as the service provider has to be able to adapt and move the service forward. And that requires, like Bob's phrase, adult supervision because if you're delivering something to someone you don't know, how do you communicate that there's a change without there being some overall portfolio and lifecycle governance activity? And I know I keep harping on that one, but that's the one area where we recurrently see attempts to get to, as Bob cost it, as so at the business level with agility and flexibility, not delivering because organizations will not jump that hurdle. This is Jed and I absolutely agree with Dave and Bob's comments. And I think categorizing the technical and business, I guess, angles is absolutely appropriate. And in terms of making it more difficult, certainly my experience is on the technical side, so as an architectural design pattern, it's well accepted by the IT community. Sometimes they may use it in places they shouldn't in vice versa, but I think technically it's well accepted. Clearly the business aspect, the organizational aspect is clearly a lot more difficult and it's something that organizations are continually trying to figure out how it fits within their organizational structures because no organization is the same. They're all different. They have different personalities and trying to be successful with the true vision of SOA is something that needs to be worked. I know in a customer that I'm dealing with now, in fact they're in a position where they know who all their consumers are and it still doesn't make it any easier because the different consumers have different incentives, different objectives, different timelines and trying to get them to work together to make a decision on something, I don't want to say it's simple, but a change to a service interface, it's very complex and you can understand the implications it has. So we, as part of this organization, we had to understand in an environment that is very, very siloed by product, how can they organize themselves around the concept of building these reusable shared services? What kind of decision making authority needs to be put in place so that two groups that don't have alignment in their objectives are not simply going out and building two similar sets of assets. We put in place, and I think it was mentioned perhaps by Bob earlier on, we put in an executive level, the SOA Steering Committee that is comprised of the CIO and his direct reports, all the product line heads, and they're responsible for when there are, essentially they provide the escalation path. So they're not understanding all the details that are going on in the organization, but clearly when we have something that's designated as an enterprise level asset and there is conflict in terms of the direction, then we need to get the executive involved in helping to disposition the issue at hand. Yes, there are more comments on that question. We have another one from Prasantji who asks, could you please share experience in adoption of the governance model? What are the factors that affect the adoption model? Is the technical competence or cultural aspect of the organization, are these the factors? What are the major factors that affect how the SOA governance model is adopted? So that's a pretty general question, but it's really asking for what are people's experience in practice of this? So, Bob, I'll go first. I think from a technical, solid governance point of view, to the degree that you've laid things out well and it's obvious what needs to be done so the technical, the programmers, whatever, are not having to guess at what they need to do. In other words, there's a well-defined process. And to the degree you've made it as easy as possible for them that all of those things aid acceptance. And then I think at the business level, as I mentioned before, change management is crucial for that level of solid governance. Yeah, this is Jed. I would say if they don't know they're doing it, that's the easiest way to get it adopted. I mean, governance in general of like that solid governance is no different. As much as you can do, like Bob said, to simplify it so they know exactly what they can do, any opportunity you can have to automate the governance functions, you want to definitely look at tooling automation. I would not lead with that, but certainly tooling is a good, is a necessary part of implementation. And if there are existing governance processes in place, then certainly you want to look for opportunities to leverage those and just to give you an example. So one of my clients, they already had, as part of their IT governance framework, they had the opportunity or they had a process in place to do architectural level reviews of their solutions, clearly leveraging that to take a look and say, well, as part of your solutions, are you building the enterprise level services according to what your organization has laid out from a target state? It's something that they can ask that additional question or look at that as part of a process that the organization is already doing today. So it's not saying, well, let's define a new process to look at the services aspect of your solutions. It's built into a process that already exists. So I would say probably those three things can help increase adoption, as well as communication and change management. Anything, David, to add to that? So I'll take the job of summing up because, again, I'm agreeing with Bob and Jed, and I'm going to reach back to a comment Jed made about maturity. What problems is your organization capable of solving today, whether you look at the maturity model for SOA, at what technical capabilities you have, and what are the underpinning organizational capabilities? The example of a highly siloed organization is key because your governance activity has to be culturally aware. So we can give you some examples, but they're based upon, well, this organization works this way, so that worked. But being culturally aware and tying as closely as possible into existing governance activities, into existing reporting activities, so that we can reuse what the organization is already doing so that we're not creating more burden and helping it be invisible because people are used to doing what they do now. And if we can use what they're doing now to do effective SOA governance, it doesn't look like they're being asked to do more, if that makes sense. That's what I would focus on, to serve your maturity, your culture, and reusing existing processes and bodies in an organization. I mean, it's sounding from where we're all agreed that the culture of the organization does make, and not only the culture, but the expertise of the organization does make a big difference to the way that you need to approach governance that you must be careful not to try and put in place something that doesn't really suit the organization, and I guess it probably also reinforces the need to be able to update your governance regimen as the organization matures and develops its expertise for SOA. There was a particular point, I think, that a couple of you have picked up on, which was the value of automation in SOA governance. Perhaps I could ask, are we seeing more and better tools appear? Is this something that really the enterprise has to try and craft for itself if it wants good tools, or are we finding that there are tools available, perhaps open source for people to take advantage of? You, Bob, particularly, do you sort of have a feel for how the tooling situation is going with SOA governance? Yeah, so are there tools out there that are good? Yes. Are they getting better? Yeah. I think to some extent there hasn't been as much investment in governance tools because I think governance has not been as much uptake as SOA itself has. SOA governance is, I think, behind SOA in terms of its uptake, and perhaps its use. So I think the trend has been in the right direction, but I wouldn't say that there's just a ton of really focused tools in terms of automation at a detailed level. There's certainly tools that will help you do governance, and there's a lot of SOA governance tools out there itself, and they are helpful, but I think this area is still emerging to some degree. Sure, this is Jen, and I agree with Bob in terms of what I'm seeing. I think one of the key things, and as you roll out your governance framework to the organizations, and you look how to use a consulting term, operationalize or make real in the organization, clearly there's a number of tools that you can put in place to automate those. So if you think of the registry repository tools that are out there, those are, I think, as far as if you look at development time and runtime tooling, because those are different categories, but you look at the tooling to support those. Clearly the registry repository is one of those, but there are other tools that you can use to help automate your processes. In addition to those two, that will help make it easier for both the development community as well as those members of the organization that are doing the more strategic or planning level activities. So I would encourage you to think about it more holistically and ensure that the tooling that you pick is positioned properly and it fits the role within the governance framework that you're intending it to do. Any comments on that, Bob? If not, as we are approaching the end of the hour, I'd like to ask you all one final question that you might like to comment on which would perhaps also contribute to our understanding of the SOA governance framework and how it should be used and perhaps also be of use to any future development. Given that we have the open group SOA governance framework which has been in place now for a couple of years, if we were to think about revising that, what would be the main points that you would see that it might be important either to change or to give a different emphasis to? Okay, so I would say the framework at the level it is now that that part's fine. I think if we had right people and time and resources that they're taking that down to a next level so perhaps providing more specific guidance in the various entities would be good. I think another interesting thing, we have a SOA maturity model, we don't have a SOA governance maturity model. So I think that would be another interesting area that we could add to the framework. That's an interesting thought. SOA governance maturity. Dave, any thoughts on this? I would focus on two things if I were involved in redoing it. One is highlighting that the process is identified and the activities identified are not necessarily new processes or activities. What we were just talking about in terms of adoption, using existing governance activities, but asking one more question that you're existing architectural review. Adding something into your software development lifecycle to provide the pieces, highlighting that the framework are things that you must do but they don't have to be standalone activities which I think overcomes the burden because one of the things we see people doing is going, oh, SOA governance, I'll set up a separate SOA governance apparatus in my organization to pursue it. The second thing is echoing what Bob talked about which is a maturity, not necessarily a maturity model but maybe a value model. Where am I going to get more value out of service oriented architecture, service oriented governance, and where will I understand the investments necessary to realize that value? Those are the two things I would do. The idea of a value model is an interesting one there to focus on what are the benefits of applying maybe different aspects. Bob, do you have thoughts on this? Yeah, I think a value model is to some degree has some similarities to a maturity model because I think they talk about the same things. Where is the value and what can governments do to help engender that value? I think that's along the same lines. And is there anything else you would change or re-emphasize in the SOA governance framework? I think the framework was and is a value effort to start to put some standards in place for SOA governance. It was a good first step but I think there are other steps that would make sense to take along the lines of what we just talked about. Okay. Well, on that note, I think that's a good note to finish this webinar and I would again like to give my thanks to our panelists Bob Laird of IBM, Jed Maxuba of Accenture and Dave Hornford of Conexium and on behalf of the Open Group, this is Chris Harding signing off from this webinar and thanking all of you who have participated. I hope you have enjoyed it and gained benefit from it and we look forward to your participation in future webinars. Thank you all very much. Thanks for hosting this, Chris. Appreciate it.